[Bug c++/32056] Storage classes on template parameters
--- Comment #1 from paolo at gcc dot gnu dot org 2009-11-16 08:31 --- Subject: Bug 32056 Author: paolo Date: Mon Nov 16 08:31:26 2009 New Revision: 154198 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154198 Log: cp/ 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/32056 * decl.h (enum decl_context): Add TPARM enumerator. * decl.c (grokdeclarator): Per 14.1/2, error out if a storage class is specified in a template parameter declaration. * parser.c (cp_parser_template_parameter): Call grokdeclarator with TPARM as third argument. testsuite/ 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/32056 * testsuite/g++.dg/template/error44.C: New. Added: trunk/gcc/testsuite/g++.dg/template/error44.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/decl.h trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32056
[Bug c++/32056] Storage classes on template parameters
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-16 08:33 --- Fixed for 4.5.0. -- 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=32056
[Bug c++/42055] [4.5 Regression] ICE with ambiguous template specialization
-- 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-11-16 09:04:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42055
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #6 from mexas at bristol dot ac dot uk 2009-11-16 09:50 --- The suggested patch seems to fail. Perhaps it's out of sync now. # patch ./libgcc/config.host patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: libgcc/config.host |=== |--- libgcc/config.host (revision 152205) |+++ libgcc/config.host (working copy) -- Patching file ./libgcc/config.host using Plan A... Hunk #1 failed at 342. 1 out of 1 hunks failed--saving rejects to ./libgcc/config.host.rej Hmm... Ignoring the trailing garbage. done # -- mexas at bristol dot ac dot uk changed: What|Removed |Added GCC host triplet|FreeBSD 8.0-BETA2 ia64 |FreeBSD 9.0-current ia64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/42017] gcc compiling C for ARM has stopped using r14 in leaf functions?
--- Comment #5 from ramana at gcc dot gnu dot org 2009-11-16 09:58 --- Confirmed. LR could have been used instead of using the stack here. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-16 09:58:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #23 from rootkit85 at yahoo dot it 2009-11-16 10:02 --- Despite its name Geode GX, LX and NX are very different, I guess that we should split them to geode-gx and geode-lx, and alias geode-nx to k7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug target/41999] Bug in generation of interrupt function code for ARM processor
--- Comment #1 from ramana at gcc dot gnu dot org 2009-11-16 10:18 --- Confirmed. -- ramana 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-11-16 10:18:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41999
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #9 from dominiq at lps dot ens dot fr 2009-11-16 10:34 --- The failures reported in comment #8 have disappeared between revisions 154188 and 154190 (compare http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01435.html and http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01388.html), likely fixed by revision 154189: * gcc.dg/lto/lto.exp: For non-lto, bail out before calling init functions. Is it right to conclude that the failures were due to revision 154104? 2009-11-11 H.J. Lu hongjiu...@intel.com PR testsuite/42001 * gcc.dg/lto/lto.exp: Pass no-mathlib to lto_init. Call lto_finish at the end. * lib/lto.exp (lto_init): Set mathlib to for no-mathlib. (lto_finish): New. Restore mathlib. If yes, understanding the origin of the failures triggered by revision 154104 may help to produce a reduced test case for this PR. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, hp at axis dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #10 from hp at gcc dot gnu dot org 2009-11-16 10:57 --- (In reply to comment #9) The failures reported in comment #8 have disappeared between revisions 154188 and 154190 Is it right to conclude that the failures were due to revision 154104? *shrug* your call. At a glance it appears they're due to a bug in dsymutil, apparently trigged by dropping -lm as per 154104. Have a look at http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00732.html. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC|hp at axis dot com |hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/42063] g++ violate [class.dtor] when explicit destructor call
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-16 13:16 --- I don't have the time to analyze this, but I note that a binary built with ICC behaves exactly the same way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42063
[Bug c++/42059] [4.4/4.5 Regression] [c++0x] ICE with initializer list for VLA
--- Comment #1 from jakub at gcc dot gnu dot org 2009-11-16 13:49 --- Created an attachment (id=19020) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19020action=view) gcc45-pr42059.patch Caused by PR40689. Here is an untested fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42059
[Bug c++/42063] g++ violate [class.dtor] when explicit destructor call
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-16 13:59 --- The confusion stems from the way, slightly confusing, in which the example in the standard is written, which, if considered an actually runnable snippet, invokes undefined behavior, because destroys the base of D_object two times. If you change it to something like: D D_object, D_object2; B* B_ptr = D_object2; std::cout begin std::endl; D_object.B::~B(); B_ptr-~B(); std::cout end std::endl; Then the example still explain the important role of virtual destructors - that is, B_ptr-~B() invokes ~D, *not* ~B (after that, ~B is implicitly invoked, as normally happens in inheritance hierarchies) - but no undefined behavior is involved. Talking about undefined behavior, after Once a destructor is invoked for an object, the object no longer exists the (draft C++0x) standard continues ; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended: as any undefined behavior, anything can happen, depending on the actual size of the class being destructet, depending on the diagnostics enabled in the underlying memory allocation functions, etc. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42063
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
--- Comment #17 from paolo dot carlini at oracle dot com 2009-11-16 14:06 --- Gaby, I'm sorry, are you actively working on this issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
[Bug debug/42065] New: DWARF .debug_macinfo contains unused macros
-g3 currently produces huge objects as it contains many unused macros.
-g2 produces no macros debug info so GDB cannot provide its expansion.
There is no way to store just the used macros.
(debuginfo compression driven by Roland McGrath may eliminate them but
still...)
While even a macro never used by a program can be helpful in most cases IMO it
is enough to provide the macro definitions touched by the code being debugged.
-feliminate-unused-debug-symbols -feliminate-unused-debug-types have no effect.
---
#define NOT used
#define USED(x) x
int main (void) { return USED (0); }
---
Getting:
gcc -g3 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
DW_MACINFO_define - lineno : 1 macro : NOT used
DW_MACINFO_define - lineno : 2 macro : USED(x) x
or:
gcc -g2 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
nothing printed
Expected output:
gcc -g3 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
DW_MACINFO_define - lineno : 2 macro : USED(x) x
--
Summary: DWARF .debug_macinfo contains unused macros
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #11 from dominiq at lps dot ens dot fr 2009-11-16 14:29 ---
The following code triggers the problem on i686-apple-darwin9 at revision
154075 (+ patches from fortran-dev):
[ibook-dhum] f90/bug% cat complex-sign-add_red_1.c
extern void exit (int);
void
check_add_float (void)
{
_Complex float a1;
volatile _Complex float a2, b2, c2;
a1 = (+ 1 == 1 ? + 1 == 1 ? 0.0f + 0.0if : 0.0f - 0.0if : + 1 == 1 ? -(0.0f -
0.0if) : -(0.0f + 0.0if));
a2 = (+ 1 == 1 ? + 1 == 1 ? 0.0f + 0.0if : 0.0f - 0.0if : + 1 == 1 ? -(0.0f -
0.0if) : -(0.0f + 0.0if));
b2 = (+ 1 == 1 ? + 1 == 1 ? 0.0f + 0.0if : 0.0f - 0.0if : + 1 == 1 ? -(0.0f -
0.0if) : -(0.0f + 0.0if));
c2 = a2 + b2;
}
int
main (void)
{
check_add_float ();
exit (0);
}
[ibook-dhum] f90/bug% gcc45 complex-sign-add_red_1.c -O1 -g -c
[ibook-dhum] f90/bug% gcc45 complex-sign-add_red_1.o -O1 -g
[ibook-dhum] f90/bug% dsymutil a.out
Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
Abort
The reduced case does not trigger the error on powerpc-apple-darwin9 while the
full test does.
QUESTIONS: what does gcc 4.5 put in the a.out files that triggers (or not) the
failure?
How am I supposed to find it?
Note that 'gcc45 complex-sign-add_red_1.c -O1 -g' triggers the same error, but
in both cases the executable is produced and can be run (I did not tried to
debug it). Also the dsymutil bug is not triggered at -O0. Finally 'gcc45
complex-sign-add_red_1.c -O1 -g -lm' does not gives any error due to the fact
that dsymutil is not called. The -v option gives respectively:
...
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-O1' '-g' '-v'
'-mtune=generic'
dsymutil a.out
Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
gcc45: Internal error: Abort trap (program dsymutil)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
and
...
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-O1' '-g' '-v'
'-mtune=generic'
Is this the intended behavior?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
Re: [Bug debug/42065] New: DWARF .debug_macinfo contains unused macros
Sent from my iPhone
On Nov 16, 2009, at 6:12 AM, jan dot kratochvil at redhat dot com gcc-bugzi...@gcc.gnu.org
wrote:
-g3 currently produces huge objects as it contains many unused macros.
-g2 produces no macros debug info so GDB cannot provide its expansion.
That is by design and the reason why -g is -g2 by default
There is no way to store just the used macros.
(debuginfo compression driven by Roland McGrath may eliminate them but
still...)
While even a macro never used by a program can be helpful in most
cases IMO it
is enough to provide the macro definitions touched by the code being
debugged.
-feliminate-unused-debug-symbols -feliminate-unused-debug-types have
no effect.
---
---
---
--
#define NOT used
#define USED(x) x
int main (void) { return USED (0); }
---
---
---
--
Getting:
gcc -g3 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
DW_MACINFO_define - lineno : 1 macro : NOT used
DW_MACINFO_define - lineno : 2 macro : USED(x) x
or:
gcc -g2 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
nothing printed
Expected output:
gcc -g3 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
DW_MACINFO_define - lineno : 2 macro : USED(x) x
--
Summary: DWARF .debug_macinfo contains unused macros
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065
[Bug debug/42065] DWARF .debug_macinfo contains unused macros
--- Comment #1 from pinskia at gmail dot com 2009-11-16 14:31 ---
Subject: Re: New: DWARF .debug_macinfo contains unused macros
Sent from my iPhone
On Nov 16, 2009, at 6:12 AM, jan dot kratochvil at redhat dot com
gcc-bugzi...@gcc.gnu.org
wrote:
-g3 currently produces huge objects as it contains many unused macros.
-g2 produces no macros debug info so GDB cannot provide its expansion.
That is by design and the reason why -g is -g2 by default
There is no way to store just the used macros.
(debuginfo compression driven by Roland McGrath may eliminate them but
still...)
While even a macro never used by a program can be helpful in most
cases IMO it
is enough to provide the macro definitions touched by the code being
debugged.
-feliminate-unused-debug-symbols -feliminate-unused-debug-types have
no effect.
---
---
---
--
#define NOT used
#define USED(x) x
int main (void) { return USED (0); }
---
---
---
--
Getting:
gcc -g3 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
DW_MACINFO_define - lineno : 1 macro : NOT used
DW_MACINFO_define - lineno : 2 macro : USED(x) x
or:
gcc -g2 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
nothing printed
Expected output:
gcc -g3 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
DW_MACINFO_define - lineno : 2 macro : USED(x) x
--
Summary: DWARF .debug_macinfo contains unused macros
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065
[Bug debug/42065] DWARF .debug_macinfo contains unused macros
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-11-16 14:49 --- (In reply to comment #1) -g3 currently produces huge objects as it contains many unused macros. -g2 produces no macros debug info so GDB cannot provide its expansion. That is by design and the reason why -g is -g2 by default OK, thanks for info, still IMO there should be such an additional option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065
[Bug c++/42055] [4.5 Regression] ICE with ambiguous template specialization
--- Comment #1 from paolo at gcc dot gnu dot org 2009-11-16 14:58 --- Subject: Bug 42055 Author: paolo Date: Mon Nov 16 14:58:33 2009 New Revision: 154202 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154202 Log: cp/ 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * pt.c (determine_specialization): Assign to candidates the return value of the chainon called before print_candidates. testsuite/ 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * testsuite/g++.dg/template/crash92.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash92.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42055
[Bug c++/42055] [4.5 Regression] ICE with ambiguous template specialization
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-16 14:59 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42055
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-11-16 15:13 --- Dominique, Can code in comment 11 be converted into a test case that can be run through dsymutil without requiring FSF gcc to be installed? If so, please open a radar report with that information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #13 from dominiq at lps dot ens dot fr 2009-11-16 15:37 --- (In reply to comment #12) Can code in comment 11 be converted into a test case that can be run through dsymutil without requiring FSF gcc to be installed? If so, please open a radar report with that information. Jack, I am not sure to understand what you ask for. My knowledge (rather my ignorance!-) of C makes me unable to say if there is anything non standard in the code in comment 11. Let me repeat that the failures to use dsymutil on the executable file is specific to gcc 4.5 and cannot repeated with the gcc shipped by Apple nor with any gcc version I have pre-VTA merge. My uneducated guess is that post-VTA merge gcc sometimes puts some stuff in the executable files that trigger the assertion in dsymutil. In my opinion only those knowing what they are doing with the dwarf information can tell us where to look to go further. Note that I have forgotten to mention that further reducing the test makes the dsymutil failure to disappear (I did not tried to reduced the different switches). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug tree-optimization/41501] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE - `-fprofile-use' fails with '-02'
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-11-16 15:57 --- See PR34999 -- ghazi 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-11-16 15:57:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41501
[Bug c++/42061] [4.4/4.5 Regression] [c++0x] ICE with invalid initializer list for reference
--- Comment #1 from jakub at gcc dot gnu dot org 2009-11-16 16:06 --- Created an attachment (id=19021) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19021action=view) gcc45-pr42061.patch Fix I'm going to bootstrap/regtest. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42061
[Bug c++/42066] New: C++0x lambda captures are not understood as used by -Wunused and -Wunused-parameter
GCC 4.5's -Wunused and -Wunused-parameter warnings don't understand that i and
n being used in the function below:
#include functional
std::functionint () foo(int i)
{
int n = 5;
return [=]() { return i+n; };
}
$ g++-4.5-20091112 -std=c++0x -Wall -Wextra -c lambda.cpp
lambda.cpp: In function 'std::functionint() foo(int)':
lambda.cpp:5:8: warning: unused variable 'n'
lambda.cpp: At global scope:
lambda.cpp:3:23: warning: unused parameter 'i'
Using optimizations doesn't seem to have an effect on this either way.
Workaround: Adding i and n explicitly to the capture list causes GCC to
understand that they are being used in this function.
$ g++-4.5-20091112 -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++-4.5-20091112
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5-20091112/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5-20091112/configure
--prefix=/usr/local/gcc-4.5-20091112 --program-suffix=-4.5-20091112
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20091112 (experimental) (GCC)
--
Summary: C++0x lambda captures are not understood as used by -
Wunused and -Wunused-parameter
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42066
[Bug c++/41920] Invalid 'unused parameter' warning for parameters used in lambdas
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-16 16:17 --- *** Bug 42066 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||lloyd at randombit dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41920
[Bug c++/42066] C++0x lambda captures are not understood as used by -Wunused and -Wunused-parameter
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-16 16:17 --- *** This bug has been marked as a duplicate of 41920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|C++0x lambda captures are |C++0x lambda captures are |not understood as used by - |not understood as used by - |Wunused and -Wunused- |Wunused and -Wunused- |parameter |parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42066
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #12 from yipiha2008 at gmail dot com 2009-11-16 16:17 --- I would like to confirm that this bug affects gcc 4.4.2. Compiling ffmpeg 0.5 triggers it in many places. It may be a good idea to try to fix this in 4.5 if it's not fixed yet, before Nov 30th which is the end of stage 3. The unassigned status of this bug makes me wonder if it will be fixed soon enough. Also, I don't understand why the severity of this bug is normal and not blocker, since it makes it impossible to compile some files. -- yipiha2008 at gmail dot com changed: What|Removed |Added CC||yipiha2008 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #14 from dominiq at lps dot ens dot fr 2009-11-16 16:25 --- I don't know if this answer the question in comment 12. I have done the following experiment: [ibook-dhum] f90/bug% rm -rf a.out* [ibook-dhum] f90/bug% rm complex-sign-add_red_1.* remove complex-sign-add_red_1.c? n remove complex-sign-add_red_1.o? y remove complex-sign-add_red_1.s? y [ibook-dhum] f90/bug% gcc45 complex-sign-add_red_1.c -O1 -g -S [ibook-dhum] f90/bug% as complex-sign-add_red_1.s -o complex-sign-add_red_1.o [ibook-dhum] f90/bug% gcc complex-sign-add_red_1.o [ibook-dhum] f90/bug% a.out [ibook-dhum] f90/bug% dsymutil a.out Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line 3641. Abort [ibook-dhum] f90/bug% rm -rf a.out* [ibook-dhum] f90/bug% rm complex-sign-add_red_1.* remove complex-sign-add_red_1.c? n remove complex-sign-add_red_1.o? y remove complex-sign-add_red_1.s? y [ibook-dhum] f90/bug% gcc45 complex-sign-add_red_1.c -O0 -g -S [ibook-dhum] f90/bug% as complex-sign-add_red_1.s -o complex-sign-add_red_1.o [ibook-dhum] f90/bug% gcc complex-sign-add_red_1.o [ibook-dhum] f90/bug% a.out [ibook-dhum] f90/bug% dsymutil a.out [ibook-dhum] f90/bug% gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5493) [ibook-dhum] f90/bug% as -v Apple Inc version cctools-698.1~1, GNU assembler version 1.38 ^CInterrupted by signal 2 [ibook-dhum] f90/bug% gcc45 -v Using built-in specs. COLLECT_GCC=gcc45 COLLECT_LTO_WRAPPER=/Volumes/MacBook/opt/gcc/gcc4.5w/bin/../libexec/gcc/i686-apple-darwin9/4.5.0/lto-wrapper Target: i686-apple-darwin9 Configured with: ../gcc-4.5-work/configure --prefix=/opt/gcc/gcc4.5w --mandir=/opt/gcc/gcc4.5w/share/man --infodir=/opt/gcc/gcc4.5w/share/info --build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cloog=/sw --with-ppl=/sw --with-mpc=/opt/mpc/build Thread model: posix gcc version 4.5.0 20091110 (experimental) [trunk revision 154075p3] (GCC) So the problem seems contained in the assembly code. I had a look at the difference between the assembly generated with -O0 and -O1, but did not see anything obvious (I'll attach the files later). BTW is the test in comment 11 giving the same result on darwin10? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-11-16 16:27 --- I meant if we can create a test case from an assembly file generated from FSF gcc which can be used to trigger the problem in dsymutil in absence of FSF gcc itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #16 from dominiq at lps dot ens dot fr 2009-11-16 16:31 --- I meant if we can create a test case from an assembly file generated from FSF gcc which can be used to trigger the problem in dsymutil in absence of FSF gcc itself. Are the results in comment 14 answering your question? Can you reproduce it on darwin10? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #17 from dominiq at lps dot ens dot fr 2009-11-16 16:38 ---
Note that the dsymutil failure for the test in comment 11 disappears in 64 bit
mode.
The original code in the test suite gives:
[ibook-dhum] f90/bug% gcc45
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/torture/complex-sign-add.c -O3 -g -m64
warning: {0x0124} TAG_variable: AT_location( 0x021c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0132} TAG_variable: AT_location( 0x0250 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0140} TAG_variable: AT_location( 0x0284 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x018b} TAG_variable: AT_location( 0x02b8 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0199} TAG_variable: AT_location( 0x02ec ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x01a7} TAG_variable: AT_location( 0x0320 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x01f2} TAG_variable: AT_location( 0x0354 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0200} TAG_variable: AT_location( 0x0388 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x020e} TAG_variable: AT_location( 0x03bc ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0259} TAG_variable: AT_location( 0x03f0 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0267} TAG_variable: AT_location( 0x0424 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0275} TAG_variable: AT_location( 0x0458 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x02c0} TAG_variable: AT_location( 0x048c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x02ce} TAG_variable: AT_location( 0x04c0 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x02dc} TAG_variable: AT_location( 0x04f4 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0327} TAG_variable: AT_location( 0x0528 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0335} TAG_variable: AT_location( 0x055c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0343} TAG_variable: AT_location( 0x0590 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x038e} TAG_variable: AT_location( 0x05c4 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x039c} TAG_variable: AT_location( 0x05f8 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x03aa} TAG_variable: AT_location( 0x062c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x03f5} TAG_variable: AT_location( 0x0660 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0403} TAG_variable: AT_location( 0x0694 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0411} TAG_variable: AT_location( 0x06c8 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x045c} TAG_variable: AT_location( 0x06fc ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x046a} TAG_variable: AT_location( 0x0730 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0478} TAG_variable: AT_location( 0x0764 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x04c3} TAG_variable: AT_location( 0x0798 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x04d1} TAG_variable: AT_location( 0x07cc ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x04df} TAG_variable: AT_location( 0x0800 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x052a} TAG_variable: AT_location( 0x0834 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0538} TAG_variable: AT_location( 0x0868 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0546} TAG_variable: AT_location( 0x089c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0591} TAG_variable: AT_location( 0x08d0 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x059f} TAG_variable: AT_location( 0x0904 ) didn't have
valid function
[Bug c++/42058] [4.3/4.4/4.5 Regression] Trouble with invalid array initialization
-- 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-11-16 16:50:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42058
[Bug fortran/42041] Missing defs in omp_lib.h
--- Comment #2 from longb at cray dot com 2009-11-16 16:58 --- I posed this question to the Cray OpenMP committee member: Jim @ ISU submitted a bug against gfortran noting that some parameters defined in the omp_lib Fortran module are missing from the corresponding omp_lib.h include file. The GNU guys are claiming that the difference is intentional, and are right that in the 3.0 standard the 'missing' declarations are only in the Example module in D3, and not in the Example include file in D2. They are not mentioned in the normative text in Chapter 3. Is this difference intentional? Or is it an oversight in the standard?Could you add a Comment to Bug 753421? Thanks. And got this reply: The differences between the omp_lib.h and omp_lib module are actually a bug in the specification. I have an open issue in my name with the OpenMP Language committee to submit a proposed fix for this. The solution will be to make the types default to the size of a default integer. This change will be in the 3.1 specification due for release by SC10. -- From which I would conclude that this bug will come back again when the OpenMP spec is corrected. Might be easier to just fix it now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42041
[Bug c++/42067] New: Misleading error message for misusing a type
The following small test drove me crazy and had me convinced that gcc 4.4 had regressed. I had the C++ spec out too trying to understand exactly how string is declared until I eventually saw the actual problem, which is that the first parameter is named 'string'. I'm not sure exactly how to improve the error message here. 4.3 and earlier accept this code. #include string using std::string; int fn(string string, string head); g++-4.4 -c junk.C junk.C:3: error: string is not a type -- Summary: Misleading error message for misusing a type Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jlquinn at optonline dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42067
[Bug c++/42067] Misleading error message for misusing a type
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-16 17:02 --- Well you are not misusing a type here really. The second string causes string to be a variable name, so the error message is correct as it is no longer a type at that point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42067
[Bug c++/42067] Misleading error message for misusing a type
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-16 17:04 --- Comeau online tester gives: ComeauTest.c, line 4: error: parameter string is not a type name int fn(string string, string head); Which is only slightly better. The trunk gives a column number: t.cc:3:24: error: 'string' is not a type Which shows where the problem is. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42067
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2009-11-16 17:23 --- CCing one the of ARM maintainers. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #14 from rearnsha at gcc dot gnu dot org 2009-11-16 17:35 --- This is probably a consequence of some changes made to support Thumb-2. Only a very limited number of instructions are permitted to modify SP there, and co-processor operations are not amongst them. I think the correct way to solve this is to add a secondary reload pattern that handles moving co-processor regs to STACK_REGS (and vice-versa). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug bootstrap/42068] New: [4.5 regression] ICE in function_and_variable_visibility breaks Tru64 UNIX Ada bootstrap
Between 20091106 and 20091113 (rev 154146), bootstrap of both alpha-dec-osf4.0f and alpha-dec-osf5.1b failed in stage2 compiling ada/s-bitops.adb: % /tmp_mnt/vol/gcc/obj/gcc-4.5.0-20091113/4.0f-gcc/./prev-gcc/xgcc -B/tmp_mnt/vol/gcc/obj/gcc-4.5.0-20091113/4.0f-gcc/./prev-gcc/ -B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/lib/ -isystem /vol/gcc/alpha-dec-osf4.0f/include -isystem /vol/gcc/alpha-dec-osf4.0f/sys-include-c -g -O2 -gnatpg -gnata -nostdinc -I- -I. -Iada -I/vol/gcc/src/gcc-dist/gcc/ada -I/vol/gcc/src/gcc-dist/gcc/ada/gcc-interface /vol/gcc/src/gcc-dist/gcc/ada/s-bitops.adb -o ada/s-bitops.o +===GNAT BUG DETECTED==+ | 4.5.0 20091113 (experimental) [trunk revision 154146] (alpha-dec-osf4.0f) GCC error:| | in function_and_variable_visibility, at ipa.c:322| | Error detected around /vol/gcc/src/gcc-dist/gcc/ada/s-bitops.adb:215:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /vol/gcc/src/gcc-dist/gcc/ada/system.ads /vol/gcc/src/gcc-dist/gcc/ada/s-bitops.adb /vol/gcc/src/gcc-dist/gcc/ada/s-bitops.ads /vol/gcc/src/gcc-dist/gcc/ada/s-unstyp.ads /vol/gcc/src/gcc-dist/gcc/ada/ada.ads /vol/gcc/src/gcc-dist/gcc/ada/a-unccon.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423 make[3]: *** [ada/s-bitops.o] Error 1 This is most likely due to one of Jan's recent commits. -- Summary: [4.5 regression] ICE in function_and_variable_visibility breaks Tru64 UNIX Ada bootstrap Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: alpha-dec-osf* GCC host triplet: alpha-dec-osf* GCC target triplet: alpha-dec-osf* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug target/32344] crash with EH on multiprocessor machines
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-11-16 17:51 --- I can reproduce with mainline on a bi-processor machine (Sun-Fire-V240) running Solaris 10 but neither on a bi-processor machine (Sun-Fire-V240) runnning Solaris 9 nor on a quadri-processor machine (Sun-Fire-V440) running Solaris 8. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-11-30 12:24:24 |2009-11-16 17:51:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32344
[Bug bootstrap/41996] lto-elf.c fails to compile on IRIX 6.5
--- Comment #4 from espindola at gcc dot gnu dot org 2009-11-16 17:57 --- Created an attachment (id=19022) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19022action=view) proposed fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41996
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #7 from sje at cup dot hp dot com 2009-11-16 18:14 --- The patch worked for me after changing some leading spaces to tabs If you grabbed it with a cut-n-paste the patch may have had spaces in it instead of tabs (or perhaps it was put in the report that way). You can either change the spaces to tabs by hand and use patch or you could just apply the patch by hand, there is only one instance of ia64*freebsd in the libgcc/config.host file and all you need to do is add the two new lines to the file at that location. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #18 from dominiq at lps dot ens dot fr 2009-11-16 19:01 --- Created an attachment (id=19023) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19023action=view) assembly code giving an executable accepted by dsymutil [ibook-dhum] f90/bug% rm -rf a.out* [ibook-dhum] f90/bug% as complex-sign-add_red_1_O0.s -o complex-sign-add_red_1_O0.o [ibook-dhum] f90/bug% gcc complex-sign-add_red_1_O0.o [ibook-dhum] f90/bug% dsymutil a.out [ibook-dhum] f90/bug% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #19 from dominiq at lps dot ens dot fr 2009-11-16 19:03 --- Created an attachment (id=19024) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19024action=view) assembly code giving an executable that fails dsymutil [ibook-dhum] f90/bug% rm -rf a.out* [ibook-dhum] f90/bug% as complex-sign-add_red_1_O1.s -o complex-sign-add_red_1_O1.o [ibook-dhum] f90/bug% gcc complex-sign-add_red_1_O1.o [ibook-dhum] f90/bug% dsymutil a.out Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line 3641. Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl
--- Comment #19 from ubizjak at gmail dot com 2009-11-16 19:05 ---
(In reply to comment #18)
This bug also still appears in 4.4.2 with --with-arch=pentium3.
pentium3 fails because it is not TARGET_HIMODE_MATH and TARGET_QIMODE_MATH.
So, it fails following testcase:
unsigned short
plusccsa (unsigned short a, unsigned short b)
{
unsigned short sum = a + b;
if (sum a)
abort ();
return sum;
}
It used to generate:
plusccsa:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movzwl 8(%ebp), %edx
movzwl 12(%ebp), %eax
addl%edx, %eax
movzwl %ax, %eax
cmpw%ax, %dx
ja .L97
leave
ret
.L97:
callabort
And after the fix for wrong mode of compare insn for these targets [1]:
plusccsa:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movzwl 8(%ebp), %edx
movzwl 12(%ebp), %eax
addl%edx, %eax
movzwl %ax, %eax
cmpl%eax, %edx
ja .L52
leave
ret
.L52:
callabort
You don't want instructions that operate on bytes or words on pentium3...
At the end of the day, no bug here.
[1] http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00787.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
[Bug c++/42069] New: 4.5 fails
The following code generates an tree check error in cp/pt.c of gcc 4.5 trunk
(11/15/2009). This is a kernel that reproduces the error in a larger project.
Both the kernel and original code compile and run correctly in previous
versions of gcc.
templatetypename T
struct A
{
static const int size = 1;
};
templateint Integral
struct B
{
typedef int type;
};
templatetypename T
struct C
{
typedef int type;
};
templatetypename X, typename Y = void
struct D
{
typedef typename CX::typeT;
typedef AT AT;
typedef typename BAT::size::type type;
};
templatetypename X
struct DX, void
{
typedef typename CX::typeT;
typedef AT AT;
typedef typename BAT::size::type type;
};
main()
{
Dbool t;
}
gcc -v -save-temps -o test test.cc
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gnu/gcc-4.5.trunk.10.14.09/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc.trunk/configure --enable-languages=c++
--prefix=/usr/local/gnu/gcc-4.5.trunk.10.14.09
--with-mpfr=/usr/local/gnu/mpfr-2.4.1
Thread model: posix
gcc version 4.5.0 20091110 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-mtune=generic'
/usr/local/gnu/gcc-4.5.trunk.10.14.09/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1plus
-E -quiet -v -D_GNU_SOURCE test.cc -mtune=generic -fpch-preprocess -o test.ii
ignoring nonexistent directory
/usr/local/gnu/gcc-4.5.trunk.10.14.09/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/gnu/gcc-4.5.trunk.10.14.09/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0
/usr/local/gnu/gcc-4.5.trunk.10.14.09/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/i686-pc-linux-gnu
/usr/local/gnu/gcc-4.5.trunk.10.14.09/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/backward
/usr/local/include
/usr/local/gnu/gcc-4.5.trunk.10.14.09/include
/usr/local/gnu/gcc-4.5.trunk.10.14.09/lib/gcc/i686-pc-linux-gnu/4.5.0/include
/usr/local/gnu/gcc-4.5.trunk.10.14.09/lib/gcc/i686-pc-linux-gnu/4.5.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-mtune=generic'
/usr/local/gnu/gcc-4.5.trunk.10.14.09/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1plus
-fpreprocessed test.ii -quiet -dumpbase test.cc -mtune=generic -auxbase test
-version -o test.s
GNU C++ (GCC) version 4.5.0 20091110 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.5.0 20091110 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5
warning: GMP header version 4.3.1 differs from library version 4.1.4.
warning: MPFR header version 2.4.1-p5 differs from library version 2.3.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.5.0 20091110 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.5.0 20091110 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5
warning: GMP header version 4.3.1 differs from library version 4.1.4.
warning: MPFR header version 2.4.1-p5 differs from library version 2.3.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: a2f4d0ba16c13073ade98a90c4f4dd49
test.cc: In instantiation of 'Dbool':
test.cc:41:12: instantiated from here
test.cc:36:38: internal compiler error: tree check: accessed elt 2 of tree_vec
with 1 elts in tsubst, at cp/pt.c:9721
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: 4.5 fails
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nthomas at cs dot tamu dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42069
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #20 from dominiq at lps dot ens dot fr 2009-11-16 19:37 --- I have filled a bug report to Apple under #7397601. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/42069] [4.5 Regression] fails on class template specialization with default parameter
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-16 19:57 --- Confirmed, worked with 4.4 with checking enabled. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2009-11-16 19:57:52 date|| Summary|4.5 fails on class template |[4.5 Regression] fails on |specialization with default |class template |parameter |specialization with default ||parameter Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42069
[Bug c++/42070] New: FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use
Currently in gcc trunk on darwin10, we fail the test cases... FAIL: g++.dg/tree-prof/partition1.C compilation, -g -fprofile-use UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-g -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-O3 -g -fprofile-use when compiling with -freorder-blocks-and-partition on darwin10 because of many warnings of the form... ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from /var/tmp//ccrw73YL.o This was filed as radar 7289379 with the two failing test cases provided as samples of the problem. Apple's response was... In the sample you supplied, the warning is because there is code in the __TEXT/__unlikely section and there is dwarf debug information that says it part of a function. The linker sanity checks how it broke up the .o file into atoms by checking it against the dwarf debug info. I think the __unlikely section should be avoided on darwin until it is shown to work with the linker. At a minimum each chunk in the __unlikely section should have a label on it with a name based on the function it came from. Those labels would also help debugging. This warning does not have anything to do removing labels from __eh_frame section. -- Summary: FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: *-apple-darwin10 GCC host triplet: *-apple-darwin10 GCC target triplet: *-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42070
[Bug target/42070] FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-16 20:02 --- Basically I think breaking up functions inside sections/segments in object files is a broken way of doing dead stripping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42070
[Bug fortran/41083] Implicit typing: Save implicit type for external procedures
--- Comment #2 from burnus at gcc dot gnu dot org 2009-11-16 20:50 --- Intel (#i552365) pointed out the following, which is part of 11.2 Modules of the F2003 spec: If a procedure declared in the scoping unit of a module has an implicit interface, it shall be given the EXTERNAL attribute in that scoping unit; if it is a function, its type and type parameters shall be explicitly declared in a type declaration statement in that scoping unit. It seems that the current result is OK and standard conforming. One should check that the test cases here are properly rejected (they seem to be) and one should re-check the referenced PRs and the mailing-lists links and the interpretation request. But presumably, one can close this PR as INVALID. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41083
[Bug fortran/39997] Procedure(), pointer implicit typing: rejects-valid / accepts-invalid?
--- Comment #8 from burnus at gcc dot gnu dot org 2009-11-16 20:53 --- PR 41083 seems to be invalid (see quote there). I am not sure which parts remain to be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997
[Bug c++/14777] [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type
--- Comment #16 from dodji at gcc dot gnu dot org 2009-11-16 21:35 --- Created an attachment (id=19025) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19025action=view) Fix candidate I am testing this patch ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug c++/42071] New: ICE on trying to use a typedef as a nested class
templateclass T struct A{
typedef int *B;
};
templateclass T
void AT::B::C(){}
test.cpp:6: internal compiler error: in is_ancestor, at cp/name-lookup.c:2292
--
Summary: ICE on trying to use a typedef as a nested class
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42071
[Bug c++/29388] [4.3 regression] ICE with invalid nested name specifier
--- Comment #16 from paolo dot carlini at oracle dot com 2009-11-16 22:02 --- *** Bug 42071 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||sstrasser at systemhaus- ||gruppe dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29388
[Bug c++/42071] ICE on trying to use a typedef as a nested class
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-16 22:02 --- *** This bug has been marked as a duplicate of 29388 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42071
[Bug c++/14777] [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type
--- Comment #17 from dodji at seketeli dot org 2009-11-16 22:13 --- Subject: Re: [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type Patch sent to http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00813.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug fortran/42072] New: [F03] wrong-code with C_F_PROCPOINTER
The following variant of proc_ptr_8.* fails at runtime:
! { dg-do run }
! { dg-additional-sources proc_ptr_8.c }
MODULE X
USE ISO_C_BINDING
INTERFACE
INTEGER(KIND=C_INT) FUNCTION mytype( a ) BIND(C)
USE ISO_C_BINDING
INTEGER(KIND=C_INT), VALUE :: a
END FUNCTION
SUBROUTINE init() BIND(C,name=init)
END SUBROUTINE
END INTERFACE
TYPE(C_FUNPTR), BIND(C,name=funpointer) :: funpointer
END MODULE X
USE X
PROCEDURE(mytype), POINTER :: ptype
CALL init()
call setpointer(ptype)
if (ptype(3) /= 9) call abort()
contains
subroutine setpointer (p)
PROCEDURE(mytype), POINTER :: p
CALL C_F_PROCPOINTER(funpointer,p)
end subroutine
END
! { dg-final { cleanup-modules X } }
/* Used by proc_ptr_8.f90.
PR fortran/32580. */
int (*funpointer)(int);
int f(int t)
{
return t*3;
}
void init()
{
funpointer=f;
}
--
Summary: [F03] wrong-code with C_F_PROCPOINTER
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: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug fortran/42072] [F03] wrong-code with C_F_PROCPOINTER
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-16 22:51 --- Side-note on C_F_PROCPOINTER: The manual claims that ... Due to the currently lacking support of procedure pointers in GNU Fortran this function is not fully operable. ... which is a dirty lie. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug fortran/42072] [F03] wrong-code with C_F_PROCPOINTER
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-16 22:55 --- Proposed fix: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 154189) +++ gcc/fortran/trans-expr.c(working copy) @@ -2645,6 +2645,12 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * tmp = gfc_get_ppc_type (arg-next-expr-ref-u.c.component); else tmp = TREE_TYPE (arg-next-expr-symtree-n.sym-backend_decl); + + if (arg-next-expr-symtree-n.sym-attr.proc_pointer + arg-next-expr-symtree-n.sym-attr.dummy) + fptrse.expr = build_fold_indirect_ref_loc (input_location, + fptrse.expr); + se-expr = fold_build2 (MODIFY_EXPR, tmp, fptrse.expr, fold_convert (tmp, cptrse.expr)); -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-16 22:55:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug fortran/42072] [F03] wrong-code with C_F_PROCPOINTER
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-16 22:59 --- call setpointer(ptype) is being converted into: setpointer.1481 (); So inside MAIN__ we have: static void setpointer (integer(kind=4) (*T3af) (integer(kind=4))); setpointer (ptype); That is wrong, unless I am missing a reference type somewhere. Plus inside setpointer I think: p = (integer(kind=4) (*T3af) (integer(kind=4)) *) funpointer; is incorrect, it should be: *p = funpointer; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|NEW Last reconfirmed|2009-11-16 22:55:50 |2009-11-16 22:59:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug fortran/42072] [F03] wrong-code with C_F_PROCPOINTER
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-16 23:00 --- Wrong buttons :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug ada/42073] New: Infinite loop when parsing a project file, alpha only
On alpha-linux-gnu, gnatmake enters an infinite loop consuming 100% CPU while
parsing this project file:
project GNADE_Common_Build is
Soversion := External (soversion);
type Lib_Type is (static, dynamic);
Libtype : Lib_Type := external (LIBTYPE);
for Languages use (Ada);
-- At install time, Source_Dirs must reflect the build source
-- directories
for Source_Dirs use (../support);
-- Library_Dir must be a single directory containing all the
-- library files (*.ali, *.a, *.so) for all of the gnade packages.
for Library_Dir use tmp;
-- Object_Dir is only used at build time; it must be distinct from
-- the other package object directories, and from the library
-- directory.
for Object_Dir use tmp/common- Libtype;
for Library_Name use gnadecommon;
for Library_Kind use Libtype;
-- Library_Version is not used when Library_Kind is static
for Library_Version use libgnadecommon.so. Soversion;
package Compiler is
for Default_Switches (Ada) use
(-g,
-O2,
-gnat05,
-gnatfno,
-gnatwa,
-gnatVa,
-fstack-check);
end Compiler;
end GNADE_Common_Build;
Steps to reproduce:
$ gnatmake -p -j1 -vP2 -Pdebian/gnade_common_build -XLIBTYPE=static
-Xsoversion=1 -v
GPR_PROJECT_PATH=.:/usr/share/ada/adainclude/
Project_Path_Name_Of (debian/gnade_common_build,
/home/lbrenta/gnade-1.6.2/);
Trying /home/lbrenta/gnade-1.6.2//debian/gnade_common_build.gpr
Project_Name_From (/home/lbrenta/gnade-1.6.2/debian/gnade_common_build.gpr)
(infinite loop)
gnatmake works with the same project file on all architectures I tried:
{amd64,hppa,i386,ia64,mips,mipsel,powerpc,s390,sparc}-linux-gnu, so this looks
like a code generation bug that affects gnatmake.
I have access to an alpha-linux-gnu machine, please tell me if I can help
narrow this problem down.
--
Summary: Infinite loop when parsing a project file, alpha only
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ludovic at ludovic-brenta dot org
GCC build triplet: alpha-linux-gnu
GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42073
[Bug c++/13950] [DR176] lookup of dependent base name
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-16 23:29 --- Subject: Bug 13950 Author: jason Date: Mon Nov 16 23:29:25 2009 New Revision: 154223 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154223 Log: PR c++/13950, DR 176 * search.c (lookup_field_r): Allow lookup to find the injected-class-name from a template base. (template_self_reference_p): Remove. * decl.c (make_typename_type): Diagnose ambiguity. Use maybe_get_template_decl_from_type_decl. * parser.c (cp_parser_template_name): Pass true to is_template rather than use maybe_get_template_decl_from_type_decl. (cp_parser_lookup_name): Use maybe_get_template_decl_from_type_decl. * pt.c (maybe_get_template_decl_from_type_decl): Handle ambiguity. Use DECL_SELF_REFERENCE_P. * parser.c (cp_parser_parse_and_diagnose_invalid_type_name): Avoid duplicate ambiguity error. * error.c (dump_decl): Don't say typedef for injected-class-name. * pt.c (convert_template_argument): Tweak logic. Added: trunk/gcc/testsuite/g++.dg/template/injected1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/error.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/search.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/inherit.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash56.C trunk/gcc/testsuite/g++.old-deja/g++.pt/lookup8.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp22.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp23.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13950
[Bug bootstrap/41399] [4.5 Regression] Internal error compiling fortran/intrinsic.c
--- Comment #9 from danglin at gcc dot gnu dot org 2009-11-17 00:19 --- Regarding http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00822.html, the sched1 pass is also a big memory hog. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at arm dot com Last reconfirmed|2009-10-23 20:39:09 |2009-11-17 00:19:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41399
[Bug lto/42074] New: gcc.dg/torture/builtin-math-7.c failed
I installed MPC 0.8 on Linux/ia32 and Linux/x86-64. With revision 154212, I got FAIL: gcc.dg/torture/builtin-math-7.c -O2 -flto execution test FAIL: gcc.dg/torture/builtin-math-7.c -O2 -fwhopr execution test -- Summary: gcc.dg/torture/builtin-math-7.c failed Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-11-17 00:37 --- Created an attachment (id=19027) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19027action=view) gdb walk from _Jv_Throw breakpoint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-11-17 00:39 --- The attached unwinder_walk.txt is the log of walk of ecj1 when compiling the testme,java test code. This uses r154217 with the patch from comment 3 and with the installed libgcc replaced with a copy compiled with -O0. The walk begins at the _Jv_Throw breakpoint. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug c++/13950] [DR176] lookup of dependent base name
--- Comment #6 from jason at gcc dot gnu dot org 2009-11-17 01:34 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13950
[Bug lto/42074] gcc.dg/torture/builtin-math-7.c failed
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-17 01:47 --- I'm also seeing this. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-17 01:47:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
[Bug target/41993] [sh] ICE in create_pre_exit, at mode-switching.c:399
--- Comment #2 from iwamatsu at nigauri dot org 2009-11-17 02:55 --- Hi, Kojima-san. Thank you for your work and patch . I checked this patch. Work fine with gcc-4.3.4 , gcc-4.4.2 and gcc/HEAD. BTW, I guess that __builtin_apply/__builtin_return may be a bit obsolete. If my memory is correct, there was an argument on the list for dropping them from the compiler. I dont know this infomation. Thank you. I will check this. -- iwamatsu at nigauri dot org changed: What|Removed |Added CC||iwamatsu at nigauri dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993
[Bug lto/42074] gcc.dg/torture/builtin-math-7.c failed
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-11-17 03:56 --- On x86_64-apple-darwin10 with MPC 0.8, we are getting... FAIL: gcc.dg/torture/builtin-math-7.c -O0 execution test FAIL: gcc.dg/torture/builtin-math-7.c -O1 execution test FAIL: gcc.dg/torture/builtin-math-7.c -O2 execution test FAIL: gcc.dg/torture/builtin-math-7.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/torture/builtin-math-7.c -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gcc.dg/torture/builtin-math-7.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gcc.dg/torture/builtin-math-7.c -O3 -g execution test FAIL: gcc.dg/torture/builtin-math-7.c -Os execution test in r154232. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
[Bug c++/189] [DR176] parse error in qualified member name lookup
--- Comment #12 from jason at gcc dot gnu dot org 2009-11-17 04:02 --- Heh, wish I had noticed Nathan's patch before reimplementing it. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|nathan at gcc dot gnu dot |jason at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=189
[Bug c++/189] [DR176] parse error in qualified member name lookup
--- Comment #13 from jason at gcc dot gnu dot org 2009-11-17 04:03 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=189
[Bug c++/9937] [DR 176] Base class template name is not injected properly into derived class
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-17 04:03 --- *** This bug has been marked as a duplicate of 189 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9937
[Bug c++/189] [DR176] parse error in qualified member name lookup
--- Comment #14 from jason at gcc dot gnu dot org 2009-11-17 04:03 --- *** Bug 9937 has been marked as a duplicate of this bug. *** -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||witt at ive dot uni-hannover ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=189
[Bug c++/13950] [DR176] lookup of dependent base name
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-17 04:04 --- *** This bug has been marked as a duplicate of 189 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13950
[Bug c++/189] [DR176] parse error in qualified member name lookup
--- Comment #15 from jason at gcc dot gnu dot org 2009-11-17 04:04 --- *** Bug 13950 has been marked as a duplicate of this bug. *** -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=189
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-11-17 04:17
---
The offending patch is in 4.4 r148732, r148731 passes the test case.
--- branches/gcc-4_4-branch/gcc/fortran/resolve.c 2009/04/03 20:56:54
145519
+++ branches/gcc-4_4-branch/gcc/fortran/resolve.c 2009/06/19 22:10:45
148732
@@ -9430,9 +9430,12 @@
static gfc_try
next_data_value (void)
{
-
while (mpz_cmp_ui (values.left, 0) == 0)
{
+ if (!gfc_is_constant_expr (values.vnode-expr))
+ gfc_error (non-constant DATA value at %L,
+ values.vnode-expr-where);
+
if (values.vnode-next == NULL)
return FAILURE;
I suspect that gfc_is_constant_expr is clobbering something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-11-17 04:29 --- I have confirmed on trunk that removing that snippet clears the regression. Looking at gfc_is_constant_expr we see a call to array.c (gfc_constant_ac) which does indeed modify the expr. So we have a bad side effect going on here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-11-17 05:35 --- I propose fixing this at gfc_consant_ac which has the following comment: /* Given an array constructor, determine if the constructor is constant or not by expanding it and making sure that all elements are constants. This is a bit of a hack since something like (/ (i, i=1,1) /) will take a while as* opposed to a more clever function that traverses the expression tree. FIXME. */ We should just be able to traverse the expression tree. I have manually done so with a few test cases and one does indeed end up with a BT_CONSTANT. I will see what I can come up with. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug c++/189] [DR176] parse error in qualified member name lookup
--- Comment #16 from jason at gcc dot gnu dot org 2009-11-17 05:58 --- Subject: Bug 189 Author: jason Date: Tue Nov 17 05:58:03 2009 New Revision: 154235 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154235 Log: PR c++/189, c++/9937, c++/13950, DR 176 * g++.dg/tc1/dr176.C: Adjust. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tc1/dr176.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=189
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #17 from sgk at troutmask dot apl dot washington dot edu 2009-11-17 06:03 --- Subject: Re: [4.5/4.4 Regression] data statement with nested type constructors On Tue, Nov 17, 2009 at 05:35:33AM -, jvdelisle at gcc dot gnu dot org wrote: - Comment #16 from jvdelisle at gcc dot gnu dot org 2009-11-17 05:35 --- I propose fixing this at gfc_consant_ac which has the following comment: /* Given an array constructor, determine if the constructor is constant or not by expanding it and making sure that all elements are constants. This is a bit of a hack since something like (/ (i, i=1,1) /) will take a while as* opposed to a more clever function that traverses the expression tree. FIXME. */ We should just be able to traverse the expression tree. I have manually done so with a few test cases and one does indeed end up with a BT_CONSTANT. I will see what I can come up with. Be careful, if I remember correctly, this can be an O(n**2) problem. OTOH, nice sleuthing! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug c++/5786] array types decay too quickly
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-09-04 18:29:24 |2009-11-17 06:05:20 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5786
[Bug c++/5786] array types decay too quickly
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-17 06:05 --- This seems to be fixed for 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5786
[Bug c++/5786] array types decay too quickly
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-17 06:06 --- . -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5786
[Bug c++/42059] [4.4/4.5 Regression] [c++0x] ICE with initializer list for VLA
--- Comment #2 from jakub at gcc dot gnu dot org 2009-11-17 06:59 --- Subject: Bug 42059 Author: jakub Date: Tue Nov 17 06:59:13 2009 New Revision: 154237 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154237 Log: PR c++/42059 * typeck.c (cp_build_modify_expr): For initializer list call check_array_initializer to make sure lhs isn't a VLA. * g++.dg/cpp0x/initlist26.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42059
[Bug c++/42061] [4.4/4.5 Regression] [c++0x] ICE with invalid initializer list for reference
--- Comment #2 from jakub at gcc dot gnu dot org 2009-11-17 07:01 --- Subject: Bug 42061 Author: jakub Date: Tue Nov 17 07:01:18 2009 New Revision: 154238 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154238 Log: PR c++/42061 * call.c (reference_binding): Return NULL for initializer list with error operand inside of it. * g++.dg/cpp0x/initlist27.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist27.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42061
[Bug c++/42059] [4.4/4.5 Regression] [c++0x] ICE with initializer list for VLA
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-17 07:22 --- Subject: Bug 42059 Author: jakub Date: Tue Nov 17 07:21:43 2009 New Revision: 154239 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154239 Log: PR c++/42059 * typeck.c (cp_build_modify_expr): For initializer list call check_array_initializer to make sure lhs isn't a VLA. * g++.dg/cpp0x/initlist26.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/initlist26.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/typeck.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42059
[Bug c++/42061] [4.4/4.5 Regression] [c++0x] ICE with invalid initializer list for reference
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-17 07:27 --- Subject: Bug 42061 Author: jakub Date: Tue Nov 17 07:26:52 2009 New Revision: 154240 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154240 Log: PR c++/42061 * call.c (reference_binding): Return NULL for initializer list with error operand inside of it. * g++.dg/cpp0x/initlist27.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/initlist27.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/call.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42061
[Bug c++/42059] [4.4/4.5 Regression] [c++0x] ICE with initializer list for VLA
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-17 07:39 --- 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=42059
[Bug c++/42061] [4.4/4.5 Regression] [c++0x] ICE with invalid initializer list for reference
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-17 07:40 --- 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=42061
[Bug fortran/42041] Missing defs in omp_lib.h
--- Comment #3 from burnus at gcc dot gnu dot org 2009-11-17 07:56 --- Reopened based on comment 2 to make sure this is/remains on the radar -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42041
