[Bug testsuite/39537] overhaul printf formats and type casts in testsuite
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-24 06:54 --- Let's look at the testcases: g++.dg/ext/align1.C: a run testcase, the printf can be removed in this case. g++.old-deja/g++.law/operators28.C: An assemble only testcase so the undefined behavior is not invoked at runtime so it does not matter. gcc.dg/matrix/matrix-2.c: Weird as it has two dg-do, I don't know which one should be used here, but those changes look correct g++.dg/opt/alias2.C: that looks obviously correct. g++.old-deja/g++.abi/vbase1.C: Likewise. g++.old-deja/g++.brendan/template8.C: Again it only assembles the testcase so the undefined behavior does not matter. g++.old-deja/g++.eh/ptr1.C: that looks obviously correct. g++.old-deja/g++.jason/access23.C: Just gets assembled so the undefined behavior does not matter. g++.old-deja/g++.law/cvt8.C: Likewise. g++.old-deja/g++.mike/net35.C: that looks obviously correct. g++.old-deja/g++.mike/offset1.C: Likewise. g++.old-deja/g++.mike/p12306.C: That code is obviously dead code, it is if(0) out so maybe it should be removed ... g++.old-deja/g++.mike/p3579.C: : that looks obviously correct. g++.old-deja/g++.mike/p3708a.C: Likewise. g++.old-deja/g++.mike/p3708b.C: Likewise. g++.old-deja/g++.mike/p3708.C: Likewise. g++.old-deja/g++.mike/p646.C: Just gets assembled so the undefined behavior does not matter. g++.old-deja/g++.mike/p710.C: Likewise. g++.old-deja/g++.mike/p789a.C: that looks obviously correct. g++.old-deja/g++.mike/pmf2.C: Likewise. g++.old-deja/g++.mike/temp.C: Likewise. g++.old-deja/g++.other/temporary1.C: Likewise. g++.old-deja/g++.other/virtual8.C: Likewise. g++.old-deja/g++.pt/memtemp23.C: This testcase just links so the undefined behavior does not matter. g++.old-deja/g++.pt/memtemp24.C: Likewise. g++.old-deja/g++.pt/memtemp25.C: Likewise. g++.old-deja/g++.pt/memtemp26.C: Likewise. g++.old-deja/g++.pt/t39.C: Looks wrong, it should use %p for even ptr[2], the printf itself does not matter. g++.old-deja/g++.robertl/eb17.: that looks obviously correct. gcc.dg/pch/inline-4.c: This does not matter as only the assembly is compared so calling printf with a non string constant is ok. In summary some of the changes are correct, others technically don't matter and really are really changing for the better as the testcase changes itself and changes what the testcase is testing and Ubuntu is broken for enabling those warnings by default even when testing GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |trivial http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39537
[Bug testsuite/39537] overhaul printf formats and type casts in testsuite
--- Comment #1 from kees at outflux dot net 2009-03-24 06:34 --- Created an attachment (id=17530) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17530&action=view) testsuite updates for format strings and casts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39537
[Bug testsuite/39537] New: overhaul printf formats and type casts in testsuite
Ubuntu's builds of GCC enable non-standard options (specifically -Wformat-security and -Wformat). In an attempt to maintain parity with the upstream testsuite output, I've gone through the testsuite and located many architecture-dependent format-string/type discontinuities (e.g. %d should be %ld for a pointer on x86_64). This patch seeks to address all the mismatches through a standardized use of %p with (void*), and in several cases, a forced (int) cast. Are these changes interesting? I am hoping they are not needlessly invasive, but I am obviously open to feedback. -- Summary: overhaul printf formats and type casts in testsuite Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kees at outflux dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39537
[Bug testsuite/39536] add more VERIFY() calls to certain functions in libstdc++-v3 testsuite
--- Comment #1 from kees at outflux dot net 2009-03-24 06:27 --- Created an attachment (id=17529) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17529&action=view) more VERIFY() calls in libstdc++ testsuite -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39536
[Bug testsuite/39536] New: add more VERIFY() calls to certain functions in libstdc++-v3 testsuite
This patch adds additional calls to VERIFY() on several functions to catch additional error conditions. -- Summary: add more VERIFY() calls to certain functions in libstdc++-v3 testsuite Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kees at outflux dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39536
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #9 from aran at 100acres dot us 2009-03-24 06:16 --- Created an attachment (id=17528) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17528&action=view) Removes problematic fixincludes and defines _ANSI_H in stddef.h This is a combination of the other two patches. GCC's version of stddef.h is still installed and fixed for NetBSD. The copy of sys/types.h is not installed. -- aran at 100acres dot us changed: What|Removed |Added Attachment #16724|0 |1 is obsolete|| Attachment #17333|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug debug/39527] wrong function name and line numbers with -g -O2 option
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-24 05:16 --- *** Bug 39535 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39527
[Bug debug/39535] wrong function name and line numbers with -g -O2 option
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-24 05:16 --- Please reopen PR 39527 if it is a GCC issue. As far as I can tell it is not a GCC issue from looking at the debugging information from i686-linux-gnu. *** This bug has been marked as a duplicate of 39527 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39535
[Bug c++/38030] [4.2/4.3 Regression] name-lookup for non-dependent name in template function is wrong
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-03-24 05:14 --- *** Bug 39534 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||anubhav dot saxena at wipro ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38030
[Bug c++/39534] Template name lookup
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-24 05:14 --- *** This bug has been marked as a duplicate of 38030 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39534
[Bug c++/39534] Template name lookup
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-24 05:12 --- 4.3.3 and 4.4.0 both print 2122. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39534
[Bug debug/39535] New: wrong function name and line numbers with -g -O2 option
With -g -O2 option, crx-elf-gcc generates wrong line numbers and function
names.
==
/tmp/ccrrZsJf.o: In function `090312 (experimental)':
/home10/swami/test.c:5: undefined reference to `_f1'
collect2: ld returned 1 exit status
===
Expected output could be:
===
/tmp/ccEJcFRs.o: In function `main':
/home10/swami/test.c:6: undefined reference to `_f1'
collect2: ld returned 1 exit status
testcase: "test.c"
int f = 1;
extern int f1 ();
main () {
f1();
}
===
--
Summary: wrong function name and line numbers with -g -O2 option
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: MR dot Swami dot Reddy at nsc dot com
GCC host triplet: Native Linux
GCC target triplet: crx-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39535
[Bug debug/39527] wrong function name and line numbers with -g -O2 option
--- Comment #2 from MR dot Swami dot Reddy at nsc dot com 2009-03-24 04:51 --- Subject: Re: wrong function name and line numbers with -g -O2 option rguenth at gcc dot gnu dot org wrote: > > --- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-23 13:47 > --- > This is a binutils issue. The error is reported with the location of the > calling function, not the call. Yes, this issue need to fixed in gcc and binutils also. I am working on this issue and will send the patch soon. Thanks Swami -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39527
[Bug c++/39534] New: Template name lookup
Hi,
I expect this code to print 2122 but it instead prints .
#include
using namespace std;
namespace my{
struct S{};
void f(S s, double d = 0){cout << "1";}
}
template
void h(){ T t; my::S s;
f(t, 0);// Line 1
f(s, 0);// Line 2
}
namespace my{ // reopen the namespace and add another overloaded function.
void f(S s, int d = 0){cout << "2";}
}
template
void g(){ T t; my::S s;
f(t, 0); // Line 3
f(s, 0); // Line 4
}
int main(){ h();
g();
Regards,
Anubhav.
--
Summary: Template name lookup
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anubhav dot saxena at wipro dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39534
[Bug preprocessor/39533] -MM may list a header file twice
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-24 01:50 --- If I do cat > foo.h << EOF #include EOF I get the duplicated include file but I don;t think it matters as it is included twice, how does the cpp know they are really the same include file -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |trivial http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
[Bug preprocessor/39533] -MM may list a header file twice
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-24 01:48 --- This testcase is not complete, it does not include foo.h. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
[Bug fortran/39528] [4.0/4.1/4.2/4.3/4.4 Regression] repeated entries are not read when using list-directed input
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-03-24 01:15 --- I will give this a shot. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-03-23 19:26:59 |2009-03-24 01:15:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39528
[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-23 23:21 --- Subject: Bug 39524 Author: jakub Date: Mon Mar 23 23:21:38 2009 New Revision: 145018 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145018 Log: PR debug/39524 * dwarf2out.c (gen_variable_die): Avoid adding duplicate declaration nodes. * g++.dg/debug/dwarf2/imported-decl-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-decl-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524
[Bug libmudflap/38462] test libmudflap.c/fail27-frag.c fails output pattern test for ppc64
--- Comment #1 from fche at redhat dot com 2009-03-23 22:53 --- (In reply to comment #0) > Here there is only one nearby object; argv[] and environ[] are missing. [...] > Should the objects argv and environ be reported in the -m64 output. I believe so, because those globals are supposed to be registered with the mudflap runtime, though they might be too far from buffer[] to be listed, so we should not depend on this. The real problem seems to be that test case should expect "mudflap dead object" rather than "mudflap object" to match buffer[], just like you say. -- fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38462
[Bug ada/36939] Build Failure Ada SH2e
--- Comment #13 from joel at gcc dot gnu dot org 2009-03-23 22:14 --- *** Bug 21377 has been marked as a duplicate of this bug. *** -- joel at gcc dot gnu dot org changed: What|Removed |Added CC||corsepiu at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939
[Bug target/21377] Error detected at a-stmaco.ads:65:4
--- Comment #3 from joel at gcc dot gnu dot org 2009-03-23 22:14 --- This is very old and most likely fixed since it looks like sh-rtems builds Ada further. Marking this as a dupe so it will die. *** This bug has been marked as a duplicate of 36939 *** -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
[Bug target/36834] structure return ABI for windows targets differs from native MSVC
--- Comment #11 from dannysmith at users dot sourceforge dot net
2009-03-23 22:10 ---
(In reply to comment #10)
> Note that C++ objects need not be larger than 8 bytes to qualify for returning
> on the stack (and thus subject to this cleanup problem). Any class with a copy
> constructor, for example, seems to be affected.
Thanks. I understand your concern now.
Do you think that a function __attibute__((ms-aggregate-return)) would be
useful to specify individual problematic functions.
I expect that this would be equivalent to
(__attribute__((target("ms-aggregate-return"))) which should work now, but I
haven't tested, Will do so soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
[Bug preprocessor/39533] -MM may list a header file twice
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-23 21:44 --- Created an attachment (id=17527) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17527&action=view) A testcase # gcc -MM x.c -Iinclude x.o: x.c foo.h include/ansidecl.h include/libiberty.h include/ansidecl.h include/ansidecl.h is listed twice. Icc 11.1 generates: [...@gnu-6 dep-1]$ /opt/intel/cce/11.1/bin/icc -MM x.c -Iinclude x.o: x.c foo.h include/ansidecl.h include/libiberty.h [...@gnu-6 dep-1]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
[Bug preprocessor/39533] -MM may list a header file twice
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-23 21:39 --- Example? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
[Bug preprocessor/39533] New: -MM may list a header file twice
"gcc -MM" may list a header file twice. -- Summary: -MM may list a header file twice Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor 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=39533
[Bug fortran/39532] fortran 95 parsing trouble
--- Comment #4 from kargl at gcc dot gnu dot org 2009-03-23 21:30 --- Confirmed with Patrick that the source code is assumed to be fixed-form by gfortran and the code contains lines longer than 72 characters. Patrick confirmed that the option -ffixed-line-length-none allows the code to compile. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39532
[Bug c++/37729] function parameter pack expansion doesn't work in late-specified return type
--- Comment #1 from jason at gcc dot gnu dot org 2009-03-23 21:14 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37729
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #8 from prlw1 at cam dot ac dot uk 2009-03-23 21:07 ---
What about the first patch, which seems less drastic? (I think it would be
better to install gcc's stddef.h, so there is one thing less to remember when
upgrading gcc) It seems that if our machine/ansi.h defined _MACHINE_ANSI_H_
rather than _${MACHINE}_ANSI_H_, things would be happier. The first patch
defines _ANSI_H_ instead. Hmm I'll try both and see...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug c/39495] OMP parallel loop w/ unsigned index var rejected
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-23 21:05 --- Subject: Bug 39495 Author: jakub Date: Mon Mar 23 21:05:30 2009 New Revision: 145014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145014 Log: PR c/39495 * c-parser.c (c_parser_omp_for_loop): Call c_parser_binary_expression instead of c_parser_expression_conv, if original_code isn't one of the 4 allowed comparison codes, fail. * semantics.c (handle_omp_for_class_iterator): Swap cond operands and code if iter is the second operand. * parser.c (cp_parser_binary_expression): Add no_toplevel_fold_p argument. If it is set, don't build the toplevel expression with build_x_binary_op, but build2. (cp_parser_assignment_expression, cp_parser_omp_for_incr): Adjust callers. (cp_parser_omp_for_cond): Don't assume the first operand of the comparison must be decl. * gcc.dg/gomp/pr39495-2.c: Remove xfails. * testsuite/libgomp.c/loop-12.c: New test. * testsuite/libgomp.c/loop-11.c: New test. * testsuite/libgomp.c++/loop-11.C: New test. * testsuite/libgomp.c++/loop-12.C: New test. * testsuite/libgomp.c++/for-8.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/for-8.C trunk/libgomp/testsuite/libgomp.c++/loop-11.C trunk/libgomp/testsuite/libgomp.c++/loop-12.C trunk/libgomp/testsuite/libgomp.c/loop-11.c trunk/libgomp/testsuite/libgomp.c/loop-12.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/gomp/pr39495-2.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39495
[Bug fortran/39528] [4.0/4.1/4.2/4.3/4.4 Regression] repeated entries are not read when using list-directed input
--- Comment #4 from dominiq at lps dot ens dot fr 2009-03-23 21:04 --- Jerry could you have a look at this one? TIA -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39528
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #7 from joseph at codesourcery dot com 2009-03-23 20:53 --- Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ On Mon, 23 Mar 2009, prlw1 at cam dot ac dot uk wrote: > --- Comment #6 from prlw1 at cam dot ac dot uk 2009-03-23 20:45 --- > (In reply to comment #5) > > The patch is obviously wrong (it changes the installed headers for all > > targets instead of setting USER_H to adjust the list for the target with > > this issue) > > Care to explain more re USER_H? I tried to addIndex: stddef.h USER_H is GCC's mechanism to disable installing some of the headers, such as stddef.h, that it installs by default. You're meant to set it in a target makefile fragment t-* instead of changing the global default definition in gcc/Makefile.in. Thus, if NetBSD should have all the GCC-provided headers except for stddef.h, copy the default from gcc/Makefile.in to gcc/config/t-netbsd and remove stddef.h there (with a comment to say that it's stddef.h that's being removed). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug c++/39526] [4.4 Regression] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #5 from jason at gcc dot gnu dot org 2009-03-23 20:52 --- Fixed. -- 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=39526
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #6 from prlw1 at cam dot ac dot uk 2009-03-23 20:45 ---
(In reply to comment #5)
> The patch is obviously wrong (it changes the installed headers for all
> targets instead of setting USER_H to adjust the list for the target with
> this issue)
Care to explain more re USER_H? I tried to addIndex: stddef.h
===
--- stddef.h(revision 145011)
+++ stddef.h(working copy)
@@ -62,6 +62,20 @@
#include
#endif
+#if defined(__NetBSD__)
+typedef _BSD_PTRDIFF_T_ ptrdiff_t;
+
+#ifdef _BSD_SIZE_T_
+typedef _BSD_SIZE_T_size_t;
+#undef _BSD_SIZE_T_
+#endif
+
+#ifdef _BSD_WCHAR_T_
+typedef _BSD_WCHAR_T_ wchar_t;
+#undef _BSD_WCHAR_T_
+#endif
+#endif /* __NetBSD__ */
+
/* In 4.3bsd-net2, machine/ansi.h defines these symbols, which are
defined if the corresponding type is *not* defined.
FreeBSD-2.1 defines _MACHINE_ANSI_H_ instead of _ANSI_H_ */
which allowed me to compile gfortran. libsup++ failed including time.h, which
behaved as though _BSD_SIZE_T_ was defined, but empty.
Simply put, if I gcc -E gcc/gcc/ginclude/stddef.h, size_t is not defined:
# 1 "stddef.h"
# 1 ""
# 1 ""
# 1 "stddef.h"
# 58 "stddef.h"
# 1 "/usr/include/machine/ansi.h" 1 3 4
# 37 "/usr/include/machine/ansi.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 59 "/usr/include/sys/cdefs.h" 3 4
# 1 "/usr/include/machine/cdefs.h" 1 3 4
# 60 "/usr/include/sys/cdefs.h" 2 3 4
# 1 "/usr/include/sys/cdefs_elf.h" 1 3 4
# 62 "/usr/include/sys/cdefs.h" 2 3 4
# 38 "/usr/include/machine/ansi.h" 2 3 4
# 1 "/usr/include/machine/int_types.h" 1 3 4
# 45 "/usr/include/machine/int_types.h" 3 4
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef short int __int16_t;
typedef unsigned short int __uint16_t;
typedef int __int32_t;
typedef unsigned int __uint32_t;
typedef long long int __int64_t;
typedef unsigned long long int __uint64_t;
typedef int __intptr_t;
typedef unsigned int __uintptr_t;
# 40 "/usr/include/machine/ansi.h" 2 3 4
# 73 "/usr/include/machine/ansi.h" 3 4
typedef union {
__int64_t __mbstateL;
char __mbstate8[128];
} __mbstate_t;
# 59 "stddef.h" 2
and machine/ansi.h defines _${MACHINE}_ANSI_H_ on NetBSD. If I gcc -E
/usr/include/stddef.h, size_t is defined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL
--- Comment #47 from danglin at gcc dot gnu dot org 2009-03-23 20:39
---
I hate PCH!
The reason a small change inhibits PCH file loading is the following:
/* If the text segment was not loaded at the same address as it was
when the PCH file was created, function pointers loaded from the
PCH will not be valid. We could in theory remap all the function
pointers, but no support for that exists at present.
Since we have the same executable, it should only be necessary to
check one function. */
if (v.pch_init != &pch_init)
{
if (cpp_get_options (pfile)->warn_invalid_pch)
cpp_error (pfile, CPP_DL_WARNING,
"%s: had text segment at different address", name);
return 2;
}
Since I wasn't rebuilding the libstdc++ PCH files when I hacked expr.c and
rebuilt cc1plus, I was effectively disabling PCH.
As a side note, the comparison of v.pch_init and &pch_init is dangerous
on targets that use function descriptors. The value v.pch_init was
recorded by a different binary, so it could point to garbage in the binary
performing the check.
So, we are left with the original PCH bug. Is the missing DECL_VALUE_EXPR
expected for PCH data?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #5 from joseph at codesourcery dot com 2009-03-23 20:35 --- Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ The patch is obviously wrong (it changes the installed headers for all targets instead of setting USER_H to adjust the list for the target with this issue) and patches need to be submitted to gcc-patches following the instructions: http://gcc.gnu.org/contribute.html (which includes explaining the patch and how it fixes the problem). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug c++/39526] [4.4 Regression] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #4 from jason at gcc dot gnu dot org 2009-03-23 20:33 --- Subject: Bug 39526 Author: jason Date: Mon Mar 23 20:32:53 2009 New Revision: 145012 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145012 Log: PR c++/39526 * name-lookup.c (pushdecl_maybe_friend): Don't warn about shadowing a parm with a parm. Added: trunk/gcc/testsuite/g++.dg/warn/Wshadow-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39526
[Bug fortran/39532] fortran 95 parsing trouble
--- Comment #3 from kargl at gcc dot gnu dot org 2009-03-23 20:25 --- (In reply to comment #2) > I just tried > > ifort -warn stderrors -std95 modules.f > > which didn't complain. It seems gfortran is unhappy about the parentheses > in that declaration. I included the parts before, so you can see that > nREBOspecies is defined... > Please attach the code! Browsers have a funny way of changing the formatting of code. In particular, are you using fixed-form source code with lines longer than 72 characters? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39532
[Bug fortran/39532] fortran 95 parsing trouble
--- Comment #2 from prlw1 at cam dot ac dot uk 2009-03-23 20:23 --- I just tried ifort -warn stderrors -std95 modules.f which didn't complain. It seems gfortran is unhappy about the parentheses in that declaration. I included the parts before, so you can see that nREBOspecies is defined... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39532
[Bug fortran/29962] Initialization expressions
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-03-23 20:03 --- Transformational intrinsics, one down: PACK (PR32890). Left: * all, any, count * maxloc, minloc * maxval, minval (generic case) * product, sum * dot_product, matmul, transpose * unpack, spread * cshift, eoshift -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug fortran/39532] fortran 95 parsing trouble
--- Comment #1 from kargl at gcc dot gnu dot org 2009-03-23 20:01 --- Please attach the offending code. Also, ifort has an option for fairly strict conformance to the Fortran 95 standard. Does the code compile with this option. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39532
[Bug fortran/39532] New: fortran 95 parsing trouble
Program extract: ... module brennerdata use datatypes use element,only : maxele integer(i4), save :: nbrennertype = 3 integer(i4),parameter :: nREBOspecies = 4 integer(i4), save :: nREBOspecies2 logical, save :: lbP_CHdone(0:3,0:3,3) logical, save :: lbPdone(0:3,0:3,nREBOspecies*(nREBOspecies+ 1)/2,nREBOspecies) ... logical, save :: lbPdone(0:3,0:3,nREBOspecies*(nREBO 1 Error: Missing ')' in statement at or before (1) with gfortran 4.4.0 source of 16 March 2009. I believe this is correct F95, and the intel compiler is happy with it. (This may be a duplicate of another bug, but what would good search terms be?) -- Summary: fortran 95 parsing trouble Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: prlw1 at cam dot ac dot uk GCC build triplet: i386-unknown-netbsdelf5.99.8 GCC host triplet: i386-unknown-netbsdelf5.99.8 GCC target triplet: i386-unknown-netbsdelf5.99.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39532
[Bug fortran/29962] Initialization expressions
--- Comment #12 from dfranke at gcc dot gnu dot org 2009-03-23 19:56 --- *** Bug 38205 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug fortran/38205] Tranformational function SUM rejected in initialization expressions
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-03-23 19:56 --- *** This bug has been marked as a duplicate of 29962 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38205
[Bug fortran/32890] Compile-time detect of LHS/RHS missmatch for PACK
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-03-23 19:33 --- Subject: Bug 32890 Author: dfranke Date: Mon Mar 23 19:33:39 2009 New Revision: 145011 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145011 Log: gcc/fortran/: 2009-03-23 Daniel Franke PR fortran/32890 * intrinsic.h (gfc_simplify_pack): New prototype. * intrinsic.c (add_functions): Added simplifier-callback to PACK. * simplify.c (is_constant_array_expr): Moved to beginning of file. (gfc_simplify_pack): New. * check.c (gfc_check_pack): Check that VECTOR has enough elements. gcc/testsuite/: 2009-03-23 Daniel Franke PR fortran/32890 * gfortran.dg/pack_assign_1.f90: New. * gfortran.dg/pack_vector_1.f90: New. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/pack_assign_1.f90 branches/fortran-dev/gcc/testsuite/gfortran.dg/pack_vector_1.f90 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.dev branches/fortran-dev/gcc/fortran/check.c branches/fortran-dev/gcc/fortran/intrinsic.c branches/fortran-dev/gcc/fortran/intrinsic.h branches/fortran-dev/gcc/fortran/simplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32890
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #4 from prlw1 at cam dot ac dot uk 2009-03-23 19:31 --- Just hit this bug. Either solution looks good (am about to test, but spent ages reaching the same conclusion, so expect success for both) Anyone from gcc listening? -- prlw1 at cam dot ac dot uk changed: What|Removed |Added CC||prlw1 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug fortran/39528] [4.0/4.1/4.2/4.3/4.4 Regression] repeated entries are not read when using list-directed input
--- Comment #3 from jv244 at cam dot ac dot uk 2009-03-23 19:26 --- good old Fortran.. (fine with NAG as well) -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.0 4.3.3 4.2.3 Known to work||3.4.5 Last reconfirmed|-00-00 00:00:00 |2009-03-23 19:26:59 date|| Summary|gfortran: repeated entries |[4.0/4.1/4.2/4.3/4.4 |are not read when using |Regression] repeated entries |list-directed input |are not read when using ||list-directed input http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39528
[Bug target/39531] m68k gcc does not convert andil to bclr when compiled on a 64bit host
--- Comment #1 from radford at blackbean dot org 2009-03-23 19:13 --- Created an attachment (id=17526) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17526&action=view) Fix output_andsi3 to correctly convert andil to bclr when compiler runs on a 64bit host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39531
[Bug c/39531] New: m68k gcc does not convert andil to bclr when compiled on a 64bit host
The following function will use a bclr on a 32 bit host and a andil on a 64bit
host.
int f(int x) { return x & 0x7fff; }
This is caused by a missing & 0x the expression
exact_log2 (~ INTVAL (operands[2])))
in output_andsi3.
--
Summary: m68k gcc does not convert andil to bclr when compiled on
a 64bit host
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: radford at blackbean dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39531
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #48 from pluto at agmk dot net 2009-03-23 19:00 --- with the latest patch applied on top of 4.4-svn i get following diagnostic for simple code snippet: $ cat 14912-2.cpp #include std::string s = 7; $ /opt/gcc44/bin/g++ -c -Wall -O2 14912-2.cpp 14912-2.cpp:2: error: invalid conversion from 'int' to 'const char*' 14912-2.cpp:2: error: initializing argument 1 of 'std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits, _Alloc = std::allocator]' defaults are still printed in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/39530] [regression] runtime_error text not shown
--- Comment #1 from shadow2531 at gmail dot com 2009-03-23 18:49 --- Created an attachment (id=17525) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17525&action=view) .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39530
[Bug c++/39530] New: [regression] runtime_error text not shown
#include
using namespace std;
int main() {
throw runtime_error("ouch");
}
// g++ -Wall -Wextra test.cc -o test -O3 -s
// g++ (GCC) 4.3.3-dw2-tdm-1
// WinXP SP3
// CMD.exe
Result:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Expected:
"ouch" should be shown somewhere in there. It used to be in < 4.3.
--
Summary: [regression] runtime_error text not shown
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shadow2531 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39530
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #7 from gbarnt at student dot dtu dot dk 2009-03-23 18:42 --- Created an attachment (id=17524) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17524&action=view) Same as previous - except for the -lib error. This patch replaces my old patch and does not break the --with-gmp-lib and --with-mpfr-lib (I had used the wrong variable - too much copy/paste). Aside from that, it is exactly like the old patch. This patch (also) requires autoconf to be run afterwards. Patch was created with: u...@host$ diff -Naur gcc-old/configure.ac gcc-new/configure.ac > gcc-4.3.3_runtime_link.patch ~Niels -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #6 from gbarnt at student dot dtu dot dk 2009-03-23 18:38 --- (From update of attachment 17522) Sorry, too much copy-paste in the patch... re-uploading a new patch that does not break --with-(gmp|mpfr)-lib. -- gbarnt at student dot dtu dot dk changed: What|Removed |Added Attachment #17522|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug tree-optimization/39529] ICE on valid code
--- Comment #1 from edmar at freescale dot com 2009-03-23 18:36 --- Created an attachment (id=17523) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17523&action=view) Here is the patch I used -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39529
[Bug tree-optimization/39529] New: ICE on valid code
The compiler gives ICE on valid code.
Invocation:
gcc -O3 -S x.c
Test case:
void
foo (void)
{
char a[1024];
char *p = &a[0];
char *p2;
p2 = p + 1024;
do
{
p += 2;
*(p-2) = 1;
*(p-1) = 1;
} while (p < p2);
}
Output:
x.c: In function 'foo':
x.c:3: error: missing definition
for SSA_NAME: SMT.9_14 in statement:
SMT.9_8 = PHI
PHI argument
SMT.9_14
for PHI node
SMT.9_8 = PHI
x.c:3: internal compiler error: verify_ssa failed
Description:
Bellow is x.c.106t.vect for target PowerPC 603e, but the same ICE
happens for altivec and for x86_64. The vectorizer replaces the two
original stores with one vector store, leaving behind a bad SMT phi
node.
Pass statistics:
Vectorized loops: 1
Merging blocks 2 and 6
foo ()
{
unsigned intD.3 ivtmp.31D.1297;
vector charD.1 * ivtmp.30D.1296;
vector charD.1 * vect_pa.29D.1295;
vector charD.1 * vect_pa.25D.1291;
vector charD.1 vect_cst_.24D.1290;
unsigned intD.3 ivtmp.23D.1283;
charD.1 * p2D.1254;
charD.1 * pD.1253;
charD.1 aD.1252[1024];
charD.1 * D.1258;
# BLOCK 2 freq:100
# PRED: ENTRY [100.0%] (fallthru,exec)
p2D.1254_3 = &aD.1252 + 1024;
vect_cst_.24D.1290_18 = { 1, 1, 1, 1 };
vect_pa.29D.1295_19 = (vector charD.1 *) &aD.1252;
vect_pa.25D.1291_20 = vect_pa.29D.1295_19;
# SUCC: 3 [100.0%] (fallthru)
# BLOCK 3 freq:1
# PRED: 2 [100.0%] (fallthru) 4 [100.0%] (fallthru,dfs_back,exec)
# ivtmp.31D.1297_23 = PHI <0(2), ivtmp.31D.1297_24(4)>
# ivtmp.30D.1296_21 = PHI
# ivtmp.23D.1283_16 = PHI <512(2), ivtmp.23D.1283_17(4)>
# SMT.9D.1269_8 = PHI
# =
# aD.1252_7 = PHI
# pD.1253_1 = PHI <&aD.1252(2), pD.1253_4(4)>
pD.1253_4 = pD.1253_1 + 2;
# aD.1252_25 = VDEF { aD.1252 }
*ivtmp.30D.1296_21 = vect_cst_.24D.1290_18;
D.1258_6 = pD.1253_4 + -1;
ivtmp.23D.1283_17 = ivtmp.23D.1283_16 - 1;
ivtmp.30D.1296_22 = ivtmp.30D.1296_21 + 4;
ivtmp.31D.1297_24 = ivtmp.31D.1297_23 + 1;
if (ivtmp.31D.1297_24 < 256)
goto ;
else
goto ;
# SUCC: 4 [99.0%] (true,exec) 5 [1.0%] (false,exec)
# BLOCK 4 freq:9900
# PRED: 3 [99.0%] (true,exec)
goto ;
# SUCC: 3 [100.0%] (fallthru,dfs_back,exec)
# BLOCK 5 freq:100
# PRED: 3 [1.0%] (false,exec)
return;
# SUCC: EXIT [100.0%]
}
My solution:
After each loop is vectorized, and SSA is updated, I re-compute alias
info. I am not familiar with the vectorizer sources, so I don't know
if there is a more efficient way to fix this problem, and still be
sure it would be correct for all inputs.
This attached patch fixed the problem for 603e, altivec, and
x86_64. Regression tests done for 603e and it is under way for x86_64.
--
Summary: ICE on valid code
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edmar at freescale dot com
GCC build triplet: powerpc-unknown-linux-gnu
GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39529
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #7 from basile at starynkevitch dot net 2009-03-23 18:16 --- fopencookie is removed in rev145010 of MELT branch. I'm using a temporary kludge , calling an unstable function inside PPL. So You'll need a recent PPL snapshot (obtained thru GIT). http://www.cs.unipr.it/pipermail/ppl-devel/2009-March/014162.html Better fix will be available after PPL gets a better function to debugprint inside a string buffer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug target/35180] built-in-setjmp.x2
--- Comment #11 from joel at gcc dot gnu dot org 2009-03-23 17:56 --- Closing. This found an issue in the RTEMS ta 3 trap handler. Resolved on the RTEMS side. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug fortran/39528] gfortran: repeated entries are not read when using list-directed input
--- Comment #2 from dominiq at lps dot ens dot fr 2009-03-23 17:39 --- It is a regression with respect to g77. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39528
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #5 from gbarnt at student dot dtu dot dk 2009-03-23 17:23 --- Sadly my skills with bugzilla's haven't improved. I meant to have the following accompany the patch above: This issue is also present on an x86_64 red hat linux in gcc-4.3.3. Usage of --with-gmp and --with-mpfr does not add the path to the run-time dependencies (see ld's -rpath flag). Configured with --with-gmp=$HOME/softInstall_blades/ --with-mpfr=$HOME/softInstall_blades my x86_64-unknown-linux-gnu/libgcc/config.log (home folder replaced by ~): ~/software/gcc_2build/./gcc/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or direc tory ldd gcc/cc1 yields: libmpfr.so.1 => not found libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00329620) libc.so.6 => /lib64/libc.so.6 (0x003365a0) /lib64/ld-linux-x86-64.so.2 (0x00336560) Notice that it wrongly located the libgmp in /usr/lib64, when I explicitly asked for it to use the gmp in subdir of my home folder. I do not have root access to this machine (university) so most (read: all) our software is installed in non-standard paths - else I would just have upgraded/installed gmp/mpfr via yum (red hat's package manager) and called it a day. Manually adding LDFLAGS="-Wl,-rpath,[dir]" does not work (it still found the wrong dirs). The "crle" approach is not possible (it is not a sun/solaris machine). Looking at configure.ac (gcc-root folder - line: 1191) the variables set by --with-gmp only adds "-L". Manually appending "-Wl,-rpath,[dir variable]" to the lib-part worked for me, though "-Wl,-R,[dir variable]" is probably more portable (since gnu ld translates -R [dir] into -rpath [dir] and solaris uses -R [dir]). I have not tested if this solution allows [dir variable] to contain spaces. For other users suffering this: modification of configure.ac requires autoconf to update the "configure" script. ~Niels -- gbarnt at student dot dtu dot dk changed: What|Removed |Added CC||gbarnt at student dot dtu ||dot dk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #4 from gbarnt at student dot dtu dot dk 2009-03-23 17:22 --- Created an attachment (id=17522) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17522&action=view) Patch adding -Wl,-R,[dir] to --with-gmp/mpfr(-lib)? Patch that adds linker flags "-Wl,-R,[dir]" to the linker flags generated by the --with-gmp-lib, --with-gmp, --with-mpfr and --with-mpfr-lib options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug rtl-optimization/24319] [4.2/4.3/4.4 regression] amd64 register spill error with -fschedule-insns
--- Comment #12 from vmakarov at redhat dot com 2009-03-23 17:04 --- I started my work on register pressure sensitive insn scheduling recently. This bug will be fixed as byproduct of this work. I hope the code will be available for gcc4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
[Bug target/38549] [avr] eicall not properly set for > 128K program space
-- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-23 16:43:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549
[Bug target/38057] [AVR] ATMega2561 wrong addressing (probably eicall).
--- Comment #2 from eric dot weddington at atmel dot com 2009-03-23 16:42 --- *** This bug has been marked as a duplicate of 38549 *** -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38057
[Bug target/38549] [avr] eicall not properly set for > 128K program space
--- Comment #4 from eric dot weddington at atmel dot com 2009-03-23 16:42 --- *** Bug 38057 has been marked as a duplicate of this bug. *** -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||optech_tr at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549
[Bug target/38549] [avr] eicall not properly set for > 128K program space
--- Comment #3 from thiago dot correa at gmail dot com 2009-03-23 16:33 --- Bug #38057 reports the same issue. Perhaps this should be changed to CONFIRMED and one of the bug reports set as duplicate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549
[Bug c++/39526] [4.4 Regression] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #3 from jason at gcc dot gnu dot org 2009-03-23 15:32 --- The problem is that we're pushing declarations for parameters while tentatively parsing that as a function declaration. Oops. -- 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|2009-03-23 13:45:05 |2009-03-23 15:32:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39526
[Bug target/32348] ICE on valid code
--- Comment #3 from edmar at freescale dot com 2009-03-23 15:13 --- Ben, this bug is almost 2 years old. I don't remember what we did to resolve the issue. I am surprised to find it is still open. I am going try to close it. Edmar -- edmar at freescale dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32348
[Bug fortran/39528] gfortran: repeated entries are not read when using list-directed input
--- Comment #1 from dominiq at lps dot ens dot fr 2009-03-23 15:10 --- Confirmed on powerpc-apple-darwin9 for trunk, 4.3.3, and 4.2.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39528
[Bug fortran/39528] New: gfortran: repeated entries are not read when using list-directed input
When I read repeated entries using list-directed input and I use a slash to terminate the read, the number of entries read in the last series depends on the position of the closing slash. In addition, an additional entry at the end corrects the problem. The test program: program rread implicit none integer :: iarr(1:7), ia, ib, i do i=1,7 iarr(i)= 0 enddo read(*,*) (iarr(i), i=1,7) read(*,*) ia, ib write(*,*) (iarr(i), i=1,7) write(*,*) ia, ib end program rread Example input #1: 2*1 3*2 / 12 13 gfortran gives: 1 1 2 0 0 0 0 12 13 Intel fortran gives: 1 1 2 2 2 0 0 12 13 Example input #2: 2*1 3*2 / 12 13 Both gfortran and Intel fortran give: 1 1 2 2 2 0 0 12 13 Example input #3: 2*1 3*2 5 / 12 13 Both gfortran and Intel fortran give: 1 1 2 2 2 5 0 12 13 My system is the following: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ version of the kernel: Linux 2.6.18-6-amd64 #1 SMP Thu Dec 25 21:08:54 UTC 2008 x86_64 GNU/Linux I use gfortran from a chrooted Debian 5.0.0 (codename: lenny) system. (My outside system is a Debian 4.0 release7 (codename: etch) one.) gfortran -v -save-temps -o rrGF-bug ./rread.f90 Driving: gfortran -v -save-temps -o rrGF-bug ./rread.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'rrGF-bug' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.3.2/f951 ./rread.f90 -quiet -dumpbase rread.f90 -mtune=generic -auxbase rread -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/4.3.2/finclude -o rread.s GNU F95 (Debian 4.3.2-1.1) version 4.3.2 (x86_64-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2. warning: MPFR header version 2.3.2 differs from library version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'rrGF-bug' '-shared-libgcc' '-mtune=generic' as -V -Qy -o rread.o rread.s GNU assembler version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'rrGF-bug' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o rrGF-bug /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../.. rread.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crtn.o -- Summary: gfortran: repeated entries are not read when using list- directed input Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brolly at aeki dot kfki dot hu GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39528
[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-23 14:30 --- Created an attachment (id=17521) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17521&action=view) gcc44-pr39524.patch Argh, sorry, actually this patch, not the one I've attached in the previous comment. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #17520|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524
[Bug tree-optimization/39516] [4.4 Regression] internal compiler error: in copy_to_mode_reg, at explow.c:623
--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-23 14:08 --- 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=39516
[Bug tree-optimization/39516] [4.4 Regression] internal compiler error: in copy_to_mode_reg, at explow.c:623
--- Comment #12 from jakub at gcc dot gnu dot org 2009-03-23 14:00 --- Subject: Bug 39516 Author: jakub Date: Mon Mar 23 14:00:34 2009 New Revision: 145008 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145008 Log: PR tree-optimization/39516 * lambda-code.c (perfect_nestify): Fix type of the uboundvar variable. * gfortran.dg/pr39516.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr39516.f Modified: trunk/gcc/ChangeLog trunk/gcc/lambda-code.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39516
[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-23 13:52 --- Created an attachment (id=17520) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17520&action=view) gcc44-pr39524.patch Modified Dodji's patch I've actually bootstrapped/regtested (neither of the patches caused any regressions). I've moved the test after Fortran COMMON handling, there we update the DW_AT_location if it was missing before etc., and added a check if the preexisting old_die is in the right context just to be sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524
[Bug c/39525] [easy to fix bug] Docs for C99 "designated initializers" isn't clear what happens to omitted field members
--- Comment #2 from mnemo at minimum dot se 2009-03-23 13:48 --- If you could just add that info in a single sentence to the GCC docs, it would be very helpful for end users. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39525
[Bug debug/39527] wrong function name and line numbers with -g -O2 option
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-23 13:47 --- This is a binutils issue. The error is reported with the location of the calling function, not the call. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39527
[Bug c++/39526] [4.4 Regression] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-23 13:45 --- Regressed in r140120 (PR37302). Similar testcase where infoo is a global variable also starts failing at that revision. Jason, can you please have a look at this? Isn't infoo just an argument passed to a ctor, not a shadowing declaration of the infoo argument (or global var)? -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-23 13:45:05 date|| Summary|-Wshadow reports shadowed |[4.4 Regression] -Wshadow |declarations for parameters |reports shadowed |of unnamed temp objects |declarations for parameters ||of unnamed temp objects Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39526
[Bug c/39525] [easy to fix bug] Docs for C99 "designated initializers" isn't clear what happens to omitted field members
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-23 13:30 --- Hmm, how so? The C standard is clear that these fields are zero initialized if omitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39525
[Bug debug/39527] New: wrong function name and line numbers with -g -O2 option
With -g -O2 option, crx-elf-gcc generates wrong line numbers and function
names.
==
/tmp/ccrrZsJf.o: In function `090312 (experimental)':
/home10/swami/test.c:5: undefined reference to `_f1'
collect2: ld returned 1 exit status
===
Expected output could be:
===
/tmp/ccEJcFRs.o: In function `main':
/home10/swami/test.c:6: undefined reference to `_f1'
collect2: ld returned 1 exit status
testcase: "test.c"
int f = 1;
extern int f1 ();
main () {
f1();
}
===
--
Summary: wrong function name and line numbers with -g -O2 option
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: MR dot Swami dot Reddy at nsc dot com
GCC host triplet: Native Linux
GCC target triplet: crx-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39527
[Bug c++/39526] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #1 from caolanm at redhat dot com 2009-03-23 12:22 --- Created an attachment (id=17519) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17519&action=view) trivial demo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39526
[Bug c++/39526] New: -Wshadow reports shadowed declarations for parameters of unnamed temp objects
for the parameters passed to a C++ constructor when an unnamed temporary object is created and a method called on it i.e. following test-case reports... $ g++ -c -Wshadow demo.cxx demo.cxx: In function int foo(int): demo.cxx:10: warning: declaration of INetURLObject infoo shadows a parameter demo.cxx:8: warning: shadowed declaration is here $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog=/builddir/build/BUILD/gcc-4.4.0-20090307/cloog-ppl/inst/usr --with-tune=generic --with-arch_32=i586 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.0 20090307 (Red Hat 4.4.0-0.23) (GCC) -- Summary: -Wshadow reports shadowed declarations for parameters of unnamed temp objects Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: caolanm at redhat dot com GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39526
[Bug middle-end/39514] [4.4 Regression] unreported change to packed bitfields
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-03-23 11:47
---
> I'd like to see this message, which is on by default, for the change
> introduced in r132614. I haven't figured out how to determine if the offset
> for a field has changed, just the alignment. I'll attach my current patch,
> where the message should be "Perhaps the alignment of packed bit-field
> has changed in GCC 4.4", which is not terribly useful.
I think that's better (without the "perhaps", the alignment is always changed)
than "Offset" because this also can change the padding of the structure:
struct s
{
struct
{
__attribute__ ((aligned (2))) int d:32;
} __attribute__ ((packed)) c;
unsigned short int e;
};
yields (4, 8) with 4.3.3 and (4, 6) with mainline. This apparently will be so
uncommon in C/C++ (packed bit-field with alignment attribute) that I'm not sure
sure we need to tune it further.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39514
[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution
--- Comment #3 from jan dot kratochvil at redhat dot com 2009-03-23 11:32 --- One fix should be enough next time, thanks. Going to gdb-regression test both the patches (in Fedora GCC on Fedora 11). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524
[Bug middle-end/39514] [4.4 Regression] unreported change to packed bitfields
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-03-23 11:25 --- > Did behavior change if you remove the aligned (2) attribute from d? No, it didn't change without the attribute, it was and still is (10, 12). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39514
[Bug target/39482] [4.3 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478
--- Comment #7 from ubizjak at gmail dot com 2009-03-23 11:21 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution
--- Comment #2 from dodji at gcc dot gnu dot org 2009-03-23 11:20 --- Created an attachment (id=17518) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17518&action=view) another candidate fix I was looking at this bug when I saw Jakub's patch :) After talking with Jakub a little bit I felt I could post attch the patch here as well, before full regtest. Jan, would it be possible to test this patch as well against your gdb environment ? I have regtested it for the c++ FE, but it needs regtesting for all the FEs I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524
[Bug target/39482] [4.3 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478
--- Comment #6 from uros at gcc dot gnu dot org 2009-03-23 11:19 --- Subject: Bug 39482 Author: uros Date: Mon Mar 23 11:19:41 2009 New Revision: 145005 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145005 Log: Backport from mainline: 2009-03-17 Uros Bizjak PR target/39482 * config/i386/i386.md (*truncdfsf_mixed): Avoid combining registers from different units in a single alternative. (*truncdfsf_i387): Ditto. (*truncxfsf2_mixed): Ditto. (*truncxfdf2_mixed): Ditto. testsuite/ChangLog: Backport from mainline: 2009-03-17 Uros Bizjak PR target/39482 * gcc.target/i386/pr39482.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr39482.c - copied unchanged from r144915, trunk/gcc/testsuite/gcc.target/i386/pr39482.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/i386.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
[Bug c/39525] New: [easy to fix bug] Docs for C99 "designated initializers" isn't clear what happens to omitted field members
The documentation for C99 "designated initializers" is not clear what happens
to omitted field members. I'm fairly sure omitted field members get initialized
to the same value they would get if they were static but it would be very nice
to have this explicitly called out in the docs.
The documentation page I'm referring to is available here:
http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
In particular I would like the documentation to explain what the values of
struct my_struct { bool a; int b; double c; };
struct my_struct ms = { .b = 42 };
At this point, what is the values of ms.a and ms.c? As I mention above, I
suspect the answer is that they have been initialized to the same values that
the corresponding data types would get if they were static variables? i.e.
false and 0.0, no?
--
Summary: [easy to fix bug] Docs for C99 "designated initializers"
isn't clear what happens to omitted field members
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mnemo at minimum dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39525
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
--- Comment #3 from singler at gcc dot gnu dot org 2009-03-23 11:00 --- A parallelized std::copy was also suggested. -- singler at gcc dot gnu dot org changed: What|Removed |Added Summary|parallel fill in the|parallel fill and copy in |parallel version of |the parallel version of |libstdc++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-23 10:14 --- Created an attachment (id=17517) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17517&action=view) gcc44-pr39524.patch Could you please test this with gdb/archer testsuite? I'm going to bootstrap/regtest it in gcc in the mean time. -- 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=39524
[Bug tree-optimization/39516] [4.4 Regression] internal compiler error: in copy_to_mode_reg, at explow.c:623
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-23 09:30 --- Created an attachment (id=17516) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17516&action=view) gcc44-pr39516.patch Patch I'm going to bootstrap/regtest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39516
[Bug tree-optimization/39516] [4.4 Regression] internal compiler error: in copy_to_mode_reg, at explow.c:623
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-03-21 15:19:23 |2009-03-23 09:23:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39516
[Bug debug/39524] New: Duplicite C++ DW_TAG_variable breaking its DW_AT_location resolution
Tested on: GNU C++ 4.4.0 20090323 (experimental)
Testcase:
--
namespace A
{
static int var2 = 2;
}
int
func (void)
{
using A::var2;
return var2;
}
--
will generate (reduced):
<1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2f> DW_AT_name: (indirect string, offset: 0x42): func
<3d> DW_AT_low_pc : 0x0
<45> DW_AT_high_pc : 0xc
<4d> DW_AT_frame_base : 0x0 (location list)
<2><55>: Abbrev Number: 3 (DW_TAG_lexical_block)
<56> DW_AT_low_pc : 0x4
<5e> DW_AT_high_pc : 0xa
<3><66>: Abbrev Number: 4 (DW_TAG_imported_declaration)
<69> DW_AT_import : <0x7f> [Abbrev Number: 7 (DW_TAG_variable)]
<1><76>: Abbrev Number: 6 (DW_TAG_namespace)
<77> DW_AT_name: A
<2><7f>: Abbrev Number: 7 (DW_TAG_variable)
<80> DW_AT_name: (indirect string, offset: 0x34): var2
<84> DW_AT_decl_file : 1
<85> DW_AT_decl_line : 3
<86> DW_AT_type: <0x6f>
<8a> DW_AT_declaration : 1
<2><8b>: Abbrev Number: 7 (DW_TAG_variable)
<8c> DW_AT_name: (indirect string, offset: 0x34): var2
<84> DW_AT_decl_file : 1
<85> DW_AT_decl_line : 3
<92> DW_AT_type: <0x6f>
<96> DW_AT_declaration : 1
<1><98>: Abbrev Number: 8 (DW_TAG_variable)
<99> DW_AT_specification: <0x8b>
<9d> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
You can see the code references the <7f> "var" instance but DW_AT_location is
given by the <98> completion only for the <8b> "var" instance.
Also <7f> and <8b> have a name conflict as being in the same naming scope.
This problem causes a wrong evaluation by Archer archer-keiths-expr-cumulative
branch (which is IMO right) for the more complex testcase - as it cannot find
the right DW_AT_location there:
--
# archer-keiths-expr-cumulative=35ca449e9f1a4cd477df644f717bbe4e3362c486/gdb -q
./outer
(gdb) l 1
1 #include
2
3 namespace A
4 {
5 static int var = 2;
6 }
7
8 int
9 main (void)
10 {
11int var = 1;
12
13if (var != 1) /* var-is-1 */
14 abort ();
15
16{
17 using A::var;
18
19 if (var != 2) /* var-is-2 */
20abort ();
21}
22
23return 0; /* break-here */
24 }
(gdb) b 13
Breakpoint 1 at 0x4005a7: file outer.C, line 13.
(gdb) r
Starting program: /tmp/outer
Breakpoint 1, main () at outer.C:13
13if (var != 1) /* var-is-1 */
(gdb) p var
$1 = 1
(gdb) adv 19
main () at outer.C:19
19 if (var != 2) /* var-is-2 */
(gdb) p var
$2 = 1
^^ Wrong GDB evaluation.
(gdb) adv 23
main () at outer.C:23
23return 0; /* break-here */
(gdb) q
--
--
Summary: Duplicite C++ DW_TAG_variable breaking its
DW_AT_location resolution
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
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=39524
[Bug tree-optimization/39516] [4.4 Regression] internal compiler error: in copy_to_mode_reg, at explow.c:623
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-23 08:48 ---
Even more reduced testcase:
C { dg-options "-O2 -ftree-loop-linear" }
SUBROUTINE SUB(A, B, M)
IMPLICIT NONE
DOUBLE PRECISION A(20,20), B(20)
INTEGER*8 I, J, K, M
DO I=1,M
DO J=1,M
A(I,J)=A(I,J)+1
END DO
END DO
DO K=1,20
DO I=1,M
DO J=1,M
B(I)=B(I)+A(I,J)
END DO
END DO
END DO
END SUBROUTINE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39516
[Bug c/39369] ioquake3 SIGSEGVs when compiled with SSE optimizations
--- Comment #3 from ubizjak at gmail dot com 2009-03-23 08:25 --- As a workaround, can you try to compile with -fno-common? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39369
[Bug c/39369] ioquake3 SIGSEGVs when compiled with SSE optimizations
--- Comment #2 from ubizjak at gmail dot com 2009-03-23 08:24 --- This is probably the dup of PR37216. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39369
