[Bug libstdc++/36428] std::tr1 Header Location
--- Comment #2 from christopher dot kormanyos at al-lighting dot com 2008-06-05 08:21 --- OK now I understand your strategy. Thanks for the explaination. But there is still a problem in the community. Two very popular compilers (VC and GCC) which are often used in cross development projects together now have different include paths for the C++ tr1 stuff. And it seems like support for tr1 must exist for quite some time until the transition to c++0x is complete. We have discussed this with a few other developers and we wonder if it would be possible to somehow add to the include path based on a new compiler switch. Perhaps there could be an additional compiler switch like std=c++98tr1. This would allow for code-compatibility when using tr1 and simultaneously allow the build system to be independent of the compiler location. Could this be considered as a change request? Thank you for your consideration. Sincerely, Chris. -- christopher dot kormanyos at al-lighting dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36428
[Bug other/28322] GCC new warnings and compatibility
--- Comment #20 from pmaydell at chiark dot greenend dot org dot uk 2008-06-05 08:31 --- I wrote: >The deferred 'unrecognised -Wno*' output should only be a warning, not an >error. I suggested a patch that would correct this: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00139.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
[Bug c++/36439] New: [4.3 regression] infinite loop building gimp-plugin-registry
[forwarded from http://bugs.debian.org/484569] seen with 4.3.1 20080523, works with 4.2.4. Replacing -O2 with -O1 lets the build succeed. Matthias g++ -Wall -g -O2 -save-temps -pthread greycstoration4gimp.ii timed out after 150min on various buildds. -- Summary: [4.3 regression] infinite loop building gimp-plugin- registry Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug rtl-optimization/36438] gcc ICE compiling code with mmx builtin
--- Comment #2 from ubizjak at gmail dot com 2008-06-05 11:21 --- Your testcase works for me on i686-pc-linux-gnu with 'GCC: (GNU) 4.4.0 20080605 (experimental) [trunk revision 136389]', with -mmmx and all optimization levels: .L5: movq%mm1, %mm0 psllq $8, %mm0 psllq $8, %mm0 movq%mm0, (%ecx,%eax,8) addl$1, %eax movq%mm0, %mm1 cmpl%eax, %edx jg .L5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36438
[Bug c++/36439] [4.3/4.4 Regression] infinite loop in PRE building gimp-plugin-registry
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-05 11:24 --- In function cimg_library::CImg& cimg_library::CImg::blur_patch(unsigned int, float, float, unsigned int, bool), which contains some number of loops from macro expansion stuff. -fno-tree-pre "fixes" it. phi-translation is dog slow. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||compile-time-hog Summary|[4.3 regression] infinite |[4.3/4.4 Regression] |loop building gimp-plugin- |infinite loop in PRE |registry|building gimp-plugin- ||registry http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug c++/36439] [4.3/4.4 Regression] infinite loop in PRE building gimp-plugin-registry
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-05 11:37 --- Created an attachment (id=15722) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15722&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug c++/36439] [4.3/4.4 Regression] infinite loop in PRE building gimp-plugin-registry
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-05 11:37:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug rtl-optimization/36438] gcc ICE compiling code with mmx builtin
--- Comment #3 from ubizjak at gmail dot com 2008-06-05 11:53 --- The bug triggers on x86_64-pc-linux-gnu target. I will look into it. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||x86_64-pc-linux-gnu Last reconfirmed|-00-00 00:00:00 |2008-06-05 11:53:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36438
[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions
--- Comment #5 from gunnar at greyhound-data dot com 2008-06-05 12:07 --- Please find below a proposed patch. The patch will making GCC aware that shift does set the CC already and the TST is not needed in this case. The same example could be used to used to make GCC aware of the CC set by other instructions. Index: gcc/config/m68k/m68k.md === *** gcc/config/m68k/m68k.md.orig2008-05-30 10:00:55.0 +0200 --- gcc/config/m68k/m68k.md 2008-06-04 17:01:11.0 +0200 *** *** 5198,5203 --- 5198,5215 [(set_attr "type" "shift") (set_attr "opy" "2")]) + (define_insn "*lshrsi3_cc" + [(set (cc0) + (lshiftrt:SI (match_operand:SI 1 "register_operand" "0") +(match_operand:SI 2 "general_operand" "dI"))) +(set (match_operand:SI 0 "register_operand" "=d") + (lshiftrt:SI (match_dup 1) +(match_dup 2)))] + "" + "lsr%.l %2,%0" + [(set_attr "type" "shift") +(set_attr "opy" "2")]) + (define_insn "lshrhi3" [(set (match_operand:HI 0 "register_operand" "=d") (lshiftrt:HI (match_operand:HI 1 "register_operand" "0") -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36133
[Bug libstdc++/36428] std::tr1 Header Location
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-06-05 12:24 --- Use -std=c++0x if you want them in the "correct" location. They are only part of the C++0x standard and not part of C++98/03 standards. -- 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=36428
[Bug rtl-optimization/36438] gcc ICE compiling code with mmx builtin
--- Comment #4 from ubizjak at gmail dot com 2008-06-05 12:50 --- There is a general problem with vector shifts by scalar operands. The code assumed that both operands are vector mode operands, so it tries to add both constant shift operands using V1DImode. Following patch fixes ICE: Index: cse.c === --- cse.c (revision 136389) +++ cse.c (working copy) @@ -3489,6 +3489,11 @@ fold_rtx (rtx x, rtx insn) && exact_log2 (- INTVAL (const_arg1)) >= 0))) break; + /* ??? Vector mode shifts by scalar +shift operand are not supported yet. */ + if (is_shift && VECTOR_MODE_P (mode)) + break; + if (is_shift && (INTVAL (inner_const) >= GET_MODE_BITSIZE (mode) || INTVAL (inner_const) < 0)) -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-06-05 11:53:55 |2008-06-05 12:50:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36438
[Bug tree-optimization/36439] [4.3/4.4 Regression] infinite loop in PRE building gimp-plugin-registry
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c++ |tree-optimization Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug testsuite/36440] New: [4.4 Regression] FAIL: g++.dg/cdce3.C on powerpc-apple-darwin8.5.0
On powerpc-apple-darwin8.5.0 (see
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00340.html) one has:
FAIL: g++.dg/cdce3.C (test for excess errors)
WARNING: g++.dg/cdce3.C compilation failed to produce executable
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:68: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:69: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:70: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:71: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:72: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:73: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:74: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:75: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:76: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:77: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:78: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:79: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:80: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:81: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:82: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:83: note: function call is
shrink-wrapped into error conditions.": dump file does not exist
although the first line is
/* { dg-do run { target { ! "*-*-darwin" } } } */
Is the syntax correct?
--
Summary: [4.4 Regression] FAIL: g++.dg/cdce3.C on powerpc-apple-
darwin8.5.0
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin8.5.0
GCC host triplet: powerpc-apple-darwin8.5.0
GCC target triplet: powerpc-apple-darwin8.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36440
[Bug rtl-optimization/36419] [4.1/4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-06-05 14:00 --- > Any ideas about this? Do you think it is ok to just apply 1) or should we > e.g. try to remove unnecessary stack adjustments before _Unwind_Resume > (though, _Unwind_Resume is a call, so we probably need to guarantee correct > stack alignment at least). Exception propagation is already slow (with DWARF-2 EH) so I don't think we should bother about performance here; applying 1) as-is seems fine to me. > For 2) and 3), we might just walk the whole function, noting the level of > stack pushing for all labels, verify at CALLs that it matches their second > operand and verify that all jumps to labels have the same level of stack > pushing. Why is 2) problematic on principle? I mean, prologue insns are translated into CFI like non-prologue stack adjustment insns so why is it a problem that one of the latters "become" one of the formers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug fortran/36441] New: gfortran looks for .mod files in default locations before -I directories
gfortran appears to pick up .mod files from default locations in preference to directories specified by -I arguments on the command line. So, for example, if foo.mod is in /usr/include and foo.mod is in /home/bar/somedir and the user types: gfortran -I/home/bar/somedir ... then gfortran will pick up /usr/include/foo.mod . This causes particular problems when the system gfortran distributed with the OS is, say, 4.2 and a user has installed gfortran 4.3 since nothing the user can specify on the command line will prevent .mod files from installed packages (generally compiled with 4.2) being used. -- Summary: gfortran looks for .mod files in default locations before -I directories Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: David at ham dot dropbear dot id dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36441
[Bug c++/36391] Compilation never ends
--- Comment #2 from ivan at cvut dot cz 2008-06-05 14:35 --- This bug is related to x86_64 target. When generating 32bit .o file, compilations succeds even with 64bit version of g++. See: [EMAIL PROTECTED]:/tmp$ g++ -m32 trotl_parser.i In file included from /usr/include/c++/4.2/ext/new_allocator.h:38, from /usr/include/c++/4.2/x86_64-linux-gnu/bits/c++allocator.h:40, from /usr/include/c++/4.2/bits/allocator.h:54, from /usr/include/c++/4.2/memory:55, from /usr/include/c++/4.2/string:49, from ../../src/trotl_parser.h:38, from ../../src/trotl_parser.cpp:35: /usr/include/c++/4.2/new:95: error: operator new takes type size_t (unsigned int) as first parameter /usr/include/c++/4.2/new:96: error: operator new takes type size_t (unsigned int) as first parameter /usr/include/c++/4.2/new:99: error: operator new takes type size_t (unsigned int) as first parameter /usr/include/c++/4.2/new:100: error: operator new takes type size_t (unsigned int) as first parameter /usr/include/c++/4.2/new:105: error: operator new takes type size_t (unsigned int) as first parameter /usr/include/c++/4.2/new:106: error: operator new takes type size_t (unsigned int) as first parameter [EMAIL PROTECTED]:/tmp$ [EMAIL PROTECTED]:/tmp$ time g++ -m32 trotl_parser.i In file included from /usr/include/c++/4.2/ext/new_allocator.h:38, from /usr/include/c++/4.2/x86_64-linux-gnu/bits/c++allocator.h:40, from /usr/include/c++/4.2/bits/allocator.h:54, from /usr/include/c++/4.2/memory:55, from /usr/include/c++/4.2/string:49, from ../../src/trotl_parser.h:38, from ../../src/trotl_parser.cpp:35: /usr/include/c++/4.2/new:95: error: operator new takes type size_t (unsigned int) as first parameter /usr/include/c++/4.2/new:96: error: operator new takes type size_t (unsigned int) as first parameter /usr/include/c++/4.2/new:99: error: operator new takes type size_t (unsigned int) as first parameter /usr/include/c++/4.2/new:100: error: operator new takes type size_t (unsigned int) as first parameter /usr/include/c++/4.2/new:105: error: operator new takes type size_t (unsigned int) as first parameter /usr/include/c++/4.2/new:106: error: operator new takes type size_t (unsigned int) as first parameter real 0m2.807s user 0m2.588s sys 0m0.212s [EMAIL PROTECTED]:/tmp$ time g++ -m64 trotl_parser.i Terminated real81m2.005s user0m0.000s sys 0m0.004s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36391
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-06-05 14:40 --- I have a working backport for 4.3.2 that get's memory usage down. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug fortran/36441] gfortran looks for .mod files in default locations before -I directories
--- Comment #1 from David at ham dot dropbear dot id dot au 2008-06-05 14:48 --- Apologies, this appears to have been caused by idiocy on our part. We now believe gfortran does the right thing and includes -I first. -- David at ham dot dropbear dot id dot au changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36441
[Bug rtl-optimization/36438] gcc ICE compiling code with mmx builtin
--- Comment #5 from ubizjak at gmail dot com 2008-06-05 17:05 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00268.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||06/msg00268.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36438
[Bug rtl-optimization/36438] gcc ICE compiling code with mmx builtin
--- Comment #6 from davidxl at gcc dot gnu dot org 2008-06-05 17:37 --- (In reply to comment #5) > Patch at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00268.html > Thanks -- same as my local workaround. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36438
[Bug fortran/36366] [4.3/4.4 Regression] ICE in gfc_conv_component_ref
--- Comment #2 from pault at gcc dot gnu dot org 2008-06-05 19:45 --- > At the moment, I cannot see what draws these together. Nor can I see any > difference in the .mod files for the cases that work Ah... go it! gcc-4.2 had a derived type list for each namespace and care was taken to apply the same backend_decl to each like derived type in all namespaces, including formal namespaces. gcc-4.3 onwards uses a single list, generate in resolve.c. This was failing to check derived type components, with the result that they could be missed in formal namespaces. This fixes the problem: Index: gcc/fortran/resolve.c === *** gcc/fortran/resolve.c (revision 136412) --- gcc/fortran/resolve.c (working copy) *** resolve_fl_derived (gfc_symbol *sym) *** 7637,7642 --- 7637,7647 return FAILURE; } + /* Ensure that all the derived type components are put on the +derived type list; even in formal namespaces. */ + if (c->ts.type == BT_DERIVED && c->ts.derived) + resolve_fl_derived (c->ts.derived); + if (c->pointer || c->allocatable || c->as == NULL) continue; It's mine! If it regtests OK, I'll apply it as obvious. 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|NEW |ASSIGNED Last reconfirmed|2008-05-29 12:05:35 |2008-06-05 19:45:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36366
[Bug libgomp/36442] New: libgomp fails when using --with-build-sysroot
I'm using both --with-build-sysroot and --with-sysroot when I compile GCC, so that I can compile it against a different version of the local system than the one I'm compiling on. Most of the build works fine, with the exception of the libraries libgomp, libmudflap, and libssp. Each of those fails because they do not take notice of the --with-build-sysroot directive, and thus they cannot find important files like crti.o etc. I configured with this: --with-build-sysroot=/tmp/invalid/gcc/i686-redhat71-linux-gnu --with-sysroot=/invalid where /tmp/invalid/gcc/i686-redhat71-linux-gnu is an extracted sysroot from Red Hat 7.1 (surprise!) Everything chugs along OK until the above-mentioned libraries, then: /usr/src/gcc/obj/gcc/./gcc/xgcc -B/usr/src/gcc/obj/gcc/./gcc/ -B/tmp/invalid/gcc/i686-generic-linux-gnu/bin/ -B/tmp/invalid/gcc/i686-generic-linux-gnu/lib/ -isystem /tmp/invalid/gcc/i686-generic-linux-gnu/include -isystem /tmp/invalid/gcc/i686-generic-linux-gnu/sys-include -shared .libs/ssp.o .libs/gets-chk.o .libs/memcpy-chk.o .libs/memmove-chk.o .libs/mempcpy-chk.o .libs/memset-chk.o .libs/snprintf-chk.o .libs/sprintf-chk.o .libs/stpcpy-chk.o .libs/strcat-chk.o .libs/strcpy-chk.o .libs/strncat-chk.o .libs/strncpy-chk.o .libs/vsnprintf-chk.o .libs/vsprintf-chk.o -Wl,--version-script=/usr/src/gcc/gcc-4.2.4/libssp/ssp.map -Wl,-soname -Wl,libssp.so.0 -o .libs/libssp.so.0.0.0 /tmp/invalid/gcc/bin/i686-generic-linux-gnu-ld: crti.o: No such file: No such file or directory collect2: ld returned 1 exit status make[4]: *** [libssp.la] Error 1 make[4]: Leaving directory `/usr/src/gcc/obj/gcc/i686-generic-linux-gnu/libssp' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/src/gcc/obj/gcc/i686-generic-linux-gnu/libssp' make[2]: *** [all-target-libssp] Error 2 The other two libraries gave essentially identical errors. I don't think the -B etc. options here are correct; they seem to be remnants from previous versions of GCC, before the --with-sysroot and --with-build-sysroot flags were supported. The configure.in files for these libraries need to be updated. -- Summary: libgomp fails when using --with-build-sysroot Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: psmith at gnu dot org GCC target triplet: i686-generic-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36442
[Bug testsuite/36443] New: HOST_CC doesn't work with --disable-bootstrap
When --disable-bootstrap, HOST_CC is set to gcc. It is used in g++.dg/compat/struct-layout-1.exp:set status [remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd"] gcc.dg/compat/struct-layout-1.exp:set status [remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd"] objc.dg/gnu-encoding/gnu-encoding.exp:set status [remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd"] "make check" will create site.exp with set GCC_EXEC_PREFIX "$(libdir)/gcc/" This will make system gcc 4.1 and 4.3 fail to compile since they can't find their own head files. -- Summary: HOST_CC doesn't work with --disable-bootstrap Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] HOST_CC doesn't work with --disable-bootstrap
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-05 21:32 --- --disable-bootstrap should not be used really, why are you using it anyways? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug middle-end/36444] New: [4.4 Regression] ICE in gen_lowpart_general with -O1 with vector registers
Testcase:
#define vector __attribute__((vector_size(16) ))
struct struct1 {
union {}vmx;
struct struct2 {
struct2(const struct2& r) {}
} w;
} __attribute__((aligned(16)));
struct struct3 {
vector float vmx;
operator const struct1& () const{
return *reinterpret_cast(this);
}
};
struct3 func3( struct3 V1);
struct3 func2( void );
void func1( ) {
struct1 vVec = func2() ;
func3 ( (struct3&)vVec );
}
--- CUT ---
On PowerPC use -O1 -maltivec, on x86 use -msse2 -O1. This was exposed by my
using VCE more patch.
--
Summary: [4.4 Regression] ICE in gen_lowpart_general with -O1
with vector registers
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36444
[Bug testsuite/36443] HOST_CC doesn't work with --disable-bootstrap
--- Comment #2 from hjl dot tools at gmail dot com 2008-06-05 21:34 --- (In reply to comment #1) > --disable-bootstrap should not be used really, why are you using it anyways? > There is no easy way to debug gcc compiled with -O2. Why do we put set GCC_EXEC_PREFIX "$(libdir)/gcc/" in site.exp when we aren't testing installed gcc? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug middle-end/36444] [4.4 Regression] ICE in gen_lowpart_general with -O1 with vector registers
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36444
[Bug middle-end/36445] New: [4.4 Regression] ICE in expand_expr_real_1 with -O1 with vector registers
Another fallout due to the using VCE more patch:
#define vector __attribute__((vector_size(16) ))
struct struct1 {
union { float a[3]; }vmx;
struct struct2 {
struct2(const struct2& r) {}
} w;
} __attribute__((aligned(16)));
struct struct3 {
vector float vmx;
operator const struct1& () const{
return *reinterpret_cast(this);
}
};
struct3 func3( struct3 V1);
struct3 func2( void );
void func1( ) {
struct1 vVec = func2() ;
func3 ( (struct3&)vVec );
}
--- CUT ---
This time you need to compile with -O2 -maltivec and it does not happen under
x86 for some reason.
--
Summary: [4.4 Regression] ICE in expand_expr_real_1 with -O1 with
vector registers
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36445
[Bug middle-end/36445] [4.4 Regression] ICE in expand_expr_real_1 with -O1 with vector registers
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36445
Re: [Bug testsuite/36443] HOST_CC doesn't work with --disable-bootstrap
On Thu, Jun 5, 2008 at 2:34 PM, hjl dot tools at gmail dot com <[EMAIL PROTECTED]> wrote: > There is no easy way to debug gcc compiled with -O2. You know if you compile cc1 manually inside the gcc directory, it will compile with -O0 -g. Also you can use stage1-gcc directory to debug and build cc1plus, etc. -- Pinski
[Bug testsuite/36443] HOST_CC doesn't work with --disable-bootstrap
--- Comment #3 from pinskia at gmail dot com 2008-06-05 21:42 --- Subject: Re: HOST_CC doesn't work with --disable-bootstrap On Thu, Jun 5, 2008 at 2:34 PM, hjl dot tools at gmail dot com <[EMAIL PROTECTED]> wrote: > There is no easy way to debug gcc compiled with -O2. You know if you compile cc1 manually inside the gcc directory, it will compile with -O0 -g. Also you can use stage1-gcc directory to debug and build cc1plus, etc. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOST_CC doesn't work with --disable-bootstrap
--- Comment #4 from hjl dot tools at gmail dot com 2008-06-05 21:58 --- This behavior was introduced by http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01493.html I rarely install gcc on my build machines. I am not sure why they are needed for testing gcc just built. If they are used for testing installed gcc, shouldn't there be different targets? -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||carlos at codesourcery dot ||com, mark at codesourcery ||dot com Summary|HOST_CC doesn't work with --|[4.3/4.4 Regression]: |disable-bootstrap |HOST_CC doesn't work with -- ||disable-bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug c/36446] New: unexplained warning in struct initialization
/*
gcc -W -c test.c
test.c:18: warning: (near initialization for m1.h.b)
*/
struct h {
int a;
int b;
};
struct m {
struct h h;
int c;
};
struct m m1 = {
.h.a = 1,
.c = 2,
};
struct m m2 = {
.h = {.a = 1},
.c = 2,
};
m1 has that warning, but m2 is ok.
I hit this with both these:
gcc version 4.1.1
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
-Geoff
--
Summary: unexplained warning in struct initialization
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffrey dot levand at am dot sony dot com
GCC host triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36446
[Bug c/36446] unexplained warning in struct initialization
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-05 21:59 --- Also seen on the trunk (4.4.0). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||diagnostic Version|4.2.1 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36446
[Bug c/36446] unexplained warning in struct initialization
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-05 22:01 --- On the trunk we get: t.c:13: warning: missing initializer t.c:13: warning: (near initialization for m1.h.b) Which seems wrong as we don't get the warning for m2 and if we add an initializer for m1.h.b we get a different warning: t.c:13: warning: missing initializer t.c:13: warning: (near initialization for m1.h.b) t.c:14: warning: initialized field overwritten t.c:14: warning: (near initialization for m1.h) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36446
[Bug middle-end/36444] [4.4 Regression] ICE in gen_lowpart_general with -O1 with vector registers
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-05 22:56 --- Fix for at least PowerPC (we should be trying to get the correct sized vector mode): Index: expmed.c === --- expmed.c(revision 2510) +++ expmed.c(working copy) @@ -1129,7 +1129,7 @@ extract_bit_field (rtx str_rtx, unsigned new_mode = MIN_MODE_VECTOR_INT; for (; new_mode != VOIDmode ; new_mode = GET_MODE_WIDER_MODE (new_mode)) - if (GET_MODE_NUNITS (new_mode) == nunits + if (GET_MODE_SIZE (new_mode) == GET_MODE_SIZE (new_mode) && GET_MODE_INNER (new_mode) == tmode && targetm.vector_mode_supported_p (new_mode)) break; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36444
[Bug target/35658] [4.3/4.4 regression] Bad interaction on ia64 between -funroll-loops -fno-automatic -O2 and common block variable
--- Comment #7 from sje at cup dot hp dot com 2008-06-05 23:02 --- I now think this is a register scheduling bug. If I use -fno-schedule-insns2 then the bug doesn't happen even with "-O2 fno-automatic -frename-registers". The problem seems to be scheduling the assignment to TEMP2 and assigning TEMP2 to F(K). In the good code, in C201S I see the following instructions, in this order: addl r17 = @gprel(temp2.717#), gp - r17 is addr of temp2 stfd [r17] = f0 - zero out temp2 (p11) stfd [r17] = f10- (maybe) put value (2.0) in temp2 ldfd f9 = [r17] - load temp2 add r16 = r34, r37- r16 is addr of F(1) stfd [r16] = f9 - store temp2 in F(1) In the bad code (with instruction scheduling turned on) I see: addl r17 = @gprel(temp2.717#), gp - r17 is addr of temp2 add r16 = r34, r37- r16 is addr of F(1) ldfd f9 = [r17] - load temp2 stfd [r17] = f0 - zero out temp2 stfd [r16] = f9 - store (old) temp2 in F(1) (p11) stfd [r17] = f10- (maybe) put value (2.0) in temp2 The store into F(1) is done before we have put the correct value int temp2. I don't understand how instruction scheduling could be this broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
[Bug c++/21917] Missing warning when trying to explicitly construct a virtual base
--- Comment #7 from r_q_einstein-gccgnuorg at yahoo dot com 2008-06-05 23:07 --- I've run across this, too. I agree with Ivan's 2005-06-04 suggestion. It would be nice if the compiler would emit a warning that the derived class's constructor's call to the virtual base class's non-default constructor is being ignored and overridden by an implicit call to the virtual base class's default constructor. Similarly, if the virtual base class fails to specify a default constructor (and specifies only a non-default one), the derived class's constructor's call to the virtual base class's non-default constructor produces only this error message: In constructor 'top::top()': error: no matching function for call to 'virt::virt()' which leaves the developer scratching his/her head if he doesn't know that the C++ spec. requires virtual base classes to have default constructors. (True, s/he should know, but the compile error message could be more helpful.) Something to the effect of: "virtual base class lacks default constructor" would be much more helpful. If this issue is different enough to warrant a separate "bug" report, let me know and I'll be happy to file it separately. Thanks. -- r_q_einstein-gccgnuorg at yahoo dot com changed: What|Removed |Added CC||r_q_einstein-gccgnuorg at ||yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21917
[Bug middle-end/36444] [4.4 Regression] ICE in gen_lowpart_general with -O1 with vector registers
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-05 23:13 ---
And the fix for the second issue:
Index: expr.c
===
--- expr.c (revision 2510)
+++ expr.c (working copy)
@@ -7654,6 +7654,16 @@ expand_expr_real_1 (tree exp, rtx target
{
if (target == 0)
target = assign_temp (type, 0, 1, 1);
+
+ /* If we don't have a memory location for op0, make a new
location for it. */
+ if (!MEM_P (op0))
+ {
+ rtx op0_mem = assign_stack_temp (GET_MODE (op0),
+GET_MODE_SIZE (GET_MODE
(op0)),
+0);
+ emit_move_insn (op0_mem, op0);
+ op0 = op0_mem;
+ }
if (bitsize == 0)
return target;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36444
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- Comment #11 from joel at gcc dot gnu dot org 2008-06-05 23:32 --- Created an attachment (id=15723) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15723&action=view) updated patch Updated to account for changes to s-osinte-vxworks.adb while this PR has lingered in the queue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- Comment #12 from joel at gcc dot gnu dot org 2008-06-05 23:34 --- s-osinte-vxworks.adb is not removed by the patch. For review purposes, you should diff s-osinte-vxworks.adb to s-osinte-hwint.adb to see what the changes were. 2008-05-28 Joel Sherrill <[EMAIL PROTECTED]> * Makefile.in: Switch RTEMS and VxWorks to s-interr-hwint.adb. * s-interr-hwint.adb: New file with portable implementation. This is a mechanical change of s-interr-vxworks.adb to use the new OS provided adapter. * s-interr-vxworks.adb: Removed. * s-osinte-rtems.ads, s-osinte-vxworks.adb, s-osinte-vxworks.ads: Add shared hardware interrupt adapter layer. RTEMS binds to OS provided adapter routines so there are no modifications to s-osinte-rtems.adb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug c/36447] New: simplify_subreg ICE with right shift more than length type AVR
Works on avr-gcc (GCC) 4.2.2 (WinAVR 20071221). Does not on 4.4 HEAD.
Test results posts show this test failing since AT LEAST SVN rev 132993 on AVR
(March 3 2008) (before that test was not run - so dont know when it started.
gcc-c/toture/unsorted/shm.c
foo (int *p)
{
int a = *p;
return a >> 24;
}
/home/hutchia/Desktop/gcc/gcc/testsuite/gcc.c-torture/unsorted/shm.c:5:
internal compiler error: in simplify_subreg, at simplify-rtx.c:4962
test.c: In function 'foo':
test.c:4: warning: right shift count >= width of type
Analyzing compilation unit
Performing interprocedural optimizations
Assembling functions:
foo
Breakpoint 1, fancy_abort (file=0xb030f2 "../../gcc/gcc/simplify-rtx.c",
line=4962, function=0xb03158 "simplify_subreg")
at ../../gcc/gcc/diagnostic.c:654
654 internal_error ("in %s, at %s:%d", function, trim_filename (file),
lin
e);
(gdb) where
#0 fancy_abort (file=0xb030f2 "../../gcc/gcc/simplify-rtx.c", line=4962,
function=0xb03158 "simplify_subreg") at ../../gcc/gcc/diagnostic.c:654
#1 0x007a1143 in simplify_subreg (outermode=QImode, op=0x7ff24f20,
innermode=HImode, byte=3) at ../../gcc/gcc/simplify-rtx.c:4937
#2 0x007a1672 in simplify_gen_subreg (outermode=QImode, op=0x7ff24f20,
innermode=HImode, byte=3) at ../../gcc/gcc/simplify-rtx.c:5287
#3 0x007a0b83 in simplify_subreg (outermode=QImode, op=0x7ff25100,
innermode=HImode, byte=0) at ../../gcc/gcc/simplify-rtx.c:5271
#4 0x007a1672 in simplify_gen_subreg (outermode=QImode, op=0x7ff25100,
innermode=HImode, byte=0) at ../../gcc/gcc/simplify-rtx.c:5287
#5 0x0098f86a in propagate_rtx_1 (px=0x22caf4, old=0x4, new=0x7ff25100,
flags=2) at ../../gcc/gcc/fwprop.c:333
#6 0x009907da in forward_propagate_into (use=0x0)
at ../../gcc/gcc/fwprop.c:457
#7 0x00990bc2 in fwprop () at ../../gcc/gcc/fwprop.c:1055
#8 0x00624a0e in execute_one_pass (pass=0x0) at ../../gcc/gcc/passes.c:1292
#9 0x00624b33 in execute_pass_list (pass=0xa8c320)
at ../../gcc/gcc/passes.c:1342
#10 0x00624b46 in execute_pass_list (pass=0xa8c5c0)
at ../../gcc/gcc/passes.c:1343
#11 0x0084d899 in tree_rest_of_compilation (fndecl=0x7fdbf1f0)
at ../../gcc/gcc/tree-optimize.c:421
#12 0x00625d4b in cgraph_expand_function (node=0x7ff40280)
at ../../gcc/gcc/cgraphunit.c:1148
#13 0x0062793e in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1211
#14 0x0041bee7 in c_write_global_declarations ()
at ../../gcc/gcc/c-decl.c:8062
#15 0x0062c95b in toplev_main (argc=3, argv=0x1c014c0)
at ../../gcc/gcc/toplev.c:976
#16 0x0049467a in main (argc=3, argv=0x1c014c0) at ../../gcc/gcc/main.c:35
--
Summary: simplify_subreg ICE with right shift more than length
type AVR
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hutchinsonandy at aim dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36447
[Bug middle-end/36447] simplify_subreg ICE with right shift more than length type AVR
--- Comment #1 from hutchinsonandy at aim dot com 2008-06-06 03:08 --- rev 132971 appears to have created this problem. Revision: 132971 Author: bonzini Date: 8:30:10 AM, Thursday, March 06, 2008 Message: 2008-03-06 Paolo Bonzini <[EMAIL PROTECTED]> * simplify-rtx.c (simplify_subreg): Remove useless shifts from word-extractions out of a multi-word object. Modified : /trunk/gcc/ChangeLog Modified : /trunk/gcc/simplify-rtx.c It fails because subreg simplification tries to extract byte 3 of the HImode int 'a' at simplify-rtx 5271. No check is performed here to see if shift count >= length. For this case simplification should give sign of value (-1 or 0). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36447
