[Bug debug/25793] dwarf2 debug info lacks linkage names for constructors destructors
--- Comment #2 from thor at math dot tu-berlin dot de 2006-01-16 09:29 --- HI Andrew, even though I'm not sure whether this is a duplicate of 11774 (I'm not competent enough to judge that), let me explain: i) The reason why you are able to set a breakpoint here is the consequence of the testclass having only one single (non-trivial) constructor and no base class. The problem becomes aparent as soon as you add a second (non-trivial) constructor and call the wrong one, i.e. one that gdb is not aware of. As far as I know, g++ generates more than one subroutine per constructor (is this correct?) and gdb does not know *where* to set the breakpoint. Unfortunately, the program where this happens here is a bit too large, and this also seems to some part a bug in gdb. ii) I've worked thru the gdb code last weekend. gdb does, indeed, depend on the mangled symbol name in the dwarf output as otherwise it seems to be unable to locate the proper symbol. It stores the linkage name (physname there in gdb-speak) in its data structure, and then later uses this name to locate the proper code section. However, at that time, it is already too late to distinguish between the two constructors. The gdb version I'm using is the latest, gdb 6.4, pulled off the gdb web-page. Indeed, gdb should use the additional attributes provided with the symbol to locate the code, though it doesn't. I don't know about the gdb authors, but it looks hard to fix this right now, and adding the linkage name *might* help a lot here. (At least, I was trying to fix gdb for my in-house use then to provide a patch for gdb, but failed due to that.) If that helps, I'll try to construct a larger non-trivial test case for it (but then larger really means that) the bug becomes pretty anoying for a project I'm working on, making it impossible to set breakpoints in constructors). So long, Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25793
[Bug rtl-optimization/24257] [4.1 Regression] ICE: in extract_insn with -O -fgcse -fgcse-sm
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-01-16 09:37 --- Subject: Bug 24257 Author: rguenth Date: Mon Jan 16 09:37:10 2006 New Revision: 109744 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109744 Log: 2006-01-16 Steven Bosscher [EMAIL PROTECTED] Richard Guenther [EMAIL PROTECTED] PR rtl-optimization/24257 * gcse.c (find_moveable_store): Only consider a store movable when the SET_SRC of the insn can be assigned to a register. * gcc.dg/torture/pr24257.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr24257.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/gcse.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
[Bug rtl-optimization/24257] [4.1 Regression] ICE: in extract_insn with -O -fgcse -fgcse-sm
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-01-16 09:37 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
[Bug c/25805] New: Incorrect handling of zero-initialized flexible arrays
A GNU C extension allows you to initialise a flexible array field.
However, if you do this, the DECL_SIZE of the containing object does not
account for the size of the initialised array. DECL_SIZE is simply
CHAR_BIT * sizeof (the structure type). Thus if you have:
struct { int a; int x[]; } d1 = { 0, 0 };
and if -fzero-initialized-in-bss is in effect, we will only allocate
one int for d1, not two:
d1:
.zero 4
A simple executable testcase is:
-
struct { int a; int x[]; } d1 = { 0, 0 };
int d2 = 0;
int main ()
{
d2 = 1;
if (d1.x[0] != 0)
abort ();
exit (0);
}
-
The testcase passes if compiled with -fno-zero-initialized-in-bss.
--
Summary: Incorrect handling of zero-initialized flexible arrays
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25805
[Bug c/25805] Incorrect handling of zero-initialized flexible arrays
--- Comment #1 from rsandifo at gcc dot gnu dot org 2006-01-16 10:19 --- Testing a fix -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-16 10:19:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25805
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-01-16 10:22 --- Honza or Micha - can you take over from here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug fortran/25806] New: problems with functions returning array pointers?
Hi! This code program a real, target :: storage(10) real :: s(5) print*,x(5) s = 0 s = x(5) print*,s contains function x(n) result(t) integer :: n real, pointer :: t(:) t = storage(1:n) ! allocate( t(n) ) t = (/ (i,i=1,n) /) end function x end program a prints: free(): invalid pointer 0x5012a0! 1.00 2.00 3.00 4.00 5.00 0.00 0.00 0.00 0.00 0.00 on a x86_64. If you delete s=0 statement, the latter line will contain values from uninitialized memory. gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060112 (experimental) Copyright (C) 2005 Free Software Foundation, Inc. Is this supposed to work? Regards, Juha -- Summary: problems with functions returning array pointers? Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jpr at csc dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug middle-end/23631] construct to memory and memcpy instead of memset
--- Comment #2 from etienne_lorrain at yahoo dot fr 2006-01-16 10:36 --- Same bug still present in gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5). http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477 is itself corrected, but this current bug has never been corrected. -- etienne_lorrain at yahoo dot fr changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
--- Comment #56 from rguenth at gcc dot gnu dot org 2006-01-16 10:37 --- Steven, are your patches in comment #31 orthogonal to the fix proposed in comment #39, or is it strictly needed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-01-16 11:14 --- I have re-tested today, and it seems that the problem only occurs when gfortran is built using a self-compiled version of GMP 4.1.3. When using the system-wide installed GMP 4.1.4 I don't get the error. So this looks like a GMP-related problem (either a bug in GMP or a miscompilation of GMP). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-01-16 11:23 --- Created an attachment (id=10651) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10651action=view) patch Testing the attached patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
--- Comment #57 from rguenth at gcc dot gnu dot org 2006-01-16 11:24 --- Created an attachment (id=10652) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10652action=view) patch Testing the attached patch on x86-64 (all languages) and hppa (only C, my machine is slow). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #10449|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug c/25682] [4.0/4.1/4.2 Regression] ICE when using old sytle offsetof (with non zero start) as array size
-- 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 | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg00835.html Status|NEW |ASSIGNED Last reconfirmed|2006-01-05 22:36:33 |2006-01-16 12:46:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25682
[Bug libstdc++/25807] New: endless loop when with sl_SI locale.
The following programm enters an endless loop with recursively calling
std::money_putchar, std::ostreambuf_iteratorchar, std::char_traitschar
::~money_put ()
**
#include locale
#include iostream
#include math.h
int main()
{
std::cout.imbue(std::locale(sl_SI));
std::cout pi = M_PI std::endl;
return 0;
}
**
This appears under SuSE 10.0, other locales work, but sl_SI shows the described
behaviour.
gcc version:
gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,f95,java,ada --disable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
--disable-libjava-multilib --with-slibdir=/lib --with-system-zlib
--enable-shared --enable-__cxa_atexit --without-system-libunwind
--host=i586-suse-linux
Thread model: posix
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
*
--
Summary: endless loop when with sl_SI locale.
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot glas at ev-i dot at
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25807
[Bug preprocessor/25717] [3.4/4.0/4.1/4.2 Regression] -dD does not list all defined macros (in particular, __STDC__)
-- 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 | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg00840.html Status|NEW |ASSIGNED Last reconfirmed|2006-01-09 01:28:51 |2006-01-16 13:47:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25717
[Bug libstdc++/25807] endless loop when with sl_SI locale.
--- Comment #1 from pcarlini at suse dot de 2006-01-16 13:55 --- Hi. I cannot reproduce the problem with current mainline/4_1-branch/4_0-branch, whereas I see a Segmentation fault with stock 4.0.2. This is a duplicate of libstdc++/23953, already fixed indeed. Thanks for your report, anyway. *** This bug has been marked as a duplicate of 23953 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25807
[Bug libstdc++/23953] using stringstreams causes crashes with some locales
--- Comment #10 from pcarlini at suse dot de 2006-01-16 13:55 --- *** Bug 25807 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||wolfgang dot glas at ev-i ||dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23953
[Bug c/19606] wrong code for arith.expr: (((unsigned int)(signed int) a ) / 2LL) with signed char a=-4
--- Comment #8 from kazu at gcc dot gnu dot org 2006-01-16 14:07 --- Assigning to myself. -- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg00845.html Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19606
[Bug c++/25808] New: constant on rhs of conditional assignment
Given the following C++ source code
void g();
void h();
void f( int a, int b)
{
if (b = 1) // case 1 - fixed constant on rhs. g() always executed.
g();
if (b = a) // case 2 - variable on rhs. h() might be executed.
h();
}
then GNU C++ 4.2 snapshot says
[EMAIL PROTECTED]:~/C++/Alphasrc ~/gnu/42-20060114/results/bin/g++ -c -Wall
jan15b.cc
jan15b.cc: In function 'void f(int, int)':
jan15b.cc:6: warning: suggest parentheses around assignment used as truth value
jan15b.cc:8: warning: suggest parentheses around assignment used as truth value
[EMAIL PROTECTED]:~/C++/Alphasrc
We can see the compiler fails to distinguish case 1 and case 2.
Suggest enhance the compiler to say something different for case 1.
Fixed constant on rhs is much more likely to be a programmer error, IMHO.
Here is Intel C++ 9.0 doing what I want
jan15b.cc(6): warning #187: use of = where == may have been intended
if (b = 1)
^
--
Summary: constant on rhs of conditional assignment
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25808
[Bug tree-optimization/25809] New: missed PRE optimization - move invariant casts out of loops
In testcases that have reduction, like gcc.dg/vect/vect-reduc-2char.c and gcc.dg/vect-reduc-2short.c, the following casts appear: signed char sdiff; unsigned char ux, udiff; sdiff_0 = ... loop: # sdiff_41 = PHI sdiff_39, sdiff_0; . ux_36 = udiff_37 = (unsigned char) sdiff_41; udiff_38 = x_36 + udiff_37; sdiff_39 = (signed char) udiff_38; end_loop although these casts could be taken out of loop all together. i.e., transform the code into something like the following: signed char sdiff; unsigned char ux, udiff; sdiff_0 = ... udiff_1 = (unsigned char) sdiff_0; loop: # udiff_3 = PHI udiff_2, udiff_1; . ux_36 = udiff_2 = ux_36 + udiff_3; end_loop sdiff_39 = (signed char) udiff_2; see this discussion thread: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01827.html -- Summary: missed PRE optimization - move invariant casts out of loops Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com GCC build triplet: ppc64-yellowdog-linux GCC host triplet: ppc64-yellowdog-linux GCC target triplet: ppc64-yellowdog-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25809
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #7 from hubicka at gcc dot gnu dot org 2006-01-16 14:56 ---
These two testcases seems to still fail for me even with the patch. (I use b.c
-mpreferred-stack-boundary=2 -S -march=i686 -frename-registers)
extern void abort (void) __attribute__((noreturn));
struct setconflict
{
char a[36];
int b;
};
int
main ()
{
int sum = 0;
{
struct setconflict a;
short *c;
c = (void *)a.a;
asm (: =r (c):0 (c));
*c = 0;
asm (: =r (c):0 (c));
sum += *c;
}
{
struct setconflict a;
int *c;
c = (void *)a.a;
asm (: =r (c):0 (c));
*c = 1;
asm (: =r (c):0 (c));
sum += *c;
}
printf (%d\n,sum);
if (sum != 1)
abort();
return 0;
}
extern void abort (void) __attribute__((noreturn));
struct wrapper {
union setconflict
{
short a[20];
int b[10];
} a;
};
int
main ()
{
int sum = 0;
{
struct wrapper a;
short *c;
c = a.a.a;
asm (: =r (c):0 (c));
*c = 0;
asm (: =r (c):0 (c));
sum += *c;
}
{
struct wrapper a;
int *c;
c = a.a.b;
asm (: =r (c):0 (c));
*c = 1;
asm (: =r (c):0 (c));
sum += *c;
}
printf (%d\n,sum);
if (sum != 1)
abort();
return 0;
}
So looking for unions is IMO not strong enought test. Not sure what proper
solution shall be :(
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug c/25810] New: spurious warning about unused function return
The attached file warns about an unused function return value, when the non-bugs section suggests that unused return values are quite fine. -- Summary: spurious warning about unused function return Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wingo at pobox dot com GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25810
[Bug c/25810] spurious warning about unused function return
--- Comment #1 from wingo at pobox dot com 2006-01-16 15:02 --- Created an attachment (id=10654) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10654action=view) short test case to show problem -- preprocessed Compiler output: [EMAIL PROTECTED] ~]$ gcc -v -save-temps -Wall -o test test.c Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux Thread model: posix gcc version 4.1.0 20060106 (Red Hat 4.1.0-0.14) /usr/libexec/gcc/i386-redhat-linux/4.1.0/cc1 -E -quiet -v test.c -Wall -fpch-preprocess -o test.i ignoring nonexistent directory /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../../i386-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/i386-redhat-linux/4.1.0/include /usr/include End of search list. /usr/libexec/gcc/i386-redhat-linux/4.1.0/cc1 -fpreprocessed test.i -quiet -dumpbase test.c -auxbase test -Wall -version -o test.s GNU C version 4.1.0 20060106 (Red Hat 4.1.0-0.14) (i386-redhat-linux) compiled by GNU C version 4.1.0 20060106 (Red Hat 4.1.0-0.14). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64435 Compiler executable checksum: 56e51ec7541d93cee9e835a9348da767 test.c: In function main: test.c:33: warning: value computed is not used as -V -Qy -o test.o test.s GNU assembler version 2.16.91.0.5 (i386-redhat-linux) using BFD version 2.16.91.0.5 20051219 /usr/libexec/gcc/i386-redhat-linux/4.1.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../crt1.o /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../crti.o /usr/lib/gcc/i386-redhat-linux/4.1.0/crtbegin.o -L/usr/lib/gcc/i386-redhat-linux/4.1.0 -L/usr/lib/gcc/i386-redhat-linux/4.1.0 -L/usr/lib/gcc/i386-redhat-linux/4.1.0/../../.. test.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i386-redhat-linux/4.1.0/crtend.o /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../crtn.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25810
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-01-16 15:03 --- Your char testcase is invalid - it violates type based aliasing rules as you access memory of type char as int and short. Is it solved with -fno-strict-aliasing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug c/25810] spurious warning about unused function return
--- Comment #2 from wingo at pobox dot com 2006-01-16 15:07 --- Just for clarity, here is the warning: test.c: In function main: test.c:33: warning: value computed is not used The line corresponding to 33 in the preprocessed file: (void*)data_ref((data*)d); data_ref is not declared as pure or const. It seems to be the cast that is causing the warning. The real-world case that causes this warning to be an issue are things like this, from GStreamer: #define gst_buffer_ref(buf) \ GST_BUFFER_CAST (gst_mini_object_ref (GST_MINI_OBJECT (buf))) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25810
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #23 from matz at suse dot de 2006-01-16 15:14 --- The x86-64 ABI itself doesn't talk about zero-sized bitfields. So both behaviours are correct regarding the ABI. It talks about unnamed bitfields (which zero-sized ones must be) not influencing the overall alignment of structures or unions, but the problem here is different. Having said that I agree with Marks mail on gcc@ that the pre-3.4 behaviour made more sense. Unfortunately I'm also no stor-layout.c expert, so can't really comment on how the best approach is to implement it. I assume Jason would be the best to comment here, as he changed that behaviour. Stevens latest patch changes the evaluation of EMPTY_FIELD_BOUNDARY vs. PCC_BITFIELD_TYPE_MATTERS, so someone needs to make sure that this is okay. Additionally I don't know how stor-layout tracks alignment, i.e. if desired_align contains the alignment for the _current_ field, or for the _next_ field. A zero-sized bitfield should influence alignment of the next field (although due to the size of zero this shouldn't make a difference). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug c++/25808] constant on rhs of conditional assignment
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-16 15:27 --- Both of these are questionable, I don't see why there should be a different diagnostic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25808
[Bug c/25810] spurious warning about unused function return
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-16 15:30 --- This is actually not a bug. This is also a dup of bug 24900. *** This bug has been marked as a duplicate of 24900 *** -- 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=25810
[Bug middle-end/24900] [4.1 Regression] new value computed is not used warning in gcc 4.1
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-16 15:30 --- *** Bug 25810 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||wingo at pobox dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24900
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-01-16 15:38 --- It is solved (all are) with -fno-strict-aliasing. Whether the failure mode is that of an aliasing problem or not, is another question. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug java/25535] gcj broken on 64-bit big-endian systems
--- Comment #3 from aph at gcc dot gnu dot org 2006-01-16 15:51 --- Subject: Bug 25535 Author: aph Date: Mon Jan 16 15:51:42 2006 New Revision: 109748 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109748 Log: 2006-01-16 Andrew Haley [EMAIL PROTECTED] PR java/25535 * constants.c (build_constants_constructor): move initializer into first halfword on a 6-bit big-endian machine. Modified: branches/gcc-4_1-branch/gcc/java/ChangeLog branches/gcc-4_1-branch/gcc/java/constants.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25535
[Bug c/25805] [3.4/4.0/4.1/4.2 Regression] Incorrect handling of zero-initialized flexible arrays
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to fail||4.1.0 4.0.0 3.3.3 3.4.0 ||4.2.0 Known to work||3.2.3 Summary|Incorrect handling of zero- |[3.4/4.0/4.1/4.2 Regression] |initialized flexible arrays |Incorrect handling of zero- ||initialized flexible arrays Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25805
[Bug fortran/25806] problems with functions returning array pointers?
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-16 16:30 --- Confirmed, this is defintely a problem. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-01-16 16:30:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug fortran/25806] problems with functions returning array pointers?
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-16 16:54 ---
Shorter testcase:
program a
real, target :: storage(2)
real :: s(2)
s = x(2)
print*,s
contains
function x(n) result(t)
integer :: n
real, pointer :: t(:)
t = storage(1:n)
! allocate( t(n) )
t = (/ (i,i=1,n) /)
end function x
end program a
looks like the FE generates wrong trees: .03.gimple is
MAIN__ ()
{
real4[0:] * D.831;
real4 storage[2];
real4 s[2];
static void x (struct array1_real4 , int4 );
_gfortran_set_std (118, 127);
{
int4 * D.828;
int4 C.827 = 2;
struct array1_real4 parm.3;
parm.3.dtype = 281;
parm.3.dim[0].lbound = 1;
parm.3.dim[0].ubound = 2;
parm.3.dim[0].stride = 1;
D.831 = (real4[0:] *) s[0];
parm.3.data = D.831;
parm.3.offset = 0;
D.828 = C.827;
x (parm.3, D.828);
}
{
struct __st_parameter_dt dt_parm.4;
dt_parm.4.common.filename = t3.f90;
dt_parm.4.common.line = 6;
dt_parm.4.common.unit = 6;
dt_parm.4.common.flags = 128;
_gfortran_st_write (dt_parm.4);
{
struct array1_real4 parm.5;
parm.5.dtype = 281;
parm.5.dim[0].lbound = 1;
parm.5.dim[0].ubound = 2;
parm.5.dim[0].stride = 1;
D.831 = (real4[0:] *) s[0];
parm.5.data = D.831;
parm.5.offset = 0;
_gfortran_transfer_array (dt_parm.4, parm.5, 4, 0);
}
_gfortran_st_write_done (dt_parm.4);
}
}
Note the call to _gfortran_st_write is before the array transfer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug tree-optimization/21470] -fargument-noalias-global has no effect for the vectorizer
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-16 17:09 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00864.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg00864.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21470
[Bug tree-optimization/17064] -falias-noargument-global doesn't eliminate dead stores/loads
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-16 17:11 --- Partial patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00864.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17064
[Bug c/23087] Misleading warning, ... differ in signedness
--- Comment #8 from axel at zankasoftware dot com 2006-01-16 17:14 ---
There's also the following issue, which seem related.
$ cat test.c
void nil_uch(unsigned char *uch) {
*uch = 0;
}
void nil_sch(signed char *sch) {
*sch = 0;
}
int main(void) {
char ch = 0;
nil_uch(ch);
nil_sch(ch);
return 0;
}
$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -o test test.c
test.c: In function 'main':
test.c:14: warning: pointer targets in passing argument 1 of 'nil_uch' differ
in signedness
test.c:15: warning: pointer targets in passing argument 1 of 'nil_sch' differ
in signedness
I'd expect the warning to be muted in one of the calls, depending on
-f{un}signed-char.
--
axel at zankasoftware dot com changed:
What|Removed |Added
CC||axel at zankasoftware dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
[Bug tree-optimization/25680] Store CCP does not understand REALPART_EXPR COMPLEX_CST
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-16 17:24 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00870.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg00870.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25680
[Bug fortran/25219] [GOMP] ICE with SAVE attribute and (FIRST|LAST)PRIVATE
--- Comment #3 from jakub at gcc dot gnu dot org 2006-01-16 17:40 ---
This is not Fortran specific,
int main (void)
{
static int i;
static int k;
k = 3;
#pragma omp parallel
#pragma omp for private(i) lastprivate(k)
for (i = 1; i = 100; i = i + 1)
k = i;
__builtin_printf (%d\n, k);
return 0;
}
ICEs the same. I can't reproduce this in the Fedora Core gcc though,
so I think this got fixed by
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01192.html
Dunno about its status, Diego, was it subsummed by your
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00668.html
patch?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||aldyh at gcc dot gnu dot
||org, dnovillo at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25219
[Bug fortran/25219] [GOMP] ICE with SAVE attribute and (FIRST|LAST)PRIVATE
--- Comment #4 from dnovillo at redhat dot com 2006-01-16 18:18 --- Subject: Re: [GOMP] ICE with SAVE attribute and (FIRST|LAST)PRIVATE On Monday 16 January 2006 12:40, jakub at gcc dot gnu dot org wrote: ICEs the same. I can't reproduce this in the Fedora Core gcc though, so I think this got fixed by http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01192.html Dunno about its status, Diego, was it subsummed by your http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00668.html patch? No, it's unrelated. I've committed Aldy's patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25219
[Bug middle-end/24565] [4.1/4.2 Regression] facerec performance regression
--- Comment #6 from uttamp at us dot ibm dot com 2006-01-16 18:19 --- Steve, The numbers have changed since the last time I saw them. The current facerec perf. numbers are much close to the Oct. when I reported it. Do we still want me to investigate this any further? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
[Bug rtl-optimization/25677] [4.2 regression] testsuite failure:gcc.c-torture/execute/960802-1.c -O1 and -O2
--- Comment #7 from bonzini at gnu dot org 2006-01-16 18:21 --- Patch committed -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25677
[Bug fortran/25219] [GOMP] ICE with SAVE attribute and (FIRST|LAST)PRIVATE
--- Comment #5 from dnovillo at gcc dot gnu dot org 2006-01-16 18:23 --- Fixed with http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01192.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25219
[Bug testsuite/25767] g++.dg/lookup/builtin1.C (and a couple others) fails on i686-darwin
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-16 18:53 --- Submitting the obvious patch right now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-16 18:53:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25767
[Bug testsuite/25767] g++.dg/lookup/builtin1.C (and a couple others) fails on i686-darwin
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-16 19:00 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00884.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg00884.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25767
[Bug rtl-optimization/25799] [42. Regression] cc1 stalled with -O1 -fmodulo-sched
-- zadeck at naturalbridge dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |zadeck at naturalbridge dot |dot org |com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-16 19:11:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25799
[Bug testsuite/25777] acats_run doesn't include gcc base directory in LD_LIBRARY_PATH
--- Comment #3 from guerby at gcc dot gnu dot org 2006-01-16 19:28 --- Subject: Bug 25777 Author: guerby Date: Mon Jan 16 19:28:02 2006 New Revision: 109764 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109764 Log: 2006-01-16 John David Anglin [EMAIL PROTECTED] PR testsuite/25777 * ada/acats/run_acats (LD_LIBRARY_PATH): Add BASE to LD_LIBRARY_PATH. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/ada/acats/run_acats -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25777
[Bug c/25682] [4.0/4.1/4.2 Regression] ICE when using old sytle offsetof (with non zero start) as array size
--- Comment #5 from janis at gcc dot gnu dot org 2006-01-16 19:28 --- A regression hunt on powerpc-linux using the submitter's testcase identified the following patch as introducing the failure: http://gcc.gnu.org/viewcvs?view=revrev=87064 r87064 | rth | 2004-09-03 23:50:11 + (Fri, 03 Sep 2004) | 16 lines PR middle-end/9997 * cfgexpand.c (LOCAL_ALIGNMENT): Provide default. (STACK_ALIGNMENT_NEEDED, FRAME_GROWS_DOWNWARD): Likewise. (struct stack_var, EOC, stack_vars, stack_vars_alloc, stack_vars_num, stack_vars_sorted, stack_vars_conflict, stack_vars_conflict_alloc, frame_phase, get_decl_align_unit, add_stack_var, triangular_index, resize_stack_vars_conflict, add_stack_var_conflict, stack_var_conflict_p, add_alias_set_conflicts, stack_var_size_cmp, union_stack_vars, partition_stack_vars, dump_stack_var_partition, expand_one_stack_var_at, expand_stack_vars, expand_one_stack_var, expand_one_static_var, expand_one_hard_reg_var, expand_one_register_var, expand_one_error_var, defer_stack_allocation, expand_one_var, expand_used_vars_for_block, clear_tree_used): New. (expand_used_vars): Rewrite. * Makefile.in (cfgexpand.o): Update dependencies. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25682
[Bug testsuite/25777] acats_run doesn't include gcc base directory in LD_LIBRARY_PATH
--- Comment #4 from guerby at gcc dot gnu dot org 2006-01-16 19:35 --- Subject: Bug 25777 Author: guerby Date: Mon Jan 16 19:35:02 2006 New Revision: 109765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109765 Log: 2006-01-16 John David Anglin [EMAIL PROTECTED] PR testsuite/25777 * ada/acats/run_acats (LD_LIBRARY_PATH): Add BASE to LD_LIBRARY_PATH. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ada/acats/run_acats -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25777
[Bug testsuite/25777] acats_run doesn't include gcc base directory in LD_LIBRARY_PATH
--- Comment #5 from guerby at gcc dot gnu dot org 2006-01-16 19:38 --- Subject: Bug 25777 Author: guerby Date: Mon Jan 16 19:38:30 2006 New Revision: 109767 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109767 Log: 2006-01-16 John David Anglin [EMAIL PROTECTED] PR testsuite/25777 * ada/acats/run_acats (LD_LIBRARY_PATH): Add BASE to LD_LIBRARY_PATH. Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/ada/acats/run_acats -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25777
[Bug c++/25811] New: No failure creating a POD containing a const member, using new without a new-initializer.
$ cat podnew.cpp
struct Foo // POD
{
double const d;
};
int main()
{
Foo* foo = new Foo; // without the new-initializer
}
This simple code does not fail to compile.
According to the standard (5.3.4.15), I am not sure, but i think it should fail
to compile.
$ g++ podnew.cpp echo no failure
no failure
I use gcc-4.0.2, but it is the same behaviour with 3.4.4.
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/gcc-4.0.2-r1/work/gcc-4.0.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.0.2
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.2/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libgcj --enable-languages=c,c++,f95 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.0.2 (Gentoo 4.0.2-r1, pie-8.7.8)
--
Summary: No failure creating a POD containing a const member,
using new without a new-initializer.
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fabien dot chene at laposte dot net
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811
[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-16 20:06 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Known to fail||2.95.3 3.3.1 3.0.4 3.4.0 ||4.0.0 4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-01-16 20:06:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #30 from bkoz at gcc dot gnu dot org 2006-01-16 20:09 --- Confirmed. Excellent, thanks. This is great, no regressions known with this on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug target/25758] gcc.c-torture/compile/20030921-1.c fails at -O0
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-16 20:18 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00897.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg00897.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
[Bug c++/25342] [3.4/4.0/4.1/4.2 Regression] internal compiler error: in lookup_member, at cp/search.c:1209
--- Comment #6 from janis at gcc dot gnu dot org 2006-01-16 20:34 --- A regression hunt on powerpc-linux using the testcase from comment #1 identified the following patch: http://gcc.gnu.org/viewcvs?view=revrev=72611 r72611 | lerdsuwa | 2003-10-17 15:41:46 + (Fri, 17 Oct 2003) | 13 lines PR c++/2513 * decl.c (make_typename_type): Use dependent_type_p. (make_unbound_class_template): Likewise. * pt.c (instantiate_class_template): Increment processing_template_decl during substitution of template friend function. Preincrement processing_template_decl rather than postincrement. (get_mostly_instantiated_function_type): Increment processing_template_decl during partial substitution of function type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25342
[Bug bootstrap/25794] gcc won't link to new local glibc
--- Comment #5 from davek at csh dot rit dot edu 2006-01-16 20:48 --- still can't get it to work. I've tried at least 50 different configurations and had to wait an hour to see if each one would work. It always exits with undefined references to symbols in /usr/glibc2/lib/ld-2.3.6.so. I don't understand how this is not a bug. GCC WILL NOT COMPILE WITH MY GLIBC. Perhaps if someone told me how I should be doing that, I would know if the problem is with my GCC config or my glibc config. Glibc compiled, checked, and installed just fine. Not so with gcc. Sounds to me like a its a problem with gcc. I know since this is closed, probably no one will see this. But if anyone does, please please help me. I've been stuck on square one for weeks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25794
[Bug testsuite/25767] g++.dg/lookup/builtin1.C (and a couple others) fails on i686-darwin
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-16 21:21 --- Subject: Bug 25767 Author: pinskia Date: Mon Jan 16 21:21:49 2006 New Revision: 109772 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109772 Log: 2006-01-16 Andrew Pinski [EMAIL PROTECTED] PR testsuite/25767 * lib/g++.exp (g++_init): Check for *-*-darwin* instead of powerpc-*-darwin*. * lib/obj-c++.exp (obj-c++_init): Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/g++.exp trunk/gcc/testsuite/lib/obj-c++.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25767
[Bug testsuite/25767] g++.dg/lookup/builtin1.C (and a couple others) fails on i686-darwin
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-16 21:22 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25767
[Bug testsuite/25741] Gcc testsuite isn't parallel build safe
--- Comment #5 from hjl at gcc dot gnu dot org 2006-01-16 21:43 --- Subject: Bug 25741 Author: hjl Date: Mon Jan 16 21:43:05 2006 New Revision: 109773 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109773 Log: gcc/ 2006-01-16 H.J. Lu [EMAIL PROTECTED] PR testsuite/25741 * Makefile.in (check-%): Depend on site.exp instead of $(TESTSUITEDIR)/site.exp. Run runtest in separate language directories. gcc/testsuite/ 2006-01-16 H.J. Lu [EMAIL PROTECTED] PR testsuite/25741 * lib/g++.exp (g++_init): Use $base_dir/../../ instead of $base_dir/../. * lib/gfortran.exp (gfortran_init): Likewise. * lib/obj-c++.exp (obj-c++_init): Likewise. * lib/scanasm.exp (scan-assembler-dem): Likewise. (scan-assembler-dem-not): Likewise. * lib/scandump.exp (scan-dump-dem): Likewise. (scan-dump-dem-not): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/g++.exp trunk/gcc/testsuite/lib/gfortran.exp trunk/gcc/testsuite/lib/obj-c++.exp trunk/gcc/testsuite/lib/scanasm.exp trunk/gcc/testsuite/lib/scandump.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25741
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
--- Comment #58 from steven at gcc dot gnu dot org 2006-01-16 21:52 --- Re. comment #56, Richard, only the patch of comment #39 is necessary to fix this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug libstdc++/25797] [4.2 Regression] almost all libstdc++ tests fail
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-01-16 22:11 --- I'm on it. This patch should be a step to fixing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25797
[Bug libstdc++/25797] [4.2 Regression] almost all libstdc++ tests fail
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-01-16 22:12 --- Created an attachment (id=10655) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10655action=view) correct configure test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25797
[Bug c++/25808] constant on rhs of conditional assignment
--- Comment #2 from dcb314 at hotmail dot com 2006-01-16 22:28 --- (In reply to comment #1) Both of these are questionable, I don't see why there should be a different diagnostic. Because the two different diagnostics make it easier to grep for. For example, Intel C++ compiler finds case 1, but says nothing about case 2. Easy to grep for. GNU C++ produces the same message for case 1 and case 2, leading to a lot of time wasting manual checking of diagnostics. Surely case 1 is much more likely to be programmer error than case 2 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25808
[Bug middle-end/24565] [4.1/4.2 Regression] facerec performance regression
--- Comment #7 from steven at gcc dot gnu dot org 2006-01-16 22:32 --- It's your bug. If you're happy with the current numbers, you should close the bug as FIXED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
--- Comment #59 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-16 22:34 --- Subject: Re: [4.1/4.2 Regression] internal compiler error: verify_flow_info failed --- Comment #58 from steven at gcc dot gnu dot org 2006-01-16 21:52 --- Re. comment #56, Richard, only the patch of comment #39 is necessary to fix this bug. I've tested the above change on hppa2.0w-hp-hpux11.11 and hppa-unknown-linux-gnu with the trunk, and on hppa2.0w-hp-hpux11.11 with 4.1.0. No regressions were seen. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug c/25791] -O2 execution fails, -O and -g work
--- Comment #2 from dick_guertin at yahoo dot com 2006-01-16 23:16 --- See my response below yours. --- ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-01-15 10:01 --- We cannot do anything without a reproducer. See http://gcc.gnu.org/bugs.html. However, a segfault at runtime on several platforms with -O2 and not -O1 may hint at an aliasing problem in the code. You could try to recompile everything with -O2 -fno-strict-aliasing and see what happens. Read the -fstrict-aliasing entry in the manual, section Optimize Options, for more information. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC| |ebotcazou at gcc dot gnu dot ||org Severity|major |normal Status|UNCONFIRMED |WAITING Summary|-O2 execution fails using |-O2 execution fails, -O and |3.4.4, -O and -g work |-g work http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. I tried what you said, adding -fno-strict-aliasing to my DEFINES statement in the Imakefile. I then removed all object decks, private libraries, and the Makefiles, and used 'xmkmf' to rebuild them . I then compiled the three sub-libraries, and then the main code. All were done with -O2 and -fno-strict-aliasing. Execution then went like this: elaine30:~/wylsrc gdb wylbur.ge GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as sparc-sun-solaris2.8... (gdb) run Starting program: /afs/ir.stanford.edu/users/g/u/guertin/wylsrc/wylbur.ge Program received signal SIGILL, Illegal instruction. 0x00297064 in hex_to_character () (gdb) where #0 0x00297064 in hex_to_character () #1 0x00297068 in hex_to_character () Previous frame identical to this frame (corrupt stack?) As you can see, your suggested change did NOT fix the 'problem'. What is obvious to me is that -O2 is affecting address computations. There shouldn't be any way to clobber the stack unless addresses are mis-computed or not stored into variables when they should. As far as I'm concerned, -O2 is a violation of the ISO standards concerning Optimization. If you need the source code, I can bundle it into a tar.z file and make it available for download over the web. I would include a Readme file that explains what MINOR changes you would have to make to the Imakefile because this program expects to 'read' tables and initialization information from files stored in user-owned subdirectories (the user being YOU, the one who compiles the code). This is done so that this cade can be transported to different sites, owned by different users. By the way, I will include 'Imakefile.unix' and 'Imakefile.linux' files for all three subdirectories and the main code. That will allow you to compare Big-Endian to Little-Endian. Let me know what you want me to do next. I'd like to see this -O2 problem fixed! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-16 23:20 --- Yes we need the proprocessed source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #24 from steven at gcc dot gnu dot org 2006-01-16 23:31 --- Realistically, I don't think it's safe to still fix this for GCC 4.1. The whole thing looks so complicated (to me at least) that the risk of introducing new bugs just before the release is significant. It is unfortunate that Jason has completely ignored this regression, even though he caused it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #25 from steven at gcc dot gnu dot org 2006-01-16 23:33 --- Re. comment #23, iiuc the old behavior was to align the zero-length bitfield, not the next field. My patch (one of them anyway) switches the order of EMPTY_FIELD_BOUNDARY and PCC_BITFIELD_TYPE_MATTERS back to how it was before Jason's change, but that change alone is not enough to fix the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/24565] [4.1/4.2 Regression] facerec performance regression
--- Comment #8 from uttamp at us dot ibm dot com 2006-01-16 23:56 --- I'm closing this bug as FIXED since the current facerec benchmark numbers on powerpc64-linux seems to be lot closer to the numbers generatged in Oct 2005 (before reported regression happen). -- uttamp at us dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
[Bug fortran/20869] EXTERNAL and INTRINSIC cannot be used together
--- Comment #4 from kargl at gcc dot gnu dot org 2006-01-17 00:02 --- I have a patch -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|-00-00 00:00:00 |2006-01-17 00:02:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20869
[Bug fortran/25813] New: EXTERNAL statement cause ICE in trans-decl.c
The following code is invalid due to the external sin line. Nonetheless, we get an ICE. kargl[255] gfc4x -o z v.f90 v.f90: In function 'MAIN__': v.f90:2: internal compiler error: in build_function_decl, at fortran/trans-decl.c:1131 program a external sin print *, sin() contains integer function sin () sin = 1 end function sin end program a -- Summary: EXTERNAL statement cause ICE in trans-decl.c Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25813
[Bug fortran/25813] EXTERNAL statement cause ICE in trans-decl.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-17 00:12 --- This is a dup of bug 24327. *** This bug has been marked as a duplicate of 24327 *** -- 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=25813
[Bug fortran/24327] Does not detect duplicate symbol names in contains block
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-17 00:12 --- *** Bug 25813 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24327
[Bug target/24831] [4.1/4.2 regression] gthr-dce.h:77: error: expected expression before '{' token
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-17
00:20 ---
Subject: Re: [4.1/4.2 regression] gthr-dce.h:77: error: expected expression
before '{' token
Alex,
Created an attachment (id=10362)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10362action=view)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10362action=view)
Tentative patch to accomodate expressions, absent functions et al
Dave, could you please give this patch a try? I haven't tested it yet, but I
think the approach is promising. It certainly conflicts with your patch.
I've
tried to merge the essential bits from it (i.e., the UNUSED changes are not
in).
We are coming up to release for 4.1 and I'd really like to try to get
this issue fixed. I been running the enclosed iversion of your patch
for some time on the trunk for hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
I haven't seen any issues. I haven't tried it recently on hpux10.
If there's something I can do to promote its review, let me know.
Dave
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-17
00:20 ---
Created an attachment (id=10656)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10656action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24831
[Bug c++/25814] New: Request for new warning
I'd like to request a warning to notify that a statement like X x(const Y)
is parsed as function declaration and not a definition of variable x. See the
code below.
At least as couple of PRs have been filed (9217,19503) on this topic.
I've just spent at least 2 hrs trying to figure out why my constructor and
destructor were not called and did not show up in the assembly code either.
I think this particular problem might affect users that use the
resource-acquisition idiom. The real problem is that the code compiles and
links and runs without problems, except it doesn't actually work.
#include cstdio
struct Y {};
struct X {
inline X (const Y)
{}
inline ~X ()
{
::std::printf(1\n);
}
};
int main()
{
X x(Y());
return 0;
}
--
Summary: Request for new warning
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Raimund dot Merkert at baesystems dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814
[Bug middle-end/23785] [4.1/4.2 Regression] 197.parser performance drop
--- Comment #6 from uttamp at us dot ibm dot com 2006-01-17 00:42 --- With the latest mainline, the performance numbers for parser benchmark are very close to the reported numbers (on July 29th 2005). With the mainline, parser numbers on powerpc64-linux with -O3 -m32 -mcpu=power4 -ffast-math -fpeel-loops -ftree-loop-linear -funroll-loops flags is, 197.parser: 438 (and the reported drop was at 423). Looking at the current numbers I don't think I should investigate this any further. I'm thinking of closing this bug as FIXED. Any thoughts? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23785
[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-17 00:58 --- Maybe if more C++ books actually talked about this issue, there would not be a problem (sorry I could not resists). Also warning about very valid and defined code even if it is a common mistake that beginers make. I would rather have people actually taught this rule than GCC warning about it. The real problem is that the code compiles and links and runs without problems, except it doesn't actually work. that should say doesn't actually work the way the person is expecting so it is working as the C++ standard says it should work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic Summary|Request for new warning |Request for warning for ||parser ambiguity of function ||declarations and variable ||declarations with ||initializations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814
[Bug classpath/20198] java.security.CodeSource.getLocation output is different than expected
--- Comment #6 from tromey at gcc dot gnu dot org 2006-01-17 01:17 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|green at redhat dot com |tromey at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20198
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #4 from dick_guertin at yahoo dot com 2006-01-17 01:19 --- I have created 'wylsrc/tgz' that you can download from the web as follows: http://lindy.stanford.edu/~guertin/wylsrc.tgz Use the following to extract the 'wylsrc' directory: gzip -d wylsrc.tgz tar -xf wylsrc.tar rm wylsrc.tar Move the 'wylsrc' directory to be in your home directory. Read the 'a.readme.txt' file that is in 'wylsrc'. There is a 'Rmall' script that removes all objects and private (wylsrc) libraries. There are Imakefiles for both Unix and Linux, with Imakefile itself set to the Unix version. Likewise for the Makefiles. You must make the private libraries first, inside 'common', 'modeltrm', and 'unixport' subdirectories. Then you can play with 'wylsrc' itself. All of my problems have been occurring in 'comm.c'. The Makefiles are all set for -O2 (three instances in each Makefile). If you change them to -O, and rebuild everything (Rmall), you'll get a working version. I can not find any 'code violations' that would cause -O2 to fail. If you have more questions, or need further assistance, let me know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug target/20294] ia64 gcj failures
--- Comment #2 from tromey at gcc dot gnu dot org 2006-01-17 01:20 --- Andrew, is this still happening with 4.1? -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294
[Bug target/20294] ia64 gcj failures
--- Comment #3 from overholt at redhat dot com 2006-01-17 01:38 --- (In reply to comment #2) Andrew, is this still happening with 4.1? No. Sorry I didn't close this already. I successfully built Eclipse (natively-compiled) on ia64 last week. Marking WORKSFORME. -- overholt at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20294
[Bug c/25683] Error while running `make`
--- Comment #9 from gccbugzilla at multiwebinc dot com 2006-01-17 01:44 --- Anyone know what's wrong and how I can fix it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25683
[Bug rtl-optimization/25683] Error while running `make`
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-17 01:49 --- Nope that is not the proprocessed source. Again read http://gcc.gnu.org/bugs.html and provide the proprocessed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25683
[Bug testsuite/25590] [4.1/4.2 regression] FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vectorized 1 loops 1
--- Comment #8 from hp at gcc dot gnu dot org 2006-01-17 02:02 --- Also seen on 4.1 branch, regression appearing between Fri Dec 30 21:24:33 UTC 2005 (revision 109181M) and Wed Jan 11 14:14:27 UTC 2006 (revision 109585M) for cris-axis-elf, cris-axis-linux-gnu and mmix-knuth-mmixware, cross from i686-pc-linux-gnu (FC2). -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org Summary|FAIL: gcc.dg/tree-ssa/gen- |[4.1/4.2 regression] FAIL: |vect-11.c scan-tree-dump- |gcc.dg/tree-ssa/gen-vect- |times vectorized 1 loops 1 |11.c scan-tree-dump-times ||vectorized 1 loops 1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25590
[Bug libstdc++/25815] New: [4.1 regression] libstdc++ testsuite: ext/pb_assoc/example/erase_if.cc execution test
Last known to work with: Fri Dec 30 21:24:33 UTC 2005 (revision 109181M). Known to fail with: Wed Jan 11 14:14:27 UTC 2006 (revision 109585M). FAIL: ext/pb_assoc/example/erase_if.cc execution test With the message in the .log being: ... PASS: ext/pb_assoc/example/erase_if.cc (test for excess errors) /home/hp/combined41/combined/libstdc++-v3/testsuite/ext/pb_assoc/example/erase_if.cc:89: void some_op_sequence(Cntnr) [with Cntnr\ = pb_assoc::tree_assoc_cntnrint, char, std::lessint, pb_assoc::rb_tree_ds_tag, pb_assoc::null_node_updator, std::allocatorch\ ar ]: Assertion `c.size() == 20' failed.^M program stopped with signal 6.^M FAIL: ext/pb_assoc/example/erase_if.cc execution test There were changes to both the c++ and libstdc++ in this time-frame. Let's start with blaming libstdc++ as component. -- Summary: [4.1 regression] libstdc++ testsuite: ext/pb_assoc/example/erase_if.cc execution test Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: cris-axis-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug libstdc++/25815] [4.1 regression] libstdc++ testsuite: ext/pb_assoc/example/erase_if.cc execution test
--- Comment #1 from pcarlini at suse dot de 2006-01-17 02:21 --- For sure, no changes to the concerned library code. Considering that, to my best knowledge, nobody among the library maintainers has got such kind of system and that the problem is not reproducable elsewhere, it's highly unlikely that the problem will be fixed, be warned ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug rtl-optimization/25683] Error while running `make`
--- Comment #11 from gccbugzilla at multiwebinc dot com 2006-01-17 02:34 --- Their Detailed bug reporting instructions is not very detailed. I have no idea what I'm doing. What files do I provide you? I never have to `run gcc -v -save-temps all-your-options source-file`, I just do `configure` then `make`. For example, I tried to compile gaim from the directory gaim_configure with the source located in ../gaim-2.0.0beta1/. After I run configure and make I don't see any *.i* files in my gaim_configure directory, only in the source directory, which contains a few *.in files. Is this what you need? If so, which one(s)? It's full of subdirectories that contain other *.in files. I assumed that when you compile it from another directory that it doesn't change the files in the source directory at all. If this is correct, why would you need the original files, because I get errors when I try to compile anything. It's not just one package, it's all packages. I'm sure it's not an error in the source code. The root of the source directory contains the following .in files: config.h.in Doxyfile.in gaim.apspec.in gaim.pc.in gaim.spec.in Makefile.in VERSION.in There are 43 sub-folders, most of which contain Makefile.in or other .in files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25683
[Bug libstdc++/25815] [4.1 regression] libstdc++ testsuite: ext/pb_assoc/example/erase_if.cc execution test
--- Comment #2 from hp at gcc dot gnu dot org 2006-01-17 03:02 --- In response to comment #1: For the record, *all* library maintainers have access to such a system, AFAIK. I don't expect anyone to look into this, since it involves a few extra steps, some of which involve considerable machine time (installing a glibc port) if the host system isn't FC or Debian for ix86 or installing in /usr/local/cris isn't an option; however the test was performed _using a simulator_ with code publically available. Should anyone wish to actually repeat the problem, there are some notes in PR 22382 to get and install the glibc port (2.2.4-ish). The cris-sim.exp file is available from the dejagnu CVS, see head of PR 19745. Again, I don't expect anyone else to look at this; the PR is mostly for my own record-keeping. Use or ignore it as you please. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug rtl-optimization/25683] Error while running `make`
--- Comment #12 from gccbugzilla at multiwebinc dot com 2006-01-17 03:30 --- oh btw this is my gcc -v output: $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25683
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-17 03:49 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** --- Comment #8 from hainque at adacore dot com 2006-01-03 16:25 --- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 *** Right. Preliminary attempts at fixing this a while ago made it necessary to touch expand_expr and is_alignin_offset, fairly deep in the back end. As I understand the situation, fixing the above problem is quite involved. When the parisc-linux project moved to libc6 2.3.5, free was changed and the above error changed. The enclosed change is a work-around for the above problem. The problem is that the alignment provided by malloc is less than that needed for atomic_lock_t objects. This causes the ada runtime to round the pointer that it receives from malloc; but it doesn't retain the adjustment and the free operation has a 50% chance of failing. The linux libc code can accomodate an unaligned atomic_lock_t object under most circumstances. The main issue is that ada may detemine an incorrect struct layout. I have tested the above change on hppa-unknown-linux-gnu, 4.0 through trunk. Without this change, ada is essentially unusable. Thus, I recommend installing the change as a work-around until a proper fix can be developed. OK? Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) 2006-01-16 John David Anglin [EMAIL PROTECTED] PR ada/24533 * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. Index: s-osinte-linux-hppa.ads === --- s-osinte-linux-hppa.ads (revision 109788) +++ s-osinte-linux-hppa.ads (working copy) @@ -508,7 +508,7 @@ lock : lock_array; end record; pragma Convention (C, atomic_lock_t); - for atomic_lock_t'Alignment use 16; + for atomic_lock_t'Alignment use 8; type struct_pthread_fast_lock is record spinlock : atomic_lock_t; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug libgcj/25398] .jar files held open twice at runtime
--- Comment #1 from green at redhat dot com 2006-01-17 03:59 --- I discovered why we open all jar files twice. It happens in gnu/java/net/protocol/jar/Connection.java. While searching jar files, we call gnu.java.net.protocol.jar.Connection.getJarFile(). The first thing this does is call gnu.java.net.protocol.jar.Connection.connect(). This, in turn, calls jarFileURLConnection.connect(). jarFileURLConnection is a gnu.java.net.protocol.file.Connection (if we have a file URL). This opens the file. Then gnu.java.net.protocol.jar.Connection.getJarFile() continues. This special-cases local files, and we end up calling new JarFile([filename]). This opens the jar file for the second time. And that's how we end up with two open file descriptors for every jar file we process. We should probably figure out a way to avoid doing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25398
[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations
--- Comment #2 from gdr at cs dot tamu dot edu 2006-01-17 04:01 --- Subject: Re: Request for warning for parser ambiguity of function declarations and variable declarations with initializations pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Maybe if more C++ books actually talked about this issue, there would not be a | problem (sorry I could not resists). C++ books do take about it -- just check out the good ones. This very problem, if you check out writings from Bjarne or me (see, e.g., our proposal for generalized initializer list for discussions), is a problem inherited from the C syntax which permits redundant parenthesis in declarations, exacerbed by the functional notation. Check out details from DE. | Also warning about very valid and defined | code even if it is a common mistake that beginers make. I would rather have | people actually taught this rule than GCC warning about it. this is somehow hard to diagnose, but I guess one could engineer the front-end to remember redundant parens, but it would be rather low priority for me. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #5 from dick_guertin at yahoo dot com 2006-01-17 04:34 --- Subject: Re: -O2 execution fails, -O and -g work I have created a 'wylsrc.tgz' file and made it available for download over the web. I updated the Bugzilla report # 25791 accordingly. Be sure to read 'a.readme.txt'. Dick Guertin --- pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-16 23:20 --- Yes we need the proprocessed source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC| |pinskia at gcc dot gnu dot ||org Component|c |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug regression/25816] New: [4.1/4.2 Regression] Configure detects TLS, but glibc does not support it.
I have a mipsel-linux system with glibc 2.3.3 which does not support TLS. Due to bugs in earlier binutils versions, I must use a binutils version that does support TLS on mips. The GCC configure does an assembler check to see if TLS is supported and then generates code based on that decision. When this happens with no TLS support in glibc, there is a link error due to lack of TLS support in glibc. I am testing a patch that adds a --disable-tls option to configure to force it to not use TLS. This was not a problem on 4.0 and earlier as there was no mips TLS support in GCC in those versions. I am calling it a regression as I used to be able to use GCC and with 4.1 I cannot. The test case is to compile any java program with mipsel-linux-gcj. A linker error results. -- Summary: [4.1/4.2 Regression] Configure detects TLS, but glibc does not support it. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: link-failure Severity: normal Priority: P3 Component: regression AssignedTo: daney at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: mipsel-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25816
[Bug bootstrap/25794] gcc won't link to new local glibc
--- Comment #6 from davek at csh dot rit dot edu 2006-01-17 06:20 --- I've gotten the compile to continue by cross compiling and altering the Makefile between stage 1 and 2 (or wherever it errored). $ diff -u orig/gcc-4.0.2/gcc/Makefile.in gcc-4.0.2/gcc/Makefile.in --- orig/gcc-4.0.2/gcc/Makefile.in Fri Sep 9 17:05:39 2005 +++ gcc-4.0.2/gcc/Makefile.in Mon Jan 16 19:49:17 2006 @@ -623,7 +623,7 @@ BUILD_CFLAGS= @BUILD_CFLAGS@ -DGENERATOR_FILE # Native linker and preprocessor flags. For x-fragment overrides. -BUILD_LDFLAGS=$(LDFLAGS) +BUILD_LDFLAGS=$(LDFLAGS) -Wl,--dynamic-linker,/usr/glibc2/lib/ld-linux.so.2 -Wl,-rpath,/usr/glibc2/lib BUILD_CPPFLAGS=$(ALL_CPPFLAGS) # Actual name to use when installing a native compiler. @@ -1163,8 +1163,9 @@ # and CC is `gcc'. It is renamed to `gcc' when it is installed. xgcc$(exeext): gcc.o gccspec.o version.o intl.o prefix.o \ version.o $(LIBDEPS) $(EXTRA_GCC_OBJS) - $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ gcc.o gccspec.o intl.o \ + $(CC) -Wl,--dynamic-linker,/usr/glibc2/lib/ld-linux.so.2 $(ALL_CFLAGS) $(LDFLAGS) -o $@ gcc.o gccspec.o intl.o \ prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) +# -Wl,-rpath,/usr/glibc2/lib # cpp is to cpp0 as gcc is to cc1. # The only difference from xgcc is that it's linked with cppspec.o I had to comment out rpath part when it gave linker errors. Then continued until another set of errors and then took out the comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25794
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-01-17 06:59 --- (gdb) run Starting program: /afs/ir.stanford.edu/users/g/u/guertin/wylsrc/wylbur.ge Program received signal SIGILL, Illegal instruction. 0x00297064 in hex_to_character () (gdb) where #0 0x00297064 in hex_to_character () #1 0x00297068 in hex_to_character () Previous frame identical to this frame (corrupt stack?) Could you post an excerpt of the assembly code around 0x00297064? As you can see, your suggested change did NOT fix the 'problem'. Well, it was not meant to, my wording was and see what happens. What is obvious to me is that -O2 is affecting address computations. What did you mean exactly? Sure, -O2 is expected to have a negative impact on debugging. There shouldn't be any way to clobber the stack unless addresses are mis-computed or not stored into variables when they should. As far as I'm concerned, -O2 is a violation of the ISO standards concerning Optimization. Well, if there is a code generation bug somewhere, things are expected to go badly at some point. That doesn't mean we should throw the baby with the bath water. If you need the source code, I can bundle it into a tar.z file and make it available for download over the web. No, we need a preprocessed testcase, preferably a runnable testcase but a compilable one is sufficient if you can pinpoint the miscompilation. That's explained at the URL I previously posted: http://gcc.gnu.org/bugs.html. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug ada/20753] ACATS ce3810b segfaults at runtime
--- Comment #10 from laurent at guerby dot net 2006-01-17 07:37 --- Present on 4.1 in 200601 for: sparc-linux http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00635.html sparc-solaris http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00504.html s390-linux http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00631.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20753
[Bug bootstrap/25794] gcc won't link to new local glibc
--- Comment #7 from davek at csh dot rit dot edu 2006-01-17 07:41 --- a better patch - --- orig/gcc-4.0.2/gcc/Makefile.in Fri Sep 9 17:05:39 2005 +++ gcc-4.0.2/gcc/Makefile.in Mon Jan 16 21:40:20 2006 @@ -73,6 +73,9 @@ srcdir = @srcdir@ docdir = @srcdir@/doc +# hack +BOOT_LDFLAGS = -Wl,--dynamic-linker,/usr/glibc2/lib/ld-linux.so.2 -Wl,-rpath,/usr/glibc2/lib + # Directory where sources are, absolute. abs_srcdir = @abs_srcdir@ abs_docdir = @abs_srcdir@/doc I can't define it on the makefile line, because I have to change it throughout the build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25794
[Bug bootstrap/25794] gcc won't link to new local glibc
--- Comment #8 from davek at csh dot rit dot edu 2006-01-17 07:45 --- I see gcc-bugs@gcc.gnu.org in the cc list, and I can't remove it. I was just using this as my notebook for this problem. I thought no email was sent on resolved bugs, but now I see I'm getting emails. Who's getting these posts in emails? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25794
