[Bug target/29776] New: result of ffs/clz/ctz/popcount/parity are already sign-extended
unfortunately the ffs/clz/ctz/popcount/parity builtins are defined to return
signed types despite the fact they are either undefined or return a
non-negative integer. as a result unnecessary sign extension occurs. for
example in this case the result of bsf could be used directly in the mask[]
index.
-dean
% cat ctz.c
unsigned mask[8];
unsigned foo(unsigned y, unsigned char x)
{
return y & mask[__builtin_ctz(x)];
}
% ~/gcc/bin/gcc -g -O3 -Wall -c ctz.c
% objdump -dr ctz.o
ctz.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 40 0f b6 f6 movzbl %sil,%esi
4: 0f bc f6bsf%esi,%esi
7: 48 63 f6movslq %esi,%rsi
a: 23 3c b5 00 00 00 00and0x0(,%rsi,4),%edi
d: R_X86_64_32S mask
11: 89 f8 mov%edi,%eax
13: c3 retq
% ~/gcc/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/odo/gcc --enable-languages=c
--enable-targets=x86_64-unknown-linux-gnu x86_64-unknown-linux-gnu :
(reconfigured) ../gcc/configure --prefix=/home/odo/gcc --enable-languages=c
--without-mudflap --disable-biarch x86_64-unknown-linux-gnu : (reconfigured)
../gcc/configure --prefix=/home/odo/gcc --enable-languages=c --disable-multilib
--disable-biarch x86_64-unknown-linux-gnu
Thread model: posix
gcc version 4.3.0 20061104 (experimental)
--
Summary: result of ffs/clz/ctz/popcount/parity are already sign-
extended
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
[Bug target/29775] New: redundant movzbl
in the following code, the compiler zero-extends the same byte twice... there's
something about using byte0 in an if () statement which triggers this -- if you
comment out the if() the problem goes away.
-dean
% cat redundant_movzbl.c
unsigned foo(unsigned char *p)
{
unsigned byte0 = *p;
unsigned len = __builtin_ctz(byte0) + 1;
if (byte0 == 0) return 0;
return len;
}
% ~/gcc/bin/gcc -g -O3 -Wall -c redundant_movzbl.c
% objdump -dr redundant_movzbl.o
redundant_movzbl.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 0f b6 07movzbl (%rdi),%eax
3: 31 d2 xor%edx,%edx
5: 84 c0 test %al,%al
7: 74 09 je 12
9: 0f b6 c0movzbl %al,%eax
c: 0f bc c0bsf%eax,%eax
f: 8d 50 01lea0x1(%rax),%edx
12: 89 d0 mov%edx,%eax
14: c3 retq
% ~/gcc/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/odo/gcc --enable-languages=c
--enable-targets=x86_64-unknown-linux-gnu x86_64-unknown-linux-gnu :
(reconfigured) ../gcc/configure --prefix=/home/odo/gcc --enable-languages=c
--without-mudflap --disable-biarch x86_64-unknown-linux-gnu : (reconfigured)
../gcc/configure --prefix=/home/odo/gcc --enable-languages=c --disable-multilib
--disable-biarch x86_64-unknown-linux-gnu
Thread model: posix
gcc version 4.3.0 20061104 (experimental)
--
Summary: redundant movzbl
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29775
[Bug c++/29767] partial specialization enclosed templates within the declaration of the enclosed class.
--- Comment #7 from bangerth at dealii dot org 2006-11-09 05:35 --- (In reply to comment #0) > gcc and msvc accept such code but produces different results. > is this code (in)valid? i'm not sure what behaviour is correct. The code is valid because it is a *partial* specialization of the member template class. It would be invalid if it were a *complete* specialization. In that case, the complete specialization would have to be declared outside the outer class, i.e. at namespace scope. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29767
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #9 from bangerth at dealii dot org 2006-11-09 05:33 ---
PR29767 made me try whether we can achieve the same wrong effect for
template type parameters, and indeed we can:
template struct outer {
template
struct inner {
static int f() { return inner::N; };
};
template
struct inner {
static const int N = 1;
};
};
int i = outer::inner::f();
--
This compiles with icc, but doesn't with gcc:
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc: In static member function ‘static int outer::inner::f()
[with T2 = double, U = int, T = int]’:
x.cc:13: instantiated from here
x.cc:4: error: ‘N’ is not a member of ‘outer::inner’
As PR29767 shows, this can actually lead to wrong code.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
Summary|non type boolean template |Specialization of inner
|argument partial|template using outer
|specialization to argument |template argument doesn't
|in parent never matches |work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug c++/14032] non type boolean template argument partial specialization to argument in parent never matches
--- Comment #8 from bangerth at dealii dot org 2006-11-09 05:25 --- *** Bug 29767 has been marked as a duplicate of this bug. *** -- bangerth at dealii dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug c++/29767] partial specialization enclosed templates within the declaration of the enclosed class.
--- Comment #6 from bangerth at dealii dot org 2006-11-09 05:25 --- Indeed. They are duplicates. *** This bug has been marked as a duplicate of 14032 *** -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29767
[Bug c/29774] enum int type gets promoted to unsigned int in comparison
--- Comment #2 from chris dot pickett at mail dot mcgill dot ca 2006-11-09 04:46 --- I got confused. It's only the enum constant that must be int. Indeed, if the comparison is `if (FOO >= 0)', no warning is issued and all is well. Thanks for the extremely fast response! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29774
[Bug c/29774] enum int type gets promoted to unsigned int in comparison
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-09 04:37 --- http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Structures-unions-enumerations-and-bit_002dfields-implementation.html You are incorrect in saying enum are compatiable with int by default and incorrect in saying the C standard says that. What it says it is compatiable with an implemenation defined integer type. And we define that as the following: # The integer type compatible with each enumerated type (C90 6.5.2.2, C99 6.7.2.2). Normally, the type is unsigned int if there are no negative values in the enumeration, otherwise int. If -fshort-enums is specified, then if there are negative values it is the first of signed char, short and int that can represent all the values, otherwise it is the first of unsigned char, unsigned short and unsigned int that can represent all the values. On some targets, -fshort-enums is the default; this is determined by the ABI. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29774
[Bug c/29774] New: enum int type gets promoted to unsigned int in comparison
$ cat enum-test.c
enum foo_enum { FOO };
int
main (void)
{
enum foo_enum foo;
if (foo >= FOO)
{
}
}
$ gcc -Wextra enum-test.c
enum-test.c: In function 'main':
enum-test.c:7: warning: comparison of unsigned expression >= 0 is always true
I looked through existing bug reports but didn't find this. If it's a dupe,
please let me know what I should have searched for.
Here is an old thread I found about a related test-case:
http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00772.html
I'm not sure, but even if it's only C99 that says enums have to be ints, the
promotion shouldn't happen for C89 either.
--
Summary: enum int type gets promoted to unsigned int in
comparison
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris dot pickett at mail dot mcgill dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29774
[Bug fortran/29752] [4.2/4.3 Regression] write(*,*,advance='NO'), READ(): Data not flushed
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-11-09 03:37 --- Fixed on 4.2 and 4.3. -- jvdelisle 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=29752
[Bug fortran/29752] [4.2/4.3 Regression] write(*,*,advance='NO'), READ(): Data not flushed
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-11-09 03:32 --- Subject: Bug 29752 Author: jvdelisle Date: Thu Nov 9 03:32:19 2006 New Revision: 118612 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118612 Log: 2006-11-08 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/29752 * io/transfer.c (finalize_transfer): Flush on ADVANCE_NO. Modified: branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29752
[Bug fortran/29752] [4.2/4.3 Regression] write(*,*,advance='NO'), READ(): Data not flushed
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-11-09 03:03 --- Subject: Bug 29752 Author: jvdelisle Date: Thu Nov 9 03:03:40 2006 New Revision: 118611 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118611 Log: 2006-11-08 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/29752 * io/transfer.c (finalize_transfer): Flush on ADVANCE_NO. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29752
[Bug c++/29773] New: name mangling for nested functions is wrong
Given the following translation unit:
inline int (*foo())()
{
struct localstruct {
static int f() {
return 3;
}
};
return localstruct::f;
}
GCC mangles foo::localstruct::f as '_ZZ3foovEN11localstruct1fEv'.
According to the C++ ABI (see especially the third example in section 5.1.6) it
should be
_ZNZ3foovE11localstruct1fEv
That is, it should be at the top level,
not a .
This is of course an ABI-breaking change.
--
Summary: name mangling for nested functions is wrong
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ABI
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29773
[Bug fortran/29752] [4.2/4.3 Regression] write(*,*,advance='NO'), READ(): Data not flushed
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-11-09 02:05 --- I will look into this tonight. -- 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|2006-11-08 19:20:11 |2006-11-09 02:05:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29752
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #19 from hjl at lucon dot org 2006-11-09 01:53 --- Created an attachment (id=12574) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12574&action=view) A patch This reverts the patch which triggers the problem and adds a testcase. I am running SPEC CPU 2006 now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug fortran/29431] Not Implemented: complex character array constructors
--- Comment #2 from patchapp at dberlin dot org 2006-11-09 00:20 --- Subject: Bug number PR29431 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00532.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29431
[Bug fortran/29758] Runtime segfault in RESHAPE with insufficient elements in SOURCE
--- Comment #1 from patchapp at dberlin dot org 2006-11-09 00:20 --- Subject: Bug number PR29758 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00531.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29758
[Bug tree-optimization/29738] Missed constant propagation into loops
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-11-09 00:09 --- Subject: Bug 29738 Author: rakdver Date: Thu Nov 9 00:09:43 2006 New Revision: 118602 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118602 Log: PR tree-optimization/29738 * tree-ssa-ccp.c: Remove UNKNOWN_VAL from comments. (ccp_lattice_t): Remove UNKNOWN_VAL. (dump_lattice_value, ccp_lattice_meet, ccp_visit_phi_node): Do not handle UNKNOWN_VAL. (get_default_value): Set initial value of virtual operands to VARYING. (get_value): Always use get_default_value on uninitialized operands. (set_value_varying, surely_varying_stmt_p): New functions. (set_lattice_value): Do not pass argument to get_value. Do not handle UNKNOWN_VAL. (likely_value): Follow the semantics described in the comment. (ccp_initialize): Use surely_varying_stmt_p. Do not mark phi nodes DONT_SIMULATE_AGAIN. (ccp_fold): Do not pass argument to get_value. (fold_const_aggregate_ref, visit_assignment): Ditto. Do not handle UNKNOWN_VAL. * gcc.dg/tree-ssa/ssa-ccp-14.c: New test. * gcc.dg/tree-ssa/ssa-ccp-15.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-14.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-15.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #8 from kkojima at gcc dot gnu dot org 2006-11-08 23:53 --- I don't see ICEs for the tls tests on my sh-elf build with your patches in #6 and #7. Does the new patch in #7 fix them? I've confirmed that the trunk bootstraps successfully with the patch in #4 and a one-liner to suppress a bogus compile time warning. Should I send it to the list as a workaround this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug c/29771] u != '\377' always true (u is unsigned char)
--- Comment #2 from r dot c dot ladan at gmail dot com 2006-11-08 23:52 --- (In reply to comment #1) > '\377' in C is of type int. > Ok, the comparison works with (u != 0xff), thus without the quotes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29771
[Bug c++/20133] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in import_export_decl, at cp/decl2.c:1726
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-11-08 23:47 --- *** Bug 29766 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ypwangandy at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20133
[Bug c++/29766] Template Specialization break down
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-08 23:47 --- *** This bug has been marked as a duplicate of 20133 *** -- 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=29766
[Bug c++/29766] Template Specialization break down
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-08 23:46 ---
Reduced testcase:
template
struct mytree {
static int counter;
};
template int mytree::counter = 0;
---
Now I have seen this before, this is invalid code you should be doing:
template<> int mytree::counter = 0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29766
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #7 from sergstesh at yahoo dot com 2006-11-08 23:29 --- OK, being in /maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6 directory, which is my 'obj' directory, I tried to run the 'test_summary' mentioned at the bottom of http://gcc.gnu.org/install/test.html : " 0.5 Submitting test results If you want to report the results to the GCC project, use the contrib/test_summary shell script. Start it in the objdir with srcdir/contrib/test_summary -p your_commentary.txt \ -m [EMAIL PROTECTED] |sh This script uses the Mail program to send the results, so make sure it is in your PATH. The file your_commentary.txt is prepended to the testsuite summary and should contain any special remarks you have on your results or your build environment. Please do not edit the testsuite result block or the subject line, as these messages may be automatically processed. ". Please pay attention to " This script uses the Mail program to send the results, so make sure it is in your PATH ". On my system: " [21] 1:20 [EMAIL PROTECTED]:/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6> which mail /bin/mail ". However, here's what I'm getting running the program: " ../gcc-3.4.6.src/contrib/test_summary -p /dev/null -m [EMAIL PROTECTED] | sh /usr/sbin/sendmail: No such file or directory "/ibm/home/sergei/dead.letter" 103/2351 . . . message not sent. ". So, should I file a bug against http://gcc.gnu.org/install/test.html because of 'mail' <-> /usr/sbin/sendmail discrepancy ? Anyway, I looked into /ibm/home/sergei/dead.letter file and it contains pretty much the same info I've already posted. If you insist, I can install /usr/sbin/sendmail and try again. Maybe you already have enough info to tell me which of the tests fail due to: 1) problems in the compiler; 2) problems in glibc; 3) problems in the tests themselves ? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug c++/29766] Template Specialization break down
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-08 23:23 --- The new ICE is: t.cc: In member function 'mytree& mytree::insert(mytree*, mytree*, mytree*, bool) [with C = int]': t.cc:54: instantiated from 'int mytree::counter' t.cc:54: instantiated from 'mytree& mytree::insert(mytree*, mytree*, mytree*, bool) [with C = int]' t.cc:137: instantiated from here t.cc:54: internal compiler error: in instantiate_decl, at cp/pt.c:12053 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29766
[Bug c++/29767] partial specialization enclosed templates within the declaration of the enclosed class.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-08 23:18 --- (In reply to comment #4) > This is a duplicate of another PR where we forget to substitute an > outer template argument in the specialization of an inner template. > I think it concerned a boolean value in that case, rather than a type. That is PR 14032. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||14032 Summary|specialization enclosed |partial specialization |templates within the|enclosed templates within |declaration of the enclosed |the declaration of the |class. |enclosed class. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29767
[Bug bootstrap/28324] boostrapping with gcc fails with unrecognized linker option
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-08 23:14 --- (In reply to comment #7) > If I configure with --prefix, as here: > > # ../gcc-4.1.1/configure --prefix=/usr/multiware --with-gnu-as > --with-as=/usr/multiware/bin/as --disable-wchar_t > --enable-languages=c,c++,objc > /usr/multiware/mips-sgi-irix6.5/bin/ld > is the GNU linker, > the default IRIX ld is in /usr/bin/ld and the GNU assembler is not in the > default path. Except we search the prefix for ld/as first and then the normal directories so that is not a bug, use --with-gnu-ld then. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28324
[Bug bootstrap/28324] boostrapping with gcc fails with unrecognized linker option
--- Comment #7 from multix at gmail dot com 2006-11-08 23:11 --- If I configure with --prefix, as here: # ../gcc-4.1.1/configure --prefix=/usr/multiware --with-gnu-as --with-as=/usr/multiware/bin/as --disable-wchar_t --enable-languages=c,c++,objc I get the following error during build: ./xgcc -B./ -B/usr/multiware/mips-sgi-irix6.5/bin/ -isystem /usr/multiware/mips-sgi-irix6.5/include -isystem /usr/multiware/mips-sgi-irix6.5/sys-include -L/usr/people/multix/gccbuildware/gcc/../ld -O2 -O2 -O -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,-soname,libgcc_s.so.1 -o ./libgcc_s.so.1.tmp libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_floatdidf_s.o libgcc/./_floatdisf_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./_pack_sf_s.o libgcc/./_unpack_sf_s.o libgcc/./_addsub_sf_s.o libgcc/./_mul_sf_s.o libgcc/./_div_sf_s.o libgcc/./_fpcmp_parts_sf_s.o libgcc/./_compare_sf_s.o libgcc/./_eq_sf_s.o libgcc/./_ne_sf_s.o libgcc/./_gt_sf_s.o libgcc/./_ge_sf_s.o libgcc/./_lt_sf_s.o libgcc/./_le_sf_s.o libgcc/./_unord_sf_s.o libgcc/./_si_to_sf_s.o libgcc/./_sf_to_si_s.o libgcc/./_negate_sf_s.o libgcc/./_make_sf_s.o libgcc/./_sf_to_df_s.o libgcc/./_sf_to_tf_s.o libgcc/./_thenan_sf_s.o libgcc/./_sf_to_usi_s.o libgcc/./_usi_to_sf_s.o libgcc/./_pack_df_s.o libgcc/./_unpack_df_s.o libgcc/./_addsub_df_s.o libgcc/./_mul_df_s.o libgcc/./_div_df_s.o libgcc/./_fpcmp_parts_df_s.o libgcc/./_compare_df_s.o libgcc/./_eq_df_s.o libgcc/./_ne_df_s.o libgcc/./_gt_df_s.o libgcc/./_ge_df_s.o libgcc/./_lt_df_s.o libgcc/./_le_df_s.o libgcc/./_unord_df_s.o libgcc/./_si_to_df_s.o libgcc/./_df_to_si_s.o libgcc/./_negate_df_s.o libgcc/./_make_df_s.o libgcc/./_df_to_sf_s.o libgcc/./_df_to_tf_s.o libgcc/./_thenan_df_s.o libgcc/./_df_to_usi_s.o libgcc/./_usi_to_df_s.o libgcc/./_pack_tf_s.o libgcc/./_unpack_tf_s.o libgcc/./_addsub_tf_s.o libgcc/./_mul_tf_s.o libgcc/./_div_tf_s.o libgcc/./_fpcmp_parts_tf_s.o libgcc/./_compare_tf_s.o libgcc/./_eq_tf_s.o libgcc/./_ne_tf_s.o libgcc/./_gt_tf_s.o libgcc/./_ge_tf_s.o libgcc/./_lt_tf_s.o libgcc/./_le_tf_s.o libgcc/./_unord_tf_s.o libgcc/./_si_to_tf_s.o libgcc/./_tf_to_si_s.o libgcc/./_negate_tf_s.o libgcc/./_make_tf_s.o libgcc/./_tf_to_df_s.o libgcc/./_tf_to_sf_s.o libgcc/./_thenan_tf_s.o libgcc/./_tf_to_usi_s.o libgcc/./_usi_to_tf_s.o libgcc/./fixtfdi_s.o libgcc/./fixunstfdi_s.o libgcc/./floatditf_s.o libgcc/./floatunditf_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde_s.o libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so /usr/multiware/mips-sgi-irix6.5/bin/ld: unrecognized option '-_SYSTYPE_SVR4' /usr/multiware/mips-sgi-irix6.5/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status if I give the SAME configure line but without specifying --prefix, the compiler builds and installs in /usr/local. It builds a simple hello.c program /usr/multiware/mips-sgi-irix6.5/bin/ld is the GNU assembler, ther eis NO assembler in /usr/local/bin the default IRIX ld is in /usr/bin/ld and the GNU assembler is not in the default path. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28324
[Bug c++/29767] [accept invalid?] specialization enclosed templates within the declaration of the enclosed class.
--- Comment #4 from bangerth at dealii dot org 2006-11-08 22:57 --- This is a duplicate of another PR where we forget to substitute an outer template argument in the specialization of an inner template. I think it concerned a boolean value in that case, rather than a type. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29767
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-08 22:48 --- Some failures are also due to faulty glibc, etc. and not related to GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-08 22:47 --- > 1) do the failing tests indicate problems in gcc ? Depends on the failure. > 2) do the failing test fail because they themselves are faulty ? Depends on the failures. You might want to look at http://gcc.gnu.org/gcc-3.4/buildstat.html And the other buildstat.html for the other releases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #4 from sergstesh at yahoo dot com 2006-11-08 22:43 --- I read the document: http://gcc.gnu.org/install/test.html, but it doesn't answer my questions. If you need test results reported through the suggested srcdir/contrib/test_summary -p your_commentary.txt \ -m [EMAIL PROTECTED] |sh command, I can do this, but will you answer the " 1) do the failing tests indicate problems in gcc ? 2) do the failing test fail because they themselves are faulty ? " questions ? If not, why should I bother in the first place ? If yes, what info other than the one produced by srcdir/contrib/test_summary -p your_commentary.txt \ -m [EMAIL PROTECTED] |sh do you need ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug fortran/29758] Runtime segfault in RESHAPE with insufficient elements in SOURCE
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-08 22:38:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29758
[Bug fortran/29755] [4.2 only] ICE on same name in subroutine and program
--- Comment #3 from burnus at gcc dot gnu dot org 2006-11-08 22:35 ---
Just for completeness, the ICE also occurs with 4.1
! { dg-do compile }
! { dg-shouldfail "same name of program and subroutine" }
! Tests whether ICE occurs when using the same name
! for a subroutine as for the program
! PR fortran/29755
program foo
type myType
integer :: i
end type myType
interface
subroutine foo(x)! { dg-error "PROGRAM attribute conflicts with PROCEDURE"
}
type(myType) :: i! { dg-error "Unexpected data declaration statement" }
end subroutine foo ! { dg-error "Expecting END INTERFACE statement" }
end interface
call foo() ! { dg-error "PROGRAM attribute conflicts with PROCEDURE" }
end program foo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29755
[Bug fortran/29755] [4.2 only] ICE on same name in subroutine and program
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |NEW Last reconfirmed|2006-11-08 22:23:12 |2006-11-08 22:24:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29755
[Bug fortran/29755] [4.2 only] ICE on same name in subroutine and program
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29755
[Bug fortran/29755] [4.2 only] ICE on same name in subroutine and program
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-08 22:23 --- On the trunk, the ICE is fixed by some other check in. It still occurs on the 4.2 branch (r118599, current version) Using my patch on the current trunk (118597) causes lots of regression, i.e. either the trunk has changed or my patch is nonsense or both. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-11-07 22:14:15 |2006-11-08 22:23:12 date|| Summary|ICE on same name in |[4.2 only] ICE on same name |subroutine and program |in subroutine and program http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29755
[Bug middle-end/29756] SSE intrinsics hard to use without redundant temporaries appearing
--- Comment #4 from timday at bottlenose dot demon dot co dot uk 2006-11-08 22:18 --- Created an attachment (id=12573) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12573&action=view) More concise demonstration of the v4sf->float->v4sf issue. The attached code, (no classes or unions, just a few inline functions) obtained from gcc -v -save-temps -S -O3 -march=pentium3 -mfpmath=sse -msse -fomit-frame-pointer v4sf.cpp compiles transform_good to 18 instructions and transform_bad to 33. However it's not really surprising a round-trip through stack temporaries is required when pointer arithmetic is being used to extract a float from a __v4sf. I've no idea whether it's realistic to hope this could ever be optimised away. Alternatively, it would be very nice if the builtin vector types simply provided a [] operator, or if there were some intrinsics for extracting floats from a __v4sf. (In the meantime, in the original vector4f class, remaining in the __v4sf domain by having the const operator[] return a suitably type-wrapped __v4sf "filled" with the specified component seems to be a promising direction). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29756
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #43 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-08 22:16 --- Subject: Re: [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test > Yes, I'm investigating. Ultimately I could always resort to conditionalizing > my change on HAVE_COMDAT_GROUP, but that would be more of a kludge. Things are still broken on hppa-linux. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-08 22:00 --- (In reply to comment #2) > I do not understand you comment. Documented at: http://gcc.gnu.org/install/test.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug c/29771] u != '\377' always true (u is unsigned char)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-08 21:58 --- '\377' in C is of type int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29771
[Bug java/29772] using @sourcelist-file leads to wrong flag creation
--- Comment #3 from mtrudel at gmx dot ch 2006-11-08 21:55 --- Created an attachment (id=12572) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12572&action=view) The list for the source files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29772
[Bug java/29772] using @sourcelist-file leads to wrong flag creation
--- Comment #2 from mtrudel at gmx dot ch 2006-11-08 21:54 --- Created an attachment (id=12571) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12571&action=view) A second sample source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29772
[Bug java/29772] using @sourcelist-file leads to wrong flag creation
--- Comment #1 from mtrudel at gmx dot ch 2006-11-08 21:54 --- Created an attachment (id=12570) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12570&action=view) A sample source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29772
[Bug java/29772] New: using @sourcelist-file leads to wrong flag creation
Create a dir named "foo bar". Put the attached HelloWorld.java, HelloWorld2.java and source.txt in it. source.txt has this two lines: foo\ bar/HelloWorld.java foo\ bar/HelloWorld2.java Change to the parent folder and type: gcj --main=HelloWorld -o HelloWorld @"foo bar/source.txt" It will fail with: foo:0: warning: duplicate class will only be compiled once fatal error: can't open foo: No such file or directory compilation terminated. It will work when: - -o is omitted - the space between -o and HelloWorld is removed: gcj --main=HelloWorld -oHelloWorld @"foo bar/source.txt" - the files in source.txt have no spaces - when only one file is in source.txt (with spaces) -- Summary: using @sourcelist-file leads to wrong flag creation Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: independent GCC host triplet: independent GCC target triplet: independent http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29772
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #2 from sergstesh at yahoo dot com 2006-11-08 21:44 --- I do not understand you comment. That is, from 'make' manpage: " -k Continue as much as possible after an error. While the target that failed, and those that depend on it, cannot be remade, the other dependencies of these targets can be processed all the same. " - my point was that there were failing tests. And my implied questions were: 1) do the failing tests indicate problems in gcc ? 2) do the failing test fail because they themselves are faulty ? After 'make check': " FAIL: gcc.c-torture/execute/va-arg-25.c execution, -Os FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test FAIL: gcc.dg/special/gcsec-1.c (test for excess errors) FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) FAIL: abi_check ". After 'make -k check': " FAIL: gcc.c-torture/execute/va-arg-25.c execution, -Os FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test FAIL: gcc.dg/special/gcsec-1.c (test for excess errors) FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) FAIL: abi_check FAIL: gctest ". Could you please answer the: " 1) do the failing tests indicate problems in gcc ? 2) do the failing test fail because they themselves are faulty ? " questions ? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug fortran/29630] "Unclassifiable statement" with vector subscripts in initialization
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-11-08 21:20 --- fixed. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29630
[Bug fortran/29679] Inability to get shapes correct in initializations
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-11-08 21:19 --- fixed. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29679
[Bug fortran/29630] "Unclassifiable statement" with vector subscripts in initialization
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-11-08 21:19 --- Subject: Bug 29630 Author: eedelman Date: Wed Nov 8 21:19:01 2006 New Revision: 118599 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118599 Log: 2006-11-08 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-08 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29630
[Bug fortran/29679] Inability to get shapes correct in initializations
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-11-08 21:19 --- Subject: Bug 29679 Author: eedelman Date: Wed Nov 8 21:19:01 2006 New Revision: 118599 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118599 Log: 2006-11-08 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-08 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29679
[Bug fortran/29679] Inability to get shapes correct in initializations
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-11-08 21:14 --- Subject: Bug 29679 Author: eedelman Date: Wed Nov 8 21:14:06 2006 New Revision: 118598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118598 Log: fortran/ 2006-11-08 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-08 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29679
[Bug fortran/29630] "Unclassifiable statement" with vector subscripts in initialization
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-11-08 21:14 --- Subject: Bug 29630 Author: eedelman Date: Wed Nov 8 21:14:06 2006 New Revision: 118598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118598 Log: fortran/ 2006-11-08 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-08 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29630
[Bug c/29771] New: u != '\377' always true (u is unsigned char)
Compiling this program using -Wall -Wcast-qual:
#include
int main(int argc, char *argv[]) {
unsigned char u;
u = '\377';
printf("u=%i\n", u); /* 255, as expected */
/* if (u != '\0')*//* ok */
if (u != '\377')/* ERROR (?) : always true due to
limited range of data type */
printf("wow");
return(0);
}
gives the warning "comparison is always true due to limited range of data type"
platform is i386/Pentium 4M running FreeBSD 6.2-BETA3
Note the operator !=
Also, the complementary comparison u != '\0' does *not* give a warning
"comparison is always false due to limited data type"
--
Summary: u != '\377' always true (u is unsigned char)
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot c dot ladan at gmail dot com
GCC build triplet: i386-undermydesk-freebsd
GCC host triplet: i386-undermydesk-freebsd
GCC target triplet: i386-undermydesk-freebsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29771
[Bug fortran/28849] Missed array shape violation with RESHAPE despite -fbounds-check
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-08 20:48 ---
> In this case neither sunf95 nor NAGf95 find the error.
This is actually wrong; both find it.
In my example the original tree looks like (shortend): foo (__result, n)
ubound.0 = (int8) *n;
S.4 = 1;
while (1)
{
if (S.4 > ubound.0) goto L.1; else (void) 0;
(*__result.0)[NON_LVALUE_EXPR * D.1347 + D.1345] = 4.2e+1;
S.4 = S.4 + 1;
}
L.1:;
Thus one should check
"ubound.0*stride.1+offset.2 > __result->dim[0].ubound"
and
"1 *stride.1+offset.2 < __result->dim[0].lbound"
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #37 from michaelni at gmx dot at 2006-11-08 20:45 ---
(In reply to comment #36)
> (In reply to comment #21)
> > asm volatile(""
> > : "=m" (*(unsigned int*)(src + 0*stride)),
> > "=m" (*(unsigned int*)(src + 1*stride)),
> > "=m" (*(unsigned int*)(src + 2*stride)),
> > "=m" (*(unsigned int*)(src + 3*stride)),
> > "=m" (*(unsigned int*)(src + 4*stride)),
> > "=m" (*(unsigned int*)(src + 5*stride)),
> > "=m" (*(unsigned int*)(src + 6*stride)),
> > "=m" (*(unsigned int*)(src + 7*stride))
> > );
>
> (In reply to comment #26)
> > it might also happen that in some intentionally overconstrained cases it
> > ends up
> > searching the whole 5040 possible assignments of 7 registers onto 7 non
> > memory
> > operands but still it wont fail
>
> The example Martin gave has *8* operands. You can try every possible direct
> mapping of those 8 addresses to just 7 registers, but they will obviously all
> fail. Except with ia32 addressing modes it _can_ be done, and with only 4
> registers.
>
> reg1 = src, reg2 = stride, reg3 = src+stride*3, reg4 = src+stride*6
> Then the 8 memory operands are:
> (reg1), (reg1,reg2,1), (reg1,reg2,2), (reg3),
> (reg1,reg2,4), (reg3,reg2,2), (reg4), (reg3,reg2,4)
>
> When one considers all the addressing modes, there are not just 7 possible
> registers, but (I think) 261 possible addresses. There are not just 5040
> possibilities as Michael said, but over 76 x 10^15 possible ways of assigning
> these addresses to 7 operands! Then each register can be loaded not just with
> an address but with some sub-expression too, like how I loaded reg2 with
> stride.
"m" operands and variations can be copied onto the stack and accessed from
there, so no matter how many memory operands there are they can always be
accessed over esp on ia32, so whatever you did calculate it is meaningless
now if there is a unwritten rule that "m" operands and variations of them
cannot be copied anywhere, then it would be very desireable to have a asm
constraint like "m" without this restriction this would resolve this and
several other bugs
also it would be very nice if such a dont copy restriction on "m" if it does
exist could be documented
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug fortran/28849] Missed array shape violation with RESHAPE despite -fbounds-check
--- Comment #5 from burnus at gcc dot gnu dot org 2006-11-08 20:08 --- Postscriptum: sunf95 already finds the problem in the program "check" at compile time. For non-intrinsics (non libgfortran) routines, one way to do it is too do it in the function called. (Internally called as foo (&parm.5, D.1358);) That way one could even detect the problem if one moves the "foo" function out of the "program" and uses an "interface". In this case neither sunf95 nor NAGf95 find the error. But what would be the best way for the library? Adding a check version to it? Adding a if(flag) to it (may slow down)? Both NAG f95 and sunf95 seem to expand those intrinsics (pack, reshape, transpose) rather than using a library call and add then the check directly in the tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #36 from xyzzy at speakeasy dot org 2006-11-08 20:03 ---
(In reply to comment #21)
> asm volatile(""
> : "=m" (*(unsigned int*)(src + 0*stride)),
> "=m" (*(unsigned int*)(src + 1*stride)),
> "=m" (*(unsigned int*)(src + 2*stride)),
> "=m" (*(unsigned int*)(src + 3*stride)),
> "=m" (*(unsigned int*)(src + 4*stride)),
> "=m" (*(unsigned int*)(src + 5*stride)),
> "=m" (*(unsigned int*)(src + 6*stride)),
> "=m" (*(unsigned int*)(src + 7*stride))
> );
(In reply to comment #26)
> it might also happen that in some intentionally overconstrained cases it ends
> up
> searching the whole 5040 possible assignments of 7 registers onto 7 non memory
> operands but still it wont fail
The example Martin gave has *8* operands. You can try every possible direct
mapping of those 8 addresses to just 7 registers, but they will obviously all
fail. Except with ia32 addressing modes it _can_ be done, and with only 4
registers.
reg1 = src, reg2 = stride, reg3 = src+stride*3, reg4 = src+stride*6
Then the 8 memory operands are:
(reg1), (reg1,reg2,1), (reg1,reg2,2), (reg3),
(reg1,reg2,4), (reg3,reg2,2), (reg4), (reg3,reg2,4)
When one considers all the addressing modes, there are not just 7 possible
registers, but (I think) 261 possible addresses. There are not just 5040
possibilities as Michael said, but over 76 x 10^15 possible ways of assigning
these addresses to 7 operands! Then each register can be loaded not just with
an address but with some sub-expression too, like how I loaded reg2 with
stride.
Even for ia32, which makes up for its limited number of registers with complex
addressing modes, finding a register allocation that satisfies an asm statement
is not something that can always be done in reasonable time. If the number of
operands <= number of available registers it should be able to (but gcc
doesn't) always find an allocation (_an_ allocation, not the best allocation).
--
xyzzy at speakeasy dot org changed:
What|Removed |Added
CC||xyzzy at speakeasy dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug fortran/28849] Missed array shape violation with RESHAPE despite -fbounds-check
--- Comment #4 from burnus at gcc dot gnu dot org 2006-11-08 19:44 --- See also PR 29572 (matmul(a,b) and matmul(a,transpose(b))). sunf95 and NAG f95 catch this PR and also PR29572 and also pack(). g95 catches this PR and matmul(a,b), but not matmul(a,transpose(b))). ifort 9.1 (and 10.0) don't implement these kinds of checks. For pack, see: http://gcc.gnu.org/ml/fortran/2006-11/msg00243.html I think there are two possible solutions: Specific checks for known functions (reshape, matmul etc.), which is seemingly what g95 does. Or a solution for general functions, which seems to be what NAG f95/sunf95 do. For the latter, a test case is (imagine also pointer, allocatable, in different modules etc.): program check implicit none real, dimension(2) :: r r = foo(5) contains function foo(n) integer :: n real, dimension(n) :: foo foo = 42.0 end function foo end program check -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
[Bug fortran/29572] Bounds check should check size of array: d(1:1,1:1) = a(1:4,1:4)
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-08 19:35 --- Actually, if I remove the transpose, the run-time error message is: a.out: /home/tob/projects/gcc/libgfortran/generated/matmul_c4.c:172: matmul_c4: Assertion `count == b->dim[0].ubound + 1 - b->dim[0].lbound' failed. See also PR 28849 (for reshape). Depending on the planned solution, this is a quite general problem: array = function() where function is not only a library function, but could also be a user-defined function. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-08 19:35:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29572
[Bug c++/29757] Non-ISO template qualifiers
--- Comment #4 from fang at csl dot cornell dot edu 2006-11-08 19:32 --- If you want to reject "extern templates" (and enforce more standard-conformance in general), add "-ansi -pedantic-errors" to your CXXFLAGS. -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29757
[Bug other/29768] Implement -Werror for each kind of warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-08 19:30 --- Already implemented in 4.2.0 and above: -Werror= Make the specified warning into an errors. The specifier for a warning is appended, for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings, for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect. You can use the -fdiagnostics-show-option option to have each controllable warning amended with the option which controls it, to determine what to use with this option. Note that specifying -Werror=foo automatically implies -Wfoo. However, -Wno-error=foo does not imply anything. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29768
[Bug c++/29769] Problem building 4.1.1 on Solaris 2.8
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-08 19:29 --- You forgot to use --with-gnu-ld. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29769
[Bug c++/29767] [accept invalid?] specialization enclosed templates within the declaration of the enclosed class.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-08 19:28 --- as far as I can tell, GCC is incorrect in not using the specialized template. In fact I replace A with int, it gives the correct output. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29767
[Bug c++/29767] [accept invalid?] specialization enclosed templates within the declaration of the enclosed class.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-08 19:25 --- This is valid code ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29767
[Bug c++/29769] New: Problem building 4.1.1 on Solaris 2.8
Trying to build compiler collection 4.1.1 on solaris 2.8. Have up to date
binutils, texinfo and make. Perform the following:
./configure --prefix=/oh/appl/lib/gcc --exec-prefix=/oh/appl/lib/gcc
Then
/oh/appl/lib/make/bin/make
The build eventually fails with the following:
/oh/appl/lib/gcc/gcc-4.1.1/host-sparc-sun-solaris2.8/gcc/xgcc
-B/oh/appl/lib/gcc/gcc-4.1.1/host-sparc-sun-solaris2.8/gcc/
-B/oh/appl/lib/gcc/sparc-sun-solaris2.8/bin/
-B/oh/appl/lib/gcc/sparc-sun-solaris2.8/lib/ -isystem
/oh/appl/lib/gcc/sparc-sun-solaris2.8/include -isystem
/oh/appl/lib/gcc/sparc-sun-solaris2.8/sys-include -O2 -O2 -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs
-Wl,-h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs -Wl,-M,libgcc/./libgcc.map -o
./libgcc_s.so.1.tmp libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o
libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o
libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_floatdidf_s.o
libgcc/./_floatdisf_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunssfsi_s.o
libgcc/./_fixunsdfdi_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunssfdi_s.o
libgcc/./_fixsfdi_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o
libgcc/./_floatdixf_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixtfdi_s.o
libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_clear_cache_s.o
libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o
libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o
libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o
libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o
libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o
libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o
libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o
libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o
libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o
libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o
libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o
libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o
libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_divdi3_s.o
libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o
libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o
libgcc/./unwind-dw2-fde_s.o libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o
libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ];
then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv
./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
/oh/appl/lib/binutils/bin/ld:libgcc/./libgcc.map: file format not recognized;
treating as linker script
/oh/appl/lib/binutils/bin/ld:libgcc/./libgcc.map:1: syntax error
collect2: ld returned 1 exit status
content of libgcc.map is:
smpd333>cat ./host-sparc-sun-solaris2.8/gcc/libgcc/libgcc.map
GCC_3.0 {
global:
_Unwind_ForcedUnwind;
__muldi3;
__ashrdi3;
__negvsi2;
__subvdi3;
__addvdi3;
__clear_cache;
__subvsi3;
__addvsi3;
__register_frame_info_table_bases;
__ucmpdi2;
_Unwind_GetGR;
__fixunsdfdi;
__ashldi3;
__udivdi3;
__deregister_frame_info;
__negdi2;
__deregister_frame_info_bases;
__ffsdi2;
__floatdidf;
__register_frame_info;
__fixdfdi;
__cmpdi2;
__register_frame_table;
_Unwind_RaiseException;
__divdi3;
__lshrdi3;
_Unwind_SetGR;
__umoddi3;
_Unwind_Resume;
__fixunstfdi;
_Unwind_GetIP;
__fixunsdfsi;
__fixunssfdi;
__absvdi2;
__mulvdi3;
__fixtfdi;
__floatdisf;
__absvsi2;
__mulvsi3;
__moddi3;
__fixsfdi;
__register_frame_info_bases;
_Unwind_GetDataRelBase;
_Unwind_GetRegionStart;
__deregister_frame;
_Unwind_SetIP;
_Unwind_GetLanguageSpecificData;
__floatditf;
_Unwind_DeleteException;
__register_frame;
__udivmoddi4;
__fixunssfsi;
_Unwind_Find_FDE;
__negvdi2;
__register_frame_info_table;
_Unwind_GetTextRelBase;
local:
*;
};
GCC_3.3 {
global:
_Unwind_GetCFA;
_Unwind_Resume_or_Rethrow;
_Unwind_Backtrace;
_Unwind_FindEnclosingFunction;
} GCC_3.0;
GCC_3.3.1 {
global:
__gcc_personality_v0;
} GCC_3.3;
GCC_3.4 {
global:
__ctzdi2;
__ctzsi2;
__clzdi2;
__paritydi2;
__clzsi2;
__paritysi2;
__popcountdi2;
__popcountsi2;
} GCC_3.3.1;
GCC_3.4.2 {
global:
__enable_execute_stack;
} GCC_3.4;
GCC_4.0.0 {
global:
__muldc3;
[Bug fortran/29752] [4.2/4.3 Regression] write(*,*,advance='NO'), READ(): Data not flushed
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-08 19:20 ---
CC: to [EMAIL PROTECTED], who is our libgfortran/io/ specialist.
Confirm bug.
I think the change is in transfer.c's finalize_transfer():
Change between 4.1 and 4.2/4.3 (incomplete diff, I might messed it up):
- if (dtp->u.p.advance_status == ADVANCE_NO || dtp->u.p.seen_dollar)
- {
- /* Most systems buffer lines, so force the partial record
-to be written out. */
- if (!is_internal_unit (dtp))
- flush (dtp->u.p.current_unit->s);
- dtp->u.p.seen_dollar = 0;
- return;
- }
+
+ if (dtp->u.p.advance_status == ADVANCE_NO)
+return;
+
Here, a flush could be added, but I think having a flush before a read makes
more sense (cf. commercial compilers). (Do it in any read()? How expensive is a
flush of file where nothing is to be flushed?)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-11-08 19:20:11
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29752
[Bug other/29768] New: Implement -Werror for each kind of warning
"info:/gcc/Warning Options" mentions -Werror, that treats all warnings as errors and -Werror-implicit-function-declaration, which treats implicit function declarations as errors but it does not mention how to treat other certain kinds of warnings as errors. For example -Werror-shadow does not work. This is because the feature is not generally implemented (only implemented specifically for implicit-function-declaration). -- Summary: Implement -Werror for each kind of warning Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sigra at home dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29768
[Bug c++/29767] [accept invalid?] specialization enclosed templates within the declaration of the enclosed class.
--- Comment #1 from pluto at agmk dot net 2006-11-08 18:56 --- Created an attachment (id=12569) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12569&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29767
[Bug c++/29767] New: [accept invalid?] specialization enclosed templates within the declaration of the enclosed class.
gcc and msvc accept such code but produces different results. is this code (in)valid? i'm not sure what behaviour is correct. -- Summary: [accept invalid?] specialization enclosed templates within the declaration of the enclosed class. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29767
[Bug middle-end/28752] bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc
--- Comment #16 from law at redhat dot com 2006-11-08 18:29 --- Subject: Re: bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc On Wed, 2006-11-08 at 11:33 +, irar at il dot ibm dot com wrote: > > --- Comment #14 from irar at il dot ibm dot com 2006-11-08 11:33 --- > (In reply to comment #11) > > 1. Put a breakpoint in tree_ssa_cd_dce when compiling the > > offending function from recog.c.When that breakpoint > > triggers issue: > > verify_ssa (true) > > I can't see any way for that to fail, but better safe than > > sorry. > > It fails... [ ... ] > (gdb) p debug_generic_stmt (0xf74510f0) > # VUSE ; > # VUSE ; > opD.24623_172 = recog_dataD.15550.operandD.15539[opnoD.24621_29]; > Ah. I had discounted this scenario as I thought this class of problems had been fixed. We've got an operand inside a VUSE which was never placed into SSA form. This typically occurs when a pass mucks around with aliasing information. The vectorizer has been problematical in this respect. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26197 I think there are links inside that PR which point to other instances of this underlying problem. Anyway, what typically happens is the aliasing information gets mucked up by an early pass, but the affected statements aren't marked as modified and thus the mucked up aliasing information isn't exposed until some later pass (typically SSA updates due to jump threading) marks the statement as modified and rebuilds the operand cache, exposing the non-SSA operand. The pass following jump threading typically core dumps or triggers an assert like we're seeing in DCE. Because of the hidden nature of this problem it can be difficult to determine which pass mucked up the aliasing information. I think the easiest way to at least find out what pass is mucking things up is to insert some code like this at the start of verify_ssa FOR_EACH_BB (bb) for (bsi = bsi_start (bb); ! bsi_end_p (bsi); bsi_next (&bsi)) update_stmt (bsi_stmt (bsi)); In fact, one could argue that such code really belongs at the start of verify_ssa permanently. Hopefully you'll get a checking failure much earlier. At the least it'll allow you to look at the dump files for the first reference to SFT.1940D.29535 that is not in SSA form. If I had to venture a guess, my money would be on the vectorizer being the culprit here. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug fortran/29744] [Regression] Type renaming crashes gfortran with excessive memory usage
--- Comment #2 from patchapp at dberlin dot org 2006-11-08 17:55 --- Subject: Bug number PR29744 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00507.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29744
[Bug c++/29757] Non-ISO template qualifiers
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-08 17:29 --- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1448.pdf so again "extern template" might be added to the C++ standard so we don't want to remove that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29757
[Bug c++/29766] New: Template Specialization break down
$ g++ find.mytree.cpp
find.mytree.cpp:141:2: warning: no newline at end of file
find.mytree.cpp:123: internal compiler error: in output_constant, at
varasm.c:38
43
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr
--
exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--man
dir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,
java,objc --enable-nls --without-included-gettext
--enable-version-specific-runt
ime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib
--ena
ble-interpreter --disable-libgcj-debug --enable-threads=posix
--enable-java-gc=b
oehm --disable-win32-registry --enable-sjlj-exceptions
--enable-hash-synchroniza
tion --enable-libstdcxx-debug : (reconfigured)
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
find.mytree.cpp
#include
#include
#include
#include
#define OUTPUT(x) std::cout << x << std::endl;
template
class mytree {
public:
typedef mytree MYTREE;
typedef std::map ELEMENT;
typedef typename ELEMENT::iterator ELEITER;
#define GETTREE(x) (*(x->second))
#define VALUE(x) (make_pair(x->Name(), x))
typedef std::string NAME;
mytree(char *nm, C& vl, MYTREE *ch=0, MYTREE *brss=0, MYTREE* pr=0)
: name(nm), value(vl){ insert (ch, brss, pr); }
mytree(const char* nm, const C& vl, MYTREE *ch=0, MYTREE *brss=0,
MYTREE* pr=0)
: name(nm), value(vl){ insert (ch, brss, pr); }
MYTREE& operator/(const char* str)
{
return myfind(child, str);
}
MYTREE& operator|(const char* str)
{
return myfind(brosis, str);
}
MYTREE& operator^(const char* str)
{
return myfind(parents, str);
}
const C& Value() {
return value;
}
const NAME &Name() {
return name;
}
operator C () {
return value;
}
/*
noloop: to avoid infinite loop. consider A add B as brother and at
mean time B add A as brother.
then A add B as brother... that will be infinite loop.
solution: (a) we can find each time to see if B is already
A's brother
(b) add the noloop, when it should be finished,
just set noloop to 0.
*/
MYTREE& insert(MYTREE *ch, MYTREE *brss, MYTREE* pr, bool noloop=1)
{ counter++;
if(ch){all.insert(VALUE(ch)); child.insert(VALUE(ch));
if(noloop)ch->insert(0, 0, this, 0);}
if(brss){all.insert(VALUE(brss));brosis.insert(VALUE(brss));
if(noloop)brss->insert(0, this, 0, 0);}
if(pr){all.insert(VALUE(pr));parents.insert(VALUE(pr));
if(noloop)pr->insert(this, 0, 0, 0);}
return *this;
}
void dump(MYTREE *caller=0, std::string lv="") {
typename ELEMENT::iterator it;
MYTREE *tr = this;
//dump all brosis
it = this->brosis.begin();
while(it != this->brosis.end()) {
tr = &GETTREE(it);
assert(tr);
if(tr != caller && tr != this) {
tr->dump(this, lv);
//OUTPUT(lv << "|" << tr->Name() << ": " <<
tr->Value() );
}
++it;
}
OUTPUT(lv<< " " << this->Name() << ": " << this->Value() );
//dump all child
it = this->child.begin();
while(it != this->child.end()) {
tr = &GETTREE(it);
assert(tr);
if(tr != caller && tr != this) {
//OUTPUT(lv << "\t\\" << tr->Name() << ": " <<
tr->Value() );
tr->dump(tr, lv+"\t");
}
++it;
}
}
static void dumpall() {
ELEITER it = all.begin();
while(it!= all.end()) {
OUTPUT(it->first <<" " << it->second );
++it;
}
}
/*static ELEMENT& getall() { return all;}*/
private:
MYTREE& myfind(ELEMENT& el, const char* str)
{
typename ELEMENT::iterator it = el.find(NAME(str));
if ( it != el.end() )
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-08 17:26 --- Use "make -k check" as documented. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug testsuite/29761] 'make check' for gcc-4.1.1 fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-08 17:26 --- Use make -k check as documented. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29761
[Bug c++/29763] Non-ISO template qualifiers
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-08 17:23 --- *** This bug has been marked as a duplicate of 29757 *** -- 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=29763
[Bug c++/29757] Non-ISO template qualifiers
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-08 17:23 --- *** Bug 29763 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29757
[Bug c++/29765] -Wparentheses does not warn on single equals sign inside if statement
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-08 17:22 --- Fixed in at least 4.0.4 and above. 3.4.x is no longer maintained. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29765
[Bug fortran/29744] [Regression] Type renaming crashes gfortran with excessive memory usage
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-08 17:02 --- Harald, Many thanks for bringing this up - I only just noticed it today; maybe next time anything involving derived type association comes up, could you CC me on the PR? For once, I do not feel embarrassed by this type of PR: on Cygwin_NT, which I used to develop the August round of patches, the compilation does not crash; it just stops. Since no errors are produced, the testsuite seems to proceed its own merry little way and ignore the fact that there has been a failure! The reason that the testsuite does not pick it up is that the test of the fix for PR19362 was moved to a subroutine, so that other aspects of association could be tested. This error only afflicts namespaces without a parent; eg. the main programme. I have a patch regtesting right now but I am confident that it will be OK and will submit it right away. Best regards Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-08 17:02:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29744
[Bug tree-optimization/29581] Latent bug in 4.1/4.2/4.3 lambda-code.c
--- Comment #1 from dberlin at gcc dot gnu dot org 2006-11-08 16:24 --- (In reply to comment #0) > In the testcase I posted, USE's initial_condition_in_loop_num is > -5 and X's initial_condition_in_loop_num is 1. And, adding -5 - 1 > to perfectiv (aka Y in the above routine) is exactly what would > cure this testcase. > > Do you agree with this? > I agree completely with your analysis. If you want to work up a fix to do that, i'm happy to approve it (It should suffice to generate the initial condition in the loop header and use that as the starting point for the new iv variable). > Not sure how hard is that though, other alternative would be to make > can_convert_to_perfect_nest more conservative. > -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-08 16:24:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29581
[Bug c++/29765] New: -Wparentheses does not warn on single equals sign inside if statement
When compiling the following code with -Wparentheses, no warning is shown: cat
[Bug c/29764] casting as off64_t gives wrong address for mmaped file using sendfilev64 on solaris
--- Comment #1 from schwab at suse dot de 2006-11-08 14:29 --- Conversions from pointer types to integer types are implementation defined. GCC sign extends when converting a pointer to a wider integer. See
[Bug c/29764] New: casting as off64_t gives wrong address for mmaped file using sendfilev64 on solaris
phantom# /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
This is a follow up to apache bug 34963
http://issues.apache.org/bugzilla/show_bug.cgi?id=39463
It seems to be present on at least Solaris 9 and 10.
I'm not really sure how to describe this but the below text from a Sun Engineer
with sample code explains / demonstrates the problem.
Source code from Sun engineer to demonstrate problem.
Cut here
#include
#include
#include
#include
#include
#include
#include
#include
int main (void)
{
sendfilevec64_t sfv[3];
int mmapfd;
void *addr;
/* Open a file to mmap */
if ((mmapfd = open ("/lib/libc.so", O_RDONLY)) == -1)
{
perror ("open of /lib/libc.so failed");
exit (1);
}
/* mmap file */
if ((addr = mmap (NULL, 8192, PROT_READ, MAP_SHARED, mmapfd, 0)) ==
MAP_FAILED)
{
perror ("mmap failed");
exit (1);
}
close (mmapfd);
fprintf (stdout, "mmap() done. addr = %p\n", addr);
sfv[0].sfv_off = (off64_t)addr;
sfv[1].sfv_off = (long)addr;
sfv[2].sfv_off = (unsigned long)addr;
fprintf (stdout, "Value of sfv_off[0] = %llu\n", sfv[0].sfv_off);
fprintf (stdout, "Value of sfv_off[1] = %llu\n", sfv[1].sfv_off);
fprintf (stdout, "Value of sfv_off[2] = %llu\n", sfv[2].sfv_off);
exit (0);
}
Cut here
As you can see, it mmap's a file, then takes the same value and casts it as an
off64_t (which it should be according to the definition of the struct
sendfilevec64_t), and also as a "long" (which I believe the Apache apr_off_t
type reduces to), then finally as an unsigned long.
This was compiled with Sun's cc compiler (from Studio 10 or 11 I think). The
output was this:
$ cc -D_LARGEFILE64_SOURCE -o test test.c
$ ./test
mmap() done. addr = ff39
Value of sfv_off[0] = 4281925632
Value of sfv_off[1] = 18446744073696509952
Value of sfv_off[2] = 4281925632
The correct value is given when cast either as the off64_t or as an unsigned
value. When compiled and run using gcc (I happen to have version 3.4.3), the
results are:
$ gcc -Wall -D_LARGEFILE64_SOURCE -o test test.c
test.c: In function `main':
test.c:32: warning: cast from pointer to integer of different size
$ ./test
mmap() done. addr = ff39
Value of sfv_off[0] = 18446744073696509952
Value of sfv_off[1] = 18446744073696509952
Value of sfv_off[2] = 4281925632
Here, the correct value is returned if an unsigned long is specified. I think
there are two issues here:
1) If the correct type "off64_t" is used, gcc produces incorrect
results. This would have to be investigated and taken up with the GCC team.
2) The data type "apr_off_t" is defined as a long, where it could (or
should?) be defined as unsigned long.
The obvious way forward to prevent any compiler dependencies would be to change
the apr_off_t data type, but this is Apache's call.
Please note that the above program is provided as is, and is only designed to
demonstrate a particular point. It is a bit crude really, but I hope it serves
its purpose!
--
Summary: casting as off64_t gives wrong address for mmaped file
using sendfilev64 on solaris
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dbb at st-andrews dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29764
[Bug c++/29763] New: Non-ISO template qualifiers
Don't suppose you can deprecate this non-ISO C++ standard usage of the following proprietary G++ extensions: extern template int max (int, int); inline template class Foo; static template class Foo; ... as summarised at http://www.dis.com/gnu/gcc/Template-Instantiation.html. The problem with these is that they tempt some programmers to use them (a) without really understanding what they are doing as documentation is somewhat light on these extensions (b) in the mistaken belief it is standard C++, not a proprietary G++ extension (c) that non-G++ compilers ignore it, which they may or may not do in a predictable fashion. As an example, various versions of MSVC as well as other compilers can throw some odd errors. I have no problem with these being replaced with something like say: __attribute__((template_extern)) template int max (int, int); __attribute__((template_inline)) template class Foo; __attribute__((template_static)) template class Foo; This then does not give the illusion that these misuses of extern, inline and static with template declarations is proper C++. Cheers, Niall -- Summary: Non-ISO template qualifiers Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: s_gccbugzilla at nedprod dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29763
[Bug ada/29762] New: invalid index constraint causes GNAT to crash
I wanted to compile an Ada package I am writing as a student at the University of Stuttgart, Germany. The following happened: $ gnatmake -gnaty3acefhiklmnrpt permutations.adb gcc -c -gnaty3acefhiklmnrpt permutations.adb +===GNAT BUG DETECTED==+ | 3.3 20040913 (GNAT for Mac OS X build 1650) (powerpc-unknown-darwin) | | Assert_Failure sinfo.adb:1593| | Error detected at permutations.adb:68:7 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | concatenated together with no headers between files. | +==+ Please include these source files with error report permutations.adb permutations.ads list may be incomplete permutations.adb:80:23: (style) space required compilation abandoned gnatmake: "permutations.adb" compilation error The source files: permutations.adb: -- FILE:permutations.adb -- -- PROJECT: Programmieruebungen, Uebungsblatt 02 -- VERSION: 1.0 -- DATE:08 Nov 2006 -- AUTHOR: Fritjof A. Mayer -- -- -- -- PACKAGE BODY Permutations -- package body Permutations is -- FUNCTION Next_Perm -- -- Originally written on 10 Nov 2005 -- Blatt 2, Aufgabe 3, Programmierkurs I, WS05/06 -- by Fritjof A. Mayer -- -- Generates next permutation. -- Algorithm taken from "Einfuehrung in die Informatik I WS05/06" function Next_Perm (Perm : Permutation) return Permutation is Next_P : Permutation (Perm'Range) := Perm; I, J, K, Smallest, Trans : Natural; N : constant Natural := Perm'Last; begin -- search backwards for P (I) < P (I + 1) -- starting at I = N - 1 I := N - 1; while I >= 1 and Perm (I) > Perm (I + 1) loop I := I - 1; end loop; -- search forwards for smallest Z > P (I), Z = P (J) -- starting at J = I + 1 Smallest := I + 1; for J in (I + 1) .. N loop if Perm (J) < Perm (Smallest) and Perm (J) > Perm (I) then Smallest := J; end if; end loop; J := Smallest; -- swap P (I) and P (J) in next permutation Next_P (I) := Perm (J); Next_P (J) := Perm (I); -- sort elements P (I + 1) .. P (N) -- by inverting their sequence K := 0; while (I + 1) + K < N - K loop Trans := Next_P ((I + 1) + K); Next_P ((I + 1) + K) := Next_P (N - K); Next_P (N - K) := Trans; K := K + 1; end loop; return Next_P; end Next_Perm; -- FUNCTION Word_Perm -- -- Generates all permutations of a word, first and last -- character are not permuted -- -- Example: ... -- function Word_Perm (Word : String) return P_Words is All_Perms : P_Words (1 .. (Word'Length - 2)**2, Word'Length); Perm : Permutation (1 .. Word'Length - 2); begin for I in Perm'Range loop Perm (I) := I; end loop; for I in All_Perms'Range loop All_Perms (I, 1) := Word (Word'First); for J in Perm'Range loop All_Perms (I, J) := Word (Perm (J)); end loop; All_Perms (I,Word'Length) := Word (Word'Last); Perm := Next_Perm (Perm); end loop; return All_Perms; end Word_Perm; end Permutations; permutations.ads: package Permutations is type Permutation is array (Positive range <>) of Positive; type P_Words is array (Positive range <>, Positive range <>) of Character; function Next_Perm (Perm : Permutation) return Permutation; end Permutations; I think the problem is here: ... function Word_Perm (Word : String) return P_Words is All_Perms : P_Words (1 .. (Word'Length - 2)**2, Word'Length); Perm : Permutation (1 .. Word'Length - 2); begin ... P_Words needs index constraints, those are ranges. 1 .. (Word'Length - 2)**2 is a range Word'Length is just a number and no range. Normally i should receive an error message: invalid index constraint When I change this to All_Perms : P_Words (1 .. (Word'Length - 2)**2, 1 .. Word'Length); it compiles without errors. -- Summary: invalid index constraint causes GNAT to crash Product: gcc Version: 3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot g
[Bug testsuite/29761] New: 'make check' for gcc-4.1.1 fails
This bug is similar to http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=WAITING&bug_status=ASSIGNED&bug_status=UNCONFIRMED&bug_status=REOPENED&email1=sergstesh%40yahoo.com&emailtype1=exact&emailassigned_to1=1&emailreporter1=1 , just the failure is different - here's how 'make check' screen output looks: " make[1]: Entering directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1' make[2]: Entering directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fastjar' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fastjar' make[2]: Entering directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fixincludes' autogen -T /maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1.src/fixincludes/check.tpl /maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1.src/fixincludes/inclhack.def /bin/sh ./check.sh /maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1.src/fixincludes/tests/base Fixed: testing.h Fixed: testing.h Fixed: ansi/math.h Fixed: ansi/stdlib.h Fixed: arch/i960/archI960.h Fixed: arpa/inet.h Fixed: assert.h Fixed: AvailabilityMacros.h Fixed: bits/huge_val.h Fixed: bsd/libc.h Fixed: c_asm.h Fixed: com_err.h Fixed: ctrl-quotes-def-1.h Fixed: ctype.h Fixed: curses.h Fixed: fixinc-test-limits.h Fixed: fs/rfs/rf_cache.h Fixed: _G_config.h Fixed: hsfs/hsfs_spec.h Fixed: ia64/sys/getppdp.h Fixed: internal/math_core.h Fixed: internal/sgimacros.h Fixed: internal/wchar_core.h Fixed: inttypes.h Fixed: io-quotes-def-1.h Fixed: iso/math_c99.h Fixed: locale.h Fixed: machine/cpu.h Fixed: mach-o/dyld.h Fixed: malloc.h Fixed: math.h Fixed: netdnet/dnetdb.h Fixed: netinet/in.h Fixed: netinet/ip.h Fixed: obstack.h Fixed: pixrect/memvar.h Fixed: pthread.h Fixed: regex.h Fixed: regexp.h Fixed: reg_types.h Fixed: rpc/auth.h Fixed: rpc/rpc.h Fixed: rpc/svc.h Fixed: rpcsvc/rstat.h Fixed: rpcsvc/rusers.h Fixed: rpc/xdr.h Fixed: sparc/asm_linkage.h Fixed: standards.h Fixed: stdio.h Fixed: stdio_tag.h Fixed: stdlib.h Fixed: string.h Fixed: strings.h Fixed: sundev/vuid_event.h Fixed: sunwindow/win_lock.h Fixed: sym.h Fixed: sys/asm.h Fixed: sys/cdefs.h Fixed: sys/file.h Fixed: sys/ioctl.h Fixed: sys/limits.h Fixed: sys/machine.h Fixed: sys/mman.h Fixed: sys/regset.h Fixed: sys/signal.h Fixed: sys/socket.h Fixed: sys/spinlock.h Fixed: sys/stat.h Fixed: sys/time.h Fixed: sys/times.h Fixed: sys/types.h Fixed: sys/ucontext.h Fixed: sys/utsname.h Fixed: sys/wait.h Fixed: testing.h Fixed: time.h Fixed: tinfo.h Fixed: types/vxTypesBase.h Fixed: unistd.h Fixed: wchar.h Fixed: widec.h Fixed: X11/ShellP.h Fixed: X11/Xmu.h Fixed: Xm/BaseClassI.h Fixed: Xm/Traversal.h Newly fixed header: ia64/sys/getppdp.h There were fixinclude test FAILURES make[2]: *** [check] Error 1 make[2]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fixincludes' make[1]: *** [check-fixincludes] Error 2 make[1]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1' make: *** [do-check] Error 2 ". 'autogen-2.60' was used. It appears that, unlike in http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=WAITING&bug_status=ASSIGNED&bug_status=UNCONFIRMED&bug_status=REOPENED&email1=sergstesh%40yahoo.com&emailtype1=exact&emailassigned_to1=1&emailreporter1=1 no test is run, 'make check' aborts due to some problem during fixing headers. Please let me know whther you need any additional info. -- Summary: 'make check' for gcc-4.1.1 fails Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB GCC host triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB GCC target triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29761
[Bug testsuite/29760] New: 'make check' for gcc-3.4.6 fails
I am building gcc-3.4.6 in the framework of my
http://appsfromscratch.berlios.de/
project, and 'make check' for gcc-3.4.6 fails.
Basically, my tool builds and installs every lib/app (per source tarball) in
a separate directory, other than that it uses the standard
./configure
make
make check
make install
scheme.
If necessary, I can upload the tool, it's self-contained, downloads sources
from the web; to build gcc-3.4.6 one would have to enter a command line
like this:
~/AppsFromScratch/20061104/bin/build.pl -targets_to_build gcc3 -make_like
1>build.log 2>&1 &
.
OK, here is screen output of the failing 'make check':
"
make[1]: Entering directory
`/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6/gcc'
Making a new config file...
echo "set tmpdir
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6/gcc/testsuite" >> ./tmp0
test -d testsuite || mkdir testsuite
rm -f testsuite/site.exp
sed '/set tmpdir/ s|testsuite|testsuite|' < site.exp > testsuite/site.exp
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc;
${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite; \
EXPECT=expect ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/../tcl/library ;
${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; fi ; \
runtest --tool gcc )
WARNING: Couldn't find the global config file.
Test Run By sergei on Wed Nov 8 01:18:30 2006
Native configuration is i686-pc-linux-gnu
=== gcc tests ===
Schedule of variations:
unix
Running target unix
Using
/maxtor5/sergei/AppsFromScratchWD/install/dejagnu-1.4.4/share/dejagnu/baseboards/unix.exp
as board description file for target.
Using
/maxtor5/sergei/AppsFromScratchWD/install/dejagnu-1.4.4/share/dejagnu/config/unix.exp
as generic interface file for target.
Using
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.c-torture/compile/compile.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.c-torture/execute/execute.exp
...
FAIL: gcc.c-torture/execute/va-arg-25.c execution, -Os
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.c-torture/unsorted/unsorted.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/compat/compat.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/cpp/cpp.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/cpp/trad/trad.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/debug/debug.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf2.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/dg.exp
...
FAIL: gcc.dg/cleanup-8.c execution test
FAIL: gcc.dg/cleanup-9.c execution test
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/format/format.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/noncompile/noncompile.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/pch/pch.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/special/mips-abi.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/special/special.exp
...
FAIL: gcc.dg/special/gcsec-1.c (test for excess errors)
WARNING: gcc.dg/special/gcsec-1.c compilation failed to produce executable
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/tls/tls.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/torture/dg-torture.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.dg/weak/weak.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.misc-tests/acker1.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.misc-tests/arm-isr.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.misc-tests/bprob.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.misc-tests/dhry.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.misc-tests/gcov.exp
...
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/gcc/testsuite/gcc.misc-tests/i386-prefetch.exp
...
Running
/maxtor5/sergei/AppsFro
[Bug middle-end/28752] bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc
--- Comment #15 from irar at il dot ibm dot com 2006-11-08 12:05 --- Additional behavior: If I run bootstrap with BOOT_CFLAGS="-O2 -g -ftree-vectorize -maltivec" (without -fdump-tree-vect-details), bootstrap fails with ../../gcc/gcc/recog.c: In function constrain_operands: ../../gcc/gcc/recog.c:2270: internal compiler error: in mark_operand_necessary, at tree-ssa-dce.c:266 Then I compile recog.c alone with /Develop/main-110758/build-vect/./prev-gcc/xgcc -B/Develop/main-110758/build-vect/./prev-gcc/ -B/Develop/main-110758//powerpc64-suse-linux/bin/ -c -O2 -g -ftree-vectorize -maltivec -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber../../gcc/gcc/recog.c and again I get ../../gcc/gcc/recog.c: In function constrain_operands: ../../gcc/gcc/recog.c:2270: internal compiler error: in mark_operand_necessary, at tree-ssa-dce.c:266 With -quiet I get a different error: Program received signal SIGSEGV, Segmentation fault. 0x100b1dc4 in is_gimple_min_invariant (t=0x18) at ../../gcc/gcc/tree-gimple.c:172 172 switch (TREE_CODE (t)) (gdb) backtrace #0 0x100b1dc4 in is_gimple_min_invariant (t=0x18) at ../../gcc/gcc/tree-gimple.c:172 During symbol reading, incomplete CFI data; unspecified registers (e.g., r0) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r2) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r3) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r4) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r5) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r6) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r7) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r8) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r9) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r10) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r11) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r12) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r13) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r14) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r15) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r16) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r17) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r18) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r19) at 0x100b1dbc. During symbol reading, incomplete CFI data; unspecified registers (e.g., r20) at 0x100b1dbc. #1 0x1013f110 in replace_vuses_in (stmt=0xf74510f0, replaced_addresses_p=0xff8a9790 "", prop_value=0x10b6b238) at ../../gcc/gcc/tree-ssa-propagate.c:958 #2 0x1013f8d4 in substitute_and_fold (prop_value=0x10b6b238, use_ranges_p=0 '\0') at ../../gcc/gcc/tree-ssa-propagate.c:1139 #3 0x100dd070 in fini_copy_prop () at ../../gcc/gcc/tree-ssa-copy.c:914 #4 0x100dd158 in execute_copy_prop (store_copy_prop=0 '\0', phis_only=1 '\001') at ../../gcc/gcc/tree-ssa-copy.c:1035 #5 0x100dd204 in do_phi_only_copy_prop () at ../../gcc/gcc/tree-ssa-copy.c:1076 #6 0x1051b090 in execute_one_pass (pass=0x10915e68) at ../../gcc/gcc/passes.c:853 #7 0x1051b248 in execute_pass_list (pass=0x10915e68) at ../../gcc/gcc/passes.c:897 #8 0x1051b274 in execute_pass_list (pass=0x108875bc) at ../../gcc/gcc/passes.c:898 #9 0x100b1684 in tree_rest_of_compilation (fndecl=0xf7862d00) at ../../gcc/gcc/tree-optimize.c:412 #10 0x10016914 in c_expand_body (fndecl=0xf7862d00) at ../../gcc/gcc/c-decl.c:6689 #11 0x1059b894 in cgraph_expand_function (node=0xf75b3e00) at ../../gcc/gcc/cgraphunit.c:1101 #12 0x1059bb24 in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1166 #13 0x1059c718 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1434 #14 0x1001a024 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7804 #15 0x104d9928 in compile_file () at ../../gcc/gcc/toplev.c:1012 #16 0x104dbbe4 in do_compile () at ../../gcc/gcc/toplev.c:1957 #17 0x104dbc78 in toplev_main (argc=53, argv=0xff8a9ca4) at ../../gcc/gcc/toplev.c:1989 #18 0x10090518 in main (argc=53, argv=0xff8a9ca4) at ../../gcc/gcc/main.c:35 Moreover, if I add -fdump-tree-ve
[Bug libstdc++/29722] Linking with libsupc++.a creates link time undefined references
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-11-08 11:58 --- Fixed. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29722
[Bug libstdc++/29722] Linking with libsupc++.a creates link time undefined references
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-11-08 11:58 --- Fixed in mainline/gcc-4_2-branch. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29722
[Bug libstdc++/29722] Linking with libsupc++.a creates link time undefined references
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-11-08 11:58 --- Subject: Bug 29722 Author: bkoz Date: Wed Nov 8 11:57:52 2006 New Revision: 118581 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118581 Log: 2006-11-07 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/29722 * include/ext/concurrence.h (concurrence_lock_error): New. (concurrence_unlock_error): New. (__throw_concurrence_lock_error): New. (__throw_concurrence_unlock_error): New. (__mutex): Use functions. (__recursive_mutex): Same. * testsuite/abi/cxx_runtime_only_linkage.cc: New. * include/ext/pb_ds/exception.hpp: Keep exception classes defined even when -fno-exceptions is passed, consistent with other usage. 2006-11-07 Benjamin Kosnik <[EMAIL PROTECTED]> * include/ext/pb_ds/exception.hpp (pb_ds): Modify for -fno-exceptions. (__throw_container_error): New. Conditionalize based on __EXCEPTIONS. (__throw_insert_error): New. (__throw_join_error): New. (__throw_resize_error): New. * include/ext/pb_ds/detail/resize_policy/ hash_prime_size_policy_imp.hpp: Use them. * include/ext/pb_ds/detail/resize_policy/ hash_exponential_size_policy_imp.hpp: Same. * include/ext/pb_ds/detail/resize_policy/ hash_load_check_resize_trigger_imp.hpp: Same. * include/ext/pb_ds/detail/resize_policy/ hash_standard_resize_policy_imp.hpp: Same. * include/ext/pb_ds/detail/cc_hash_table_map_/resize_fn_imps.hpp * include/ext/pb_ds/detail/cc_hash_table_map_/ constructor_destructor_fn_imps.hpp: Same. * include/ext/pb_ds/detail/pat_trie_/insert_join_fn_imps.hpp * include/ext/pb_ds/detail/pat_trie_/split_join_branch_bag.hpp * include/ext/pb_ds/detail/pat_trie_/ constructors_destructor_fn_imps.hpp: Same. * include/ext/pb_ds/detail/bin_search_tree_/ constructors_destructor_fn_imps.hpp: Same. * include/ext/pb_ds/detail/bin_search_tree_/ split_join_fn_imps.hpp: Same. * include/ext/pb_ds/detail/gp_hash_table_map_/ insert_no_store_hash_fn_imps.hpp: Same. * include/ext/pb_ds/detail/gp_hash_table_map_/ resize_store_hash_fn_imps.hpp: Same. * include/ext/pb_ds/detail/gp_hash_table_map_/ insert_store_hash_fn_imps.hpp: Same. * include/ext/pb_ds/detail/gp_hash_table_map_/resize_fn_imps.hpp: Same. * include/ext/pb_ds/detail/gp_hash_table_map_/ constructor_destructor_fn_imps.hpp: Same. * include/ext/pb_ds/detail/gp_hash_table_map_/ resize_no_store_hash_fn_imps.hpp: Same. * include/ext/pb_ds/detail/binary_heap_/ constructors_destructor_fn_imps.hpp: Same. * include/ext/pb_ds/detail/binary_heap_/split_join_fn_imps.hpp: Same. * include/ext/pb_ds/detail/left_child_next_sibling_heap_/ constructors_destructor_fn_imps.hpp: Same. * include/ext/pb_ds/detail/ov_tree_map_/split_join_fn_imps.hpp: Same. * include/ext/pb_ds/detail/list_update_map_/ constructor_destructor_fn_imps.hpp: Same. * include/ext/pb_ds/exception.hpp: Same. * src/functexcept.cc: Qualify abort with std. 2006-11-07 Benjamin Kosnik <[EMAIL PROTECTED]> * include/ext/pb_ds/exception.hpp: Add translation support to exception strings. * include/ext/concurrence.h: Same. * include/tr1/array: Same. Added: branches/gcc-4_2-branch/libstdc++-v3/testsuite/abi/cxx_runtime_only_linkage.cc Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/ext/concurrence.h branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/split_join_fn_imps.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/constructors_destructor_fn_imps.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/split_join_fn_imps.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/constructor_destructor_fn_imps.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/resize_fn_imps.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/constructor_destructor_fn_imps.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/insert_no_store_hash_fn_imps.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/insert_store_hash_fn_imps.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/resize_fn_imps.hpp branches/gcc-4_2-branch/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/resize_no_store_hash_fn_imps.hpp branche
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #42 from ebotcazou at gcc dot gnu dot org 2006-11-08 11:41 --- > Hey Eric. Yes, it looks like I'm all ok (test results are perfect) as long > as HAVE_COMDAT_GROUP is defined, but screwed if it isn't. Although I'm ok > now, it does seem as if something may be wrong in one of the code paths, as > things should still work without comdat groups, no? Yes, I'm investigating. Ultimately I could always resort to conditionalizing my change on HAVE_COMDAT_GROUP, but that would be more of a kludge. > Thanks for your help! Thanks for your patience. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug fortran/29759] New: ice on line continuation in OMP statements (gfc_next_char_literal, at fortran/scanner.c:701)
$> cat ice.f90 PROGRAM test_omp !$OMP PARALLEL & !$NUM_THREADS(2) END PROGRAM $> gfortran-svn -g -Wall -fopenmp ice.f90 ice.f90:0: internal compiler error: in gfc_next_char_literal, at fortran/scanner.c:701 Please submit a full bug report, $> gfortran-svn -v gcc version 4.3.0 20061106 (experimental) -- Summary: ice on line continuation in OMP statements (gfc_next_char_literal, at fortran/scanner.c:701) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29759
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #41 from bkoz at gcc dot gnu dot org 2006-11-08 11:34 --- Hey Eric. Yes, it looks like I'm all ok (test results are perfect) as long as HAVE_COMDAT_GROUP is defined, but screwed if it isn't. Although I'm ok now, it does seem as if something may be wrong in one of the code paths, as things should still work without comdat groups, no? It looks like you are able to reproduce now, so that's good. Thanks for your help! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug middle-end/28752] bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc
--- Comment #14 from irar at il dot ibm dot com 2006-11-08 11:33 ---
(In reply to comment #11)
> 1. Put a breakpoint in tree_ssa_cd_dce when compiling the
> offending function from recog.c.When that breakpoint
> triggers issue:
> verify_ssa (true)
> I can't see any way for that to fail, but better safe than
> sorry.
It fails...
Breakpoint 6, tree_ssa_cd_dce () at ../../gcc/gcc/tree-ssa-dce.c:947
947 perform_tree_ssa_dce (/*aggressive=*/optimize >= 2);
(gdb) p verify_ssa (true)
No symbol "true" in current context.
(gdb) p verify_ssa (1)
During symbol reading, incomplete CFI data; unspecified registers (e.g., r0) at
0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r2) at
0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r3) at
0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r4) at
0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r5) at
0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r6) at
0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r7) at
0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r8) at
0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r9) at
0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r10)
at 0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r11)
at 0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r12)
at 0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r13)
at 0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r14)
at 0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r15)
at 0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r16)
at 0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r17)
at 0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r18)
at 0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r19)
at 0x105d412c.
During symbol reading, incomplete CFI data; unspecified registers (e.g., r20)
at 0x105d412c.
../../gcc/gcc/recog.c: In function constrain_operands:
../../gcc/gcc/recog.c:2270: error: expected an SSA_NAME object
Breakpoint 1, fancy_abort (file=0x10744d58 "../../gcc/gcc/tree-ssa-operands.c",
line=1905, function=0x10745428 "verify_imm_links")
at ../../gcc/gcc/diagnostic.c:642
642 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
The program being debugged stopped while in a function called from GDB.
When the function (verify_ssa) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
Backtrace:
#0 fancy_abort (file=0x10744d58 "../../gcc/gcc/tree-ssa-operands.c",
line=1905, function=0x10745428 "verify_imm_links")
at ../../gcc/gcc/diagnostic.c:642
#1 0x100e4c10 in verify_imm_links (f=0xffec4a8, var=0xf6d34e40) at
../../gcc/gcc/tree-ssa-operands.c:1905
#2 0x100ac1fc in verify_use (bb=0xf73144d0, def_bb=0x1, use_p=0xf6beb118,
stmt=0xf74510f0, check_abnormal=0 '\0', is_virtual=1 '\001',
names_defined_in_bb=0x10a8d9d0) at ../../gcc/gcc/tree-ssa.c:228
#3 0x100ae404 in verify_ssa (check_modified_stmt=1 '\001') at
../../gcc/gcc/tree-ssa.c:735
#4
#5 tree_ssa_cd_dce () at ../../gcc/gcc/tree-ssa-dce.c:947
#6 0x1051b110 in execute_one_pass (pass=0x1088c584) at
../../gcc/gcc/passes.c:853
#7 0x1051b2c8 in execute_pass_list (pass=0x1088c584) at
../../gcc/gcc/passes.c:897
#8 0x1051b2f4 in execute_pass_list (pass=0x108876dc) at
../../gcc/gcc/passes.c:898
#9 0x100b1684 in tree_rest_of_compilation (fndecl=0xf7862d00) at
../../gcc/gcc/tree-optimize.c:412
#10 0x10016914 in c_expand_body (fndecl=0xf7862d00) at
../../gcc/gcc/c-decl.c:6689
#11 0x1059b914 in cgraph_expand_function (node=0xf75b3e00) at
../../gcc/gcc/cgraphunit.c:1101
#12 0x1059bba4 in cgraph_expand_all_functions () at
../../gcc/gcc/cgraphunit.c:1166
#13 0x1059c798 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1434
#14 0x1001a024 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7804
#15 0x104d99a8 in compile_file () at ../../gcc/gcc/toplev.c:1012
#16 0x104dbc64 in do_compile () at ../../gcc/gcc/toplev.c:1957
#17 0x104dbcf8 in toplev_main (argc=54, argv=0xffdf2c74) at
../../gcc/gcc/toplev.c:1989
#18 0x10090518 in main (argc=54, argv=0xffdf2c74) at ../../gcc/gcc/main.c:35
(gdb) p debug_tree (0xf6d34e40)
sizes-gimplified asm_written public unsigned SI
size
unit size
align 32 symtab -137297872 alias set -1
pointer_to_this >
asm_written BLK
size
[Bug preprocessor/29612] [4.0/4.1/4.2/4.3 Regression] gcc --save-temps does not give "multi-character character constant" error
-- 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|2006-10-27 04:47:37 |2006-11-08 11:02:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29612
[Bug fortran/27546] [F2003] IMPORT not implemented
--- Comment #5 from patchapp at dberlin dot org 2006-11-08 10:05 --- Subject: Bug number PR27546 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00466.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546
[Bug middle-end/29756] SSE intrinsics hard to use without redundant temporaries appearing
--- Comment #3 from timday at bottlenose dot demon dot co dot uk 2006-11-08 10:01 --- I've just tried an alternative version (will upload later) replacing the union with a single __v4sf _rep, and implementing the [] operators using e.g (reinterpret_cast(&_rep))[i]; However the code generated by the two transform implementations remains the same (20 and 32 instructions anyway; haven't checked the details yet). Maybe not surprising as it's just moving the problem around. The big difference between the two methods is perhaps primarily that the bad one involves a __v4sf->float->__vfs4 conversion, while the good one uses __v4sf throughout by using the mul_compN methods. I'll try and prepare a more concise test case based on the premise that bad handling of __v4sf <-> float is the real issue. -- timday at bottlenose dot demon dot co dot uk changed: What|Removed |Added CC||timday at bottlenose dot ||demon dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29756
[Bug fortran/29755] ICE on same name in subroutine and program
--- Comment #1 from patchapp at dberlin dot org 2006-11-08 10:01 --- Subject: Bug number PR29755 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00465.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29755
[Bug c++/28088] [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-11-08 09:51
---
Another testcase, this one from some other code that uses boost:
template< typename T> struct has_begin {static const bool value =0;};
template struct sequence_tag_impl{};
template< typename Sequence>
struct sequence_tag : sequence_tag_impl::value >{};
templatestruct lambda{};
template class F, typename T1 >struct lambda
>{};
template< typename Tag >struct size_impl;
template::type
>::value>
struct basic_expr{};
int main()
{
lambda > a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088
