[Bug c++/33754] Default argument of type list pair A, B compiles only when typedef is used
--- Comment #5 from photon at seznam dot cz 2007-10-15 07:29 --- (In reply to comment #4) DR 325 describes the ambiguities in the standard. There are a number of possible solutions to accepting this syntax, with different implementation complexities, and it is not clear what the desired outcome is. The desired outcome is clear in this case but the compiler does not recognize the template arguments. Before encountering '=' the parser honors the template argument separator with a higher priority than the function argument separator, afterwards it does not. That does not make sense and certainly either the standard or the compiler should be fixed. As there is a simple workaround -- adding parentheses -- which is unambiguously correct, I do not see a need to speculatively implement a language extension here. Provided the standard is ambiguous, fixing this problem would not introduce a language extension. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33754
[Bug c++/33754] Default argument of type list pair A, B compiles only when typedef is used
--- Comment #6 from nathan at codesourcery dot com 2007-10-15 08:24 --- Subject: Re: Default argument of type list pair A, B compiles only when typedef is used photon at seznam dot cz wrote: As there is a simple workaround -- adding parentheses -- which is unambiguously correct, I do not see a need to speculatively implement a language extension here. Provided the standard is ambiguous, fixing this problem would not introduce a language extension. What are your thoughts about the other issues raised by 325? nathan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33754
[Bug c/33776] New: Crash during a build of zsh
See the diagnostic message from the build gcc itself below: make[3]: Entering directory `/usr/src/zsh/zsh-4.3.4/Src/Builtins' gawk -f ./rlimits.awk /usr/include/sys/resource.h /dev/null rlimits.h /usr/local/bin/gcc -c -I. -DHAVE_CONFIG_H -DMODULE -O2 -o rlimits..o rlimits.c rlimits.c: In function 'bin_unlimit': rlimits.c:674: error: unrecognizable insn: (insn 44 43 45 7 (set (reg:SI 84) (const:SI (plus:SI (mem:SI (symbol_ref:SI (#i.current_limits) var_decl 0x7ff917b8 current_limits) [0 S4 A8]) (const_int 4 [0x4] -1 (nil) (nil)) rlimits.c:674: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [rlimits..o] Error 1 - end of paste please let me know how to correct this or how you to correct it. regards, darel henman -- Summary: Crash during a build of zsh Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: henman at it dot to-be dot co dot jp GCC build triplet: gcc (GCC) 4.2.2(just read the error message below:) GCC host triplet: see below cygwin i586... GCC target triplet: CYGWIN_NT-5.1 1.5.24(0.156/4/2) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33776
[Bug c/33777] New: Crash during a build of zsh
See the diagnostic message from the build gcc itself below: make[3]: Entering directory `/usr/src/zsh/zsh-4.3.4/Src/Builtins' gawk -f ./rlimits.awk /usr/include/sys/resource.h /dev/null rlimits.h /usr/local/bin/gcc -c -I. -DHAVE_CONFIG_H -DMODULE -O2 -o rlimits..o rlimits.c rlimits.c: In function 'bin_unlimit': rlimits.c:674: error: unrecognizable insn: (insn 44 43 45 7 (set (reg:SI 84) (const:SI (plus:SI (mem:SI (symbol_ref:SI (#i.current_limits) var_decl 0x7ff917b8 current_limits) [0 S4 A8]) (const_int 4 [0x4] -1 (nil) (nil)) rlimits.c:674: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [rlimits..o] Error 1 - end of paste please let me know how to correct this or how you to correct it. regards, darel henman -- Summary: Crash during a build of zsh Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: henman at it dot to-be dot co dot jp GCC build triplet: gcc (GCC) 4.2.2(just read the error message below:) GCC host triplet: see below cygwin i586... GCC target triplet: CYGWIN_NT-5.1 1.5.24(0.156/4/2) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33777
[Bug c/33777] Crash during a build of zsh
--- Comment #1 from henman at it dot to-be dot co dot jp 2007-10-15 08:33 --- none -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33777
[Bug c/33777] Crash during a build of zsh
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-10-15 09:00 --- I believe this is a dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826 The bug was closed as fixed but reappeared on 4.2.x when Richard Henderson's TLS emulation patch was reverted on the branch. See comment #16 in PR 29826 for a patch. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33777
[Bug libstdc++/33773] FAIL: 21_strings/headers/cwchar/macros.cc (test for excess errors)
--- Comment #1 from pcarlini at suse dot de 2007-10-15 09:12 --- What does it mean These are defined in hpux11? The test fails... Apparently the real problem is that wchar_t is globally disabled on that target, therefore cwchar doesn't actually include wchar.h. Then, -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-15 09:12:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33773
[Bug c/33777] Crash during a build of zsh
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-15 09:14 --- *** Bug 33776 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33777
[Bug c/33776] Crash during a build of zsh
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-15 09:14 --- *** This bug has been marked as a duplicate of 33777 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33776
[Bug libstdc++/33773] FAIL: 21_strings/headers/cwchar/macros.cc (test for excess errors)
--- Comment #2 from pcarlini at suse dot de 2007-10-15 09:14 --- I'm just fixing it ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33773
[Bug middle-end/33777] Crash during a build of zsh
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-10-15 09:15 --- Please attach preprocessed source of rlimits.c -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33777
[Bug libstdc++/33771] FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors)
--- Comment #4 from pcarlini at suse dot de 2007-10-15 09:24 --- No problem, I'm just going ahead. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-15 09:24:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33771
[Bug libstdc++/33771] FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors)
--- Comment #5 from paolo at gcc dot gnu dot org 2007-10-15 09:35 --- Subject: Bug 33771 Author: paolo Date: Mon Oct 15 09:34:49 2007 New Revision: 129313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129313 Log: 2007-10-15 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/33771 PR libstdc++/33773 * testsuite/21_strings/headers/cwchar/macros.cc: Guard test with _GLIBCXX_HAVE_WCHAR_H. * testsuite/21_strings/headers/cwctype/macros.cc: Likewise with _GLIBCXX_HAVE_WCTYPE_H. * testsuite/17_intro/headers/c++200x/all.cc: Guard inclusions of wchar.h and wctype.h. * testsuite/17_intro/headers/c++200x/all_multiple_inclusion.cc: Likewise. * testsuite/17_intro/headers/c++1998/all.cc: Likewise. * testsuite/17_intro/headers/c++1998/all_multiple_inclusion.cc: Likewise. Modified: trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/all.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_multiple_inclusion.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_multiple_inclusion.cc trunk/libstdc++-v3/testsuite/21_strings/headers/cwchar/macros.cc trunk/libstdc++-v3/testsuite/21_strings/headers/cwctype/macros.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33771
[Bug libstdc++/33773] FAIL: 21_strings/headers/cwchar/macros.cc (test for excess errors)
--- Comment #3 from paolo at gcc dot gnu dot org 2007-10-15 09:35 --- Subject: Bug 33773 Author: paolo Date: Mon Oct 15 09:34:49 2007 New Revision: 129313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129313 Log: 2007-10-15 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/33771 PR libstdc++/33773 * testsuite/21_strings/headers/cwchar/macros.cc: Guard test with _GLIBCXX_HAVE_WCHAR_H. * testsuite/21_strings/headers/cwctype/macros.cc: Likewise with _GLIBCXX_HAVE_WCTYPE_H. * testsuite/17_intro/headers/c++200x/all.cc: Guard inclusions of wchar.h and wctype.h. * testsuite/17_intro/headers/c++200x/all_multiple_inclusion.cc: Likewise. * testsuite/17_intro/headers/c++1998/all.cc: Likewise. * testsuite/17_intro/headers/c++1998/all_multiple_inclusion.cc: Likewise. Modified: trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/all.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_multiple_inclusion.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_multiple_inclusion.cc trunk/libstdc++-v3/testsuite/21_strings/headers/cwchar/macros.cc trunk/libstdc++-v3/testsuite/21_strings/headers/cwctype/macros.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33773
[Bug libstdc++/33773] FAIL: 21_strings/headers/cwchar/macros.cc (test for excess errors)
--- Comment #4 from paolo at gcc dot gnu dot org 2007-10-15 09:35 --- Subject: Bug 33773 Author: paolo Date: Mon Oct 15 09:34:56 2007 New Revision: 129314 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129314 Log: 2007-10-15 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/33771 PR libstdc++/33773 * testsuite/21_strings/headers/cwchar/macros.cc: Guard test with _GLIBCXX_HAVE_WCHAR_H. * testsuite/21_strings/headers/cwctype/macros.cc: Likewise with _GLIBCXX_HAVE_WCTYPE_H. * testsuite/17_intro/headers/c++200x/all.cc: Guard inclusions of wchar.h and wctype.h. * testsuite/17_intro/headers/c++200x/all_multiple_inclusion.cc: Likewise. * testsuite/17_intro/headers/c++1998/all.cc: Likewise. * testsuite/17_intro/headers/c++1998/all_multiple_inclusion.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33773
[Bug libstdc++/33771] FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors)
--- Comment #6 from paolo at gcc dot gnu dot org 2007-10-15 09:35 --- Subject: Bug 33771 Author: paolo Date: Mon Oct 15 09:34:56 2007 New Revision: 129314 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129314 Log: 2007-10-15 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/33771 PR libstdc++/33773 * testsuite/21_strings/headers/cwchar/macros.cc: Guard test with _GLIBCXX_HAVE_WCHAR_H. * testsuite/21_strings/headers/cwctype/macros.cc: Likewise with _GLIBCXX_HAVE_WCTYPE_H. * testsuite/17_intro/headers/c++200x/all.cc: Guard inclusions of wchar.h and wctype.h. * testsuite/17_intro/headers/c++200x/all_multiple_inclusion.cc: Likewise. * testsuite/17_intro/headers/c++1998/all.cc: Likewise. * testsuite/17_intro/headers/c++1998/all_multiple_inclusion.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33771
[Bug libstdc++/33773] FAIL: 21_strings/headers/cwchar/macros.cc (test for excess errors)
--- Comment #5 from pcarlini at suse dot de 2007-10-15 09:35 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33773
[Bug libstdc++/33771] FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors)
--- Comment #7 from pcarlini at suse dot de 2007-10-15 09:36 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33771
[Bug c/33778] New: SPU __ea qualifier doesn't get along with some structure
// file t0.c
typedef struct {
float a;
float b;
} foo;
void t() {
foo a = *(__ea foo*)0; // 0 is not problem here
}
$ spu-gcc -Wall -O0 -c t0.c -S
does not produce instruction that calls __cache_fetch.
typedef struct {
float a;
} foo;
struct with 1 member or just float/int type does produce this instruction.
brsl $lr,__cache_fetch
--
Summary: SPU __ea qualifier doesn't get along with some structure
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kojih at jp dot sony dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33778
[Bug c/33778] SPU __ea qualifier doesn't get along with some structure
--- Comment #1 from kojih at jp dot sony dot com 2007-10-15 10:12 --- forgot to write environment. $ spu-gcc -v Using built-in specs. Target: spu Configured with: ../toolchain/gcc/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-shared --disable-threads --disable-checking --with-headers --with-system-zlib --with-newlib --enable-languages=c,c++,fortran --disable-nls --enable-version-specific-runtime-libs --disable-libssp --program-prefix=spu- --target=spuThread model: single gcc version 4.1.1 $ uname -a Linux localhost.localdomain 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:13:52 EDT 2007 ppc64 ppc64 ppc64 GNU/Linux Fedora7 on PS3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33778
[Bug target/33133] [4.3 Regression] ICE in try_ready, at haifa-sched.c:2958 with -O2/-O3
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2007-10-15 10:30 --- Subject: Bug 33133 Author: mkuvyrkov Date: Mon Oct 15 10:30:13 2007 New Revision: 129315 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129315 Log: PR target/33133 * haifa-sched.c (process_insn_forw_deps_be_in_spec): Check if speculation type of insn can be changed before trying to do that. * gcc.c-torture/compile/pr33133.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr33133.c Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33133
[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)
--- Comment #16 from irar at il dot ibm dot com 2007-10-15 10:42 ---
This patch fixes the ICE and doesn't cause regressions in the vectorizer
testsuite:
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 129292)
+++ tree-data-ref.c (working copy)
@@ -571,11 +571,16 @@ split_constant_offset (tree exp, tree *v
if (TREE_CODE (def_stmt) == GIMPLE_MODIFY_STMT)
{
tree def_stmt_rhs = GIMPLE_STMT_OPERAND (def_stmt, 1);
+tree arr = NULL_TREE;
+
+if (TREE_CODE (def_stmt_rhs) == ADDR_EXPR)
+ arr = TREE_OPERAND (def_stmt_rhs, 0);
if (!TREE_SIDE_EFFECTS (def_stmt_rhs)
EXPR_P (def_stmt_rhs)
!REFERENCE_CLASS_P (def_stmt_rhs)
-!get_call_expr_in (def_stmt_rhs))
+!get_call_expr_in (def_stmt_rhs)
+ (!arr || TREE_THIS_NOTRAP (arr)))
{
split_constant_offset (def_stmt_rhs, var0, off0);
var0 = fold_convert (type, var0);
This way we avoid arrays with unknown size.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680
[Bug target/33133] [4.3 Regression] ICE in try_ready, at haifa-sched.c:2958 with -O2/-O3
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2007-10-15 10:43 --- (In reply to comment #4) Confirmed. We see this a lot (building xgl, cups, john, xpdf, metacity, openssl and more). And just with -O2 in our cases. Are these failures fixed now? -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33133
[Bug c/33778] SPU __ea qualifier doesn't get along with some structure
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-15 11:07 --- Hi Hara-san, __ea support has not been contributed to the FSF GCC yet so closing this as invalid. You might want to report this to the 3C bugzilla (which I don't have the address to right now). Ben, I added you as a CC since I know you work on SPU GCC for IBM and was contributing IBM's work for the spu parts that IBM was changing, you might want to add this to the internal spu gcc bug reports. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bje at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33778
[Bug testsuite/33775] Memset
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-15 11:14 --- This code written as a[(char*)b] is valid even C code, in C, d[e] is the same as *(d+e) so d[e] is the same as e[d]. So the code is valid and does the correct thing. There is no bug here. Unless you can explain exactly why you want the change, I am going to close this as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc-bugs at gcc dot gnu dot ||org Component|classpath |testsuite Product|classpath |gcc Version|unspecified |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33775
[Bug tree-optimization/33383] [4.3 Regression] Revision 128092 miscompiles 400.perlbench
--- Comment #13 from jakub at gcc dot gnu dot org 2007-10-15 11:20 ---
To me this looks like aliasing violation in 400.perlbench (and in perl 5.8.8
too, so I'll cite the latter).
#define IVTYPE long/**/
typedef IVTYPE IV;
typedef struct xpviv XPVIV;
typedef size_t STRLEN;
struct xpviv {
char * xpv_pv; /* pointer to malloced string */
STRLEN xpv_cur;/* length of xpv_pv as a C string */
STRLEN xpv_len;/* allocated size */
IV xiv_iv; /* integer value or pv offset */
};
# define STRUCT_OFFSET(s,m) (Size_t)s *)0)-m))
#define STATIC static
# define pTHX_
# define LOCK_SV_MUTEX
# define UNLOCK_SV_MUTEX
extern IV * PL_xiv_root;
In sv.c, we have:
STATIC void
S_del_xiv(pTHX_ XPVIV *p)
{
IV* xiv = (IV*)((char*)(p) + STRUCT_OFFSET(XPVIV, xiv_iv));
LOCK_SV_MUTEX;
*(IV**)xiv = PL_xiv_root;
PL_xiv_root = xiv;
UNLOCK_SV_MUTEX;
}
The problem is when Perl_sv_upgrade function is called, with (sv-sv_flags
0xff) == SVt_IV, mt == SVt_PVNV, ((XPVIV*) (sv)-sv_any)-xiv_iv == 0 and
PL_xiv_root != NULL:
IV iv;
...
switch (SvTYPE(sv)) {
case SVt_NULL:
break;
case SVt_IV:
iv = SvIVX(sv);
del_XIV(SvANY(sv));
if (mt == SVt_NV)
mt = SVt_PVNV;
else if (mt SVt_PVIV)
mt = SVt_PVIV;
break;
...
switch (mt) {
case SVt_PVNV:
SvANY(sv) = new_XPVNV();
SvPV_set(sv, pv);
SvCUR_set(sv, cur);
SvLEN_set(sv, len);
SvIV_set(sv, iv);
SvNV_set(sv, nv);
break;
...
or better preprocessed:
switch (((sv)-sv_flags 0xff)) {
case SVt_NULL:
break;
case SVt_IV:
iv = ((XPVIV*) (sv)-sv_any)-xiv_iv;
S_del_xiv((XPVIV*) (sv)-sv_any);
if (mt == SVt_NV)
mt = SVt_PVNV;
else if (mt SVt_PVIV)
mt = SVt_PVIV;
break;
...
switch (mt) {
...
case SVt_PVNV:
(sv)-sv_any = (void*)S_new_xpvnv();
((XPV*) (sv)-sv_any)-xpv_pv = pv;
((XPV*) (sv)-sv_any)-xpv_cur = cur;
((XPV*) (sv)-sv_any)-xpv_len = len;
((XPVIV*) (sv)-sv_any)-xiv_iv = iv;
((XPVNV*)(sv)-sv_any)-xnv_nv = nv;
break;
when sv.c is compiled with -O2 -fstrict-aliasing, then the
*(IV**)xiv = PL_xiv_root; write isn't considered aliased with the
iv = ((XPVIV*) (sv)-sv_any)-xiv_iv;, because the former accesses the object
as long *, while the latter as long. The difference between -O2
-fstrict-aliasing and -O2 -fno-strict-aliasing compiled sv.c is then that
in this call ((XPVIV*) (sv)-sv_any)-xiv_iv = iv; stores (long) PL_xiv_root
value before entering this function with -fstrict-aliasing and 0 (i.e. what
((XPVIV*) (sv)-sv_any)-xiv_iv contained on function entry) with
-fno-strict-aliasing.
It seems perl is aware of this, but doesn't care to fix it - Configure has
instead:
case $gccversion in
1*) ;;
2.[0-8]*) ;;
?*) echo
echo Checking if your compiler accepts -fno-strict-aliasing 2
1
echo 'int main(void) { return 0; }' gcctest.c
if $cc -O2 -fno-strict-aliasing -o gcctest gcctest.c; then
echo Yes, it does. 21
case $ccflags in
*strict-aliasing*)
echo Leaving current flags $ccflags alone. 2
1
;;
*) dflt=$dflt -fno-strict-aliasing ;;
esac
else
echo Nope, it doesn't, but that's ok. 21
fi
;;
esac
Not sure what is the best way forward with CPU2006 and GCC though (and what are
other compilers doing to pass 400.perlbench). Is it acceptable to add
-fno-strict-aliasing just for this test?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
[Bug tree-optimization/33383] [4.3 Regression] Revision 128092 miscompiles 400.perlbench
--- Comment #14 from jh at suse dot cz 2007-10-15 11:39 ---
Subject: Re: [4.3 Regression] Revision 128092 miscompiles 400.perlbench
when sv.c is compiled with -O2 -fstrict-aliasing, then the
*(IV**)xiv = PL_xiv_root; write isn't considered aliased with the
iv = ((XPVIV*) (sv)-sv_any)-xiv_iv;, because the former accesses the object
Duh, thanks and congratulations for finding this!
It seems perl is aware of this, but doesn't care to fix it - Configure has
instead:
It also might be that perl developers figured out by experimentation
that -fno-strict-aliasing helps, we probably could try to let them know.
case $gccversion in
1*) ;;
2.[0-8]*) ;;
?*) echo
echo Checking if your compiler accepts -fno-strict-aliasing
2
1
echo 'int main(void) { return 0; }' gcctest.c
if $cc -O2 -fno-strict-aliasing -o gcctest gcctest.c; then
echo Yes, it does. 21
case $ccflags in
*strict-aliasing*)
echo Leaving current flags $ccflags alone.
2
1
;;
*) dflt=$dflt -fno-strict-aliasing ;;
esac
else
echo Nope, it doesn't, but that's ok. 21
fi
;;
esac
Not sure what is the best way forward with CPU2006 and GCC though (and what
are
other compilers doing to pass 400.perlbench). Is it acceptable to add
-fno-strict-aliasing just for this test?
This should not be that dificult to fix. Ideally we can convince SPEC to
produce official patch as they did with similar problems with CPU2000?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
[Bug c++/29615] Class can't be friends of itself?
--- Comment #3 from jens-devel at gmx dot de 2007-10-15 12:48 ---
Subject: Class can't be friends of itself?
Hi,
I think gcc should be able to compile something like this.
There is no other way to make a member-variable accessible only from all
objects which are of the same type. Am I wrong?
test.cpp
class A
{
friend class A;
private:
int var_accessible_from_all_A_objects;
};
int main() { return 0; }
/test.cpp
Greetings
Jens
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29615
[Bug c++/33744] [4.1/4.2/4.3 regression] function-style cast and '' not allowed in template argument
-- 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|2007-10-12 15:21:49 |2007-10-15 12:53:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug rtl-optimization/33644] [4.3 Regression] ICE in local_cprop_pass with -ftrapv for crafty
--- Comment #2 from zadeck at naturalbridge dot com 2007-10-15 13:11 --- Subject: Re: [4.3 Regression] ICE in local_cprop_pass with -ftrapv for crafty On Sun, Oct 14, 2007 at 12:29:44PM -0400, Kenneth Zadeck wrote: I have not looked at this bug. I am happy to if you want. I am sure that it will be trivial to modify the pass that moved/created the insn in the middle of the libcall to inherit the LIB_CALL_ID from the previous insn. That is not desirable, if anything in this case the insn should be added before the whole libcall sequence rather than before the insn that actually needs it. Otherwise, useless insns added to the libcall sequences wouldn't be ever DCEd. While it might be easy to modify the instantiate_virtual_regs, there are dozens of other passes that do similar things, so at least for 4.3 it is highly unlikely they will be all modified. Jakub Jakub, i will fix this by moving the insn before the libcall. It may take me a day of so because i am under the weather. But i will do it soon. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33644
[Bug middle-end/33779] New: [4.3 Regression] folds unsigned multiplication == 0 to true
int foo(int i)
{
if (((unsigned)(i + 1)) * 4 == 0)
return 1;
return 0;
}
extern void abort(void);
int main()
{
if (foo(0x3fff) == 0)
abort ();
return 0;
}
This goes wrong in extract_muldiv and is exposed by folding X * C CMP 0 to
X CMP 0 for undefined overflow.
--
Summary: [4.3 Regression] folds unsigned multiplication == 0 to
true
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33779
[Bug libstdc++/33773] FAIL: 21_strings/headers/cwchar/macros.cc (test for excess errors)
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-15 13:20 --- Subject: Re: FAIL: 21_strings/headers/cwchar/macros.cc (test for excess errors) --- Comment #1 from pcarlini at suse dot de 2007-10-15 09:12 --- What does it mean These are defined in hpux11? Sorry, I meant to say the macros are defined in wchar.h in hpux11.11 and later. The macros are not defined in earlier releases (10.X and 11.00). Both 10.X and 11.00 have wchar.h but not wctype.h. That's why I was wondering about providing the defines. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33773
[Bug middle-end/33779] [4.3 Regression] folds unsigned multiplication == 0 to true
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-15 13:24 ---
Another one:
int foo(int i)
{
return ((int)((unsigned)(i + 1) * 4)) / 4;
}
extern void abort(void);
int main()
{
if (foo(0x3fff) == 0)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33779
[Bug middle-end/33779] [4.3 Regression] folds unsigned multiplication == 0 to true
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-15 13:31 ---
whoops, make the testcase in comment #1
int foo(int i)
{
return ((int)((unsigned)(i + 1) * 4)) / 4;
}
extern void abort(void);
int main()
{
if (foo(0x3fff) != 0)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33779
[Bug middle-end/33779] [4.3 Regression] folds unsigned multiplication == 0 to true
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-15 13:32 --- Only the first testcase is a regression (AFAIK), the second one also fails with 2.95. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33779
[Bug libstdc++/33773] FAIL: 21_strings/headers/cwchar/macros.cc (test for excess errors)
--- Comment #8 from paolo at gcc dot gnu dot org 2007-10-15 13:43 --- Subject: Bug 33773 Author: paolo Date: Mon Oct 15 13:43:33 2007 New Revision: 129316 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129316 Log: 2007-10-15 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/33773 (cont) * testsuite/21_strings/headers/cwchar/macros.cc: Guard with _GLIBCXX_USE_WCHAR_T, instead. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/21_strings/headers/cwchar/macros.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33773
[Bug libfortran/33055] Runtime error in INQUIRE unit existance with -fdefault-integer-8
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-10-15 13:56 --- Subject: Bug 33055 Author: jvdelisle Date: Mon Oct 15 13:55:47 2007 New Revision: 129328 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129328 Log: 2007-10-15 Jerry DeLisle [EMAIL PROTECTED] PR fortran/33055 * trans-io.c (create_dummy_iostat): New function to create a unique dummy variable expression to use with IOSTAT. (gfc_trans_inquire): Use the new function to pass unit number error info to run-time library if a regular IOSTAT variable was not given. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33055
[Bug tree-optimization/33383] [4.3 Regression] Revision 128092 miscompiles 400.perlbench
--- Comment #15 from hjl at lucon dot org 2007-10-15 13:58 --- (In reply to comment #14) Subject: Re: [4.3 Regression] Revision 128092 miscompiles 400.perlbench ? This should not be that dificult to fix. Ideally we can convince SPEC to produce official patch as they did with similar problems with CPU2000? Can we come up with a patch to fix perl? I can send it to our SPEC representatives. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
[Bug libfortran/33055] Runtime error in INQUIRE unit existance with -fdefault-integer-8
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-10-15 13:59 --- Subject: Bug 33055 Author: jvdelisle Date: Mon Oct 15 13:59:02 2007 New Revision: 129344 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129344 Log: 2007-10-15 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/33055 * io/inquire.c (inquire_via_unit): If inquiring by unit, check for an error condition from the IOSTAT variable and set EXIST to false if there was a bad unit number. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/inquire.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33055
[Bug libstdc++/33773] FAIL: 21_strings/headers/cwchar/macros.cc (test for excess errors)
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-15 13:28 --- Subject: Re: FAIL: 21_strings/headers/cwchar/macros.cc (test for excess errors) --- Comment #5 from pcarlini at suse dot de 2007-10-15 09:35 --- Fixed. I don't believe the change fixes the failure as the target has wchar.h. However, it doesn't define WCHAR_MAX or WCHAR_MIN. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33773
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #36 from pluto at agmk dot net 2007-10-15 14:04 --- could someone update this patch for 4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug libfortran/33055] Runtime error in INQUIRE unit existance with -fdefault-integer-8
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-10-15 14:04 --- Subject: Bug 33055 Author: jvdelisle Date: Mon Oct 15 14:03:52 2007 New Revision: 129346 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129346 Log: 2007-10-15 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/33055 * gfortran.dg/inquire_11.f90: New test. * gfortan.dg/negative_unit_int8.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/inquire_11.f90 trunk/gcc/testsuite/gfortran.dg/negative_unit_int8.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33055
[Bug libfortran/33055] Runtime error in INQUIRE unit existance with -fdefault-integer-8
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-10-15 14:05 --- Fixed. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33055
[Bug middle-end/33780] New: different results between O3 and O0
The following program: FUNCTION F(r,a,e) REAL*8 :: a(2:15) REAL*8 :: r,f,e f=0 DO i = 2, 15 f = f + a(i)/(r**(i-1)*REAL(i-1,8)) END DO f=f-e END FUNCTION F PROGRAM TEST REAL*8 :: a(2:15)=(/-195.771601327700D0, 15343.7861339500D0, -530864.458651600D0, 10707934.3905800D0, -140099704.789000D0, 1250943273.78500D0, -7795458330.67600D0, 33955897217.3100D0, -101135640744.000D0, 193107995718.700D0, -193440560940.000D0, -4224406093.91800D0, 217192386506.500D0, -157581228915.500D0/) REAL*8 :: r=4.51556282882533D0 REAL*8 :: e=-2.21199635966809471000D0 REAL*8 :: f write(6,*) f(r,a,e) END PROGRAM TEST generates different results with gfortran 4.3.0 at O0 and O3 gfortran -O0 -march=k8 -msse test.f90 ./a.out 0.00 gfortran -O3 -march=k8 -msse test.f90 ./a.out -1.143973804573761E-012 notice that this is without -ffast-math and with sse. gfortran 4.1 gives 0.0 in all cases. I suspect that the reason is that __powidf2 is replaced by inline code at -O3 that gives slightly different results. If this is expected behavior, maybe this substitution should be guarded by -ffast-math ? -- Summary: different results between O3 and O0 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk 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=33780
[Bug tree-optimization/33619] [4.1/4.2/4.3 Regression] TER breaks some inline-asm code (again)
--- Comment #7 from jakub at gcc dot gnu dot org 2007-10-15 15:14 --- Subject: Bug 33619 Author: jakub Date: Mon Oct 15 15:14:46 2007 New Revision: 129350 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129350 Log: PR tree-optimization/33619 * tree-ssa-ter.c (is_replaceable_p): Return false for all calls. * gcc.dg/pr33619.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr33619.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33619
[Bug middle-end/33780] different results between O3 and O0
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-15 15:01 ---
Confirmed. It changes for me -O2 vs. -O2 -fpeel-loops which causes the loop
in f to be completely unrolled (which at the first sight doesn't look wrong).
And we expand __powidf2 inline because the exponent is now a constant for all
calls. This indeed might explain the difference as __powidf2 is implemented
as
TYPE
NAME (TYPE x, int m)
{
unsigned int n = m 0 ? -m : m;
TYPE y = n % 2 ? x : 1;
while (n = 1)
{
x = x * x;
if (n % 2)
y = y * x;
}
return m 0 ? 1/y : y;
}
while we expand a constant integral power to an optimal (as of the count of
multiplications / additions) series of multiplications and additions.
As Fortran allows open-coding of integral powers this is not a bug. But
I'll leave final closing as INVALID to more fortran-knowing people.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-10-15 15:01:08
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33780
[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2007-10-15
15:02 ---
Subject: Re: [4.3 Regression] ICE when compilling elbg.c from ffmpeg
(vectorizer)
This patch fixes the ICE and doesn't cause regressions in the vectorizer
testsuite:
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 129292)
+++ tree-data-ref.c (working copy)
@@ -571,11 +571,16 @@ split_constant_offset (tree exp, tree *v
if (TREE_CODE (def_stmt) == GIMPLE_MODIFY_STMT)
{
tree def_stmt_rhs = GIMPLE_STMT_OPERAND (def_stmt, 1);
+tree arr = NULL_TREE;
+
+if (TREE_CODE (def_stmt_rhs) == ADDR_EXPR)
+ arr = TREE_OPERAND (def_stmt_rhs, 0);
if (!TREE_SIDE_EFFECTS (def_stmt_rhs)
EXPR_P (def_stmt_rhs)
!REFERENCE_CLASS_P (def_stmt_rhs)
-!get_call_expr_in (def_stmt_rhs))
+!get_call_expr_in (def_stmt_rhs)
+ (!arr || TREE_THIS_NOTRAP (arr)))
you would have to be more careful here, as arr does not have to be
array_ref, so applying TREE_THIS_NOTRAP to it may cause ICEs.
Anyway, this change does not make sense to me, I need to check
what this PR is about, but there is no reason for split_constant_offset
to special-case ADDR_EXPR's this way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680
[Bug middle-end/33780] different results between O3 and O0
--- Comment #2 from jv244 at cam dot ac dot uk 2007-10-15 15:30 --- (In reply to comment #1) As Fortran allows open-coding of integral powers this is not a bug. But I'll leave final closing as INVALID to more fortran-knowing people. I agree that Fortran-wise this is not a bug. However, gcc tends to do some of the things that Fortran allows by default (x/y - x*(1/y) ; x+Y+z - (x=z)+y ; ..) only at -ffast-math. AFAIK, this seems to be the only optimisation in gcc that causes numerical results with CP2K to change going from -O0 to -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33780
[Bug bootstrap/33781] New: [4.3 Regression] Arg list too long building libgcc.a
The recent addition of a large number of libgcc objects (for fixed point arithmetic and other things) now breaks bootstrap on IRIX. The problem is that the command line in libgcc/Makefile.in, approx line 697 reads as: $(AR_CREATE_FOR_TARGET) $@ $$objects which doesn't defend against $objects being a huge list. Currently on 32-bit IRIX this is 1762 files. Indeed, even typing ls *.o in the directory mips-sgi-irix6.5/32/libgcc, returns -bash: /usr/bin/ls: Arg list too long! Alas I'm not a wizard in build machinery, but I suspect that all that's required is a one or two line change, perhaps to use libtool to create the archive, which contains logic to circumvent these host command line limits. I believe this is what we currently do for libgcj and other large libraries. Many thanks in advance to the kind build maintainer or volunteer who looks into the problem. I'm happy to test patches on my dusty MIPS/IRIX box. -- Summary: [4.3 Regression] Arg list too long building libgcc.a Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roger at eyesopen dot com GCC host triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug c/33782] New: [4.3 Regression] FAIL: gcc.c-torture/compile/limits-stringlit.c (test for excess errors)
This started happening between revision 128772 (good) and 128824 (bad): .../gcc/testsuite/gcc.c-torture/compile/limits-stringlit.c:10: error: size of array is too large This appears to happen on all targets with 16-bit int. Revision 128811 suspected. -- Summary: [4.3 Regression] FAIL: gcc.c-torture/compile/limits- stringlit.c (test for excess errors) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at gcc dot gnu dot org GCC target triplet: m32c-unknown-elf avr-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33782
[Bug middle-end/33780] different results between O3 and O0
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-15 15:51 --- that causes numerical results with CP2K to change going from -O0 to -O3. If you do expect that optimization optimizes your computation, you should expect some change of the numerical results, so put some tolerance in the comparisons. How small can be the tolerance depends on your problem. I have modified your code to compute the polynomial in three different ways (yours, plus two others, the third one being the recommended one for numerical stability, if I did not make some errors): FUNCTION F(r,a,e,pf,qf) REAL*8 :: a(2:15) REAL*8 :: r,f,e, pr,pf,qf,rr f=0 pf=0 pr=r rr=1.0d0/r DO i = 2, 15 f = f + a(i)/(r**(i-1)*REAL(i-1,8)) pf = pf + a(i)/(pr*REAL(i-1,8)) pr = r*pr END DO f=f-e pf=pf-e qf=a(15)/REAL(14,8) do i = 14, 2, -1 qf=rr*qf+a(i)/REAL(i-1,8) end do qf=rr*qf-e END FUNCTION F PROGRAM TEST REAL*8 :: a(2:15)=(/-195.771601327700D0, 15343.7861339500D0, -530864.458651600D0, 10707934.3905800D0, -140099704.789000D0, 1250943273.78500D0, -7795458330.67600D0, 33955897217.3100D0, -101135640744.000D0, 193107995718.700D0, -193440560940.000D0, -4224406093.91800D0, 217192386506.500D0, -157581228915.500D0/) REAL*8 :: r=4.51556282882533D0 REAL*8 :: e=-2.21199635966809471000D0 REAL*8 :: pf, qf REAL*8 :: f write(6,*) f(r,a,e,pf,qf) write(6,*) pf, qf END PROGRAM TEST [karma] f90/bug% gfc pr33780_red.f90 [karma] f90/bug% a.out 0. 1.36957112317759311E-012 7.66053886991358013E-012 [karma] f90/bug% gfc -O3 pr33780_red.f90 [karma] f90/bug% a.out -1.14397380457376130E-012 1.36957112317759311E-012 1.04861186749364478E-011 So for your problem the tolerance should be ~1.0E-11, and since pf and qf don't use powers, this is not a question of inlining, but how the operations are shuffled to optimize your computation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33780
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #12 from rsandifo at gcc dot gnu dot org 2007-10-15 16:23 --- As a status update: I've got a patch I'm reasonably happy with, tested against 4.2 and trunk. The trunk version depends on some uncommitted patches, which in turn depend on a system.h patch, so I'll hold off applying the patches for this bug until the earlier ones are in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug middle-end/33706] gcc_assert failure in verify_eh_edges
--- Comment #6 from aoliva at gcc dot gnu dot org 2007-10-15 17:05 --- Subject: Bug 33706 Author: aoliva Date: Mon Oct 15 17:05:19 2007 New Revision: 129355 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129355 Log: gcc/ChangeLog: PR middle-end/33706 * tree-inline.c (copy_bb): Use bsi_replace to replace a __builtin_va_arg_pack-containing call stmt. gcc/testsuite/ChangeLog: PR middle-end/33706 * gcc.dg/va-arg-pack-2.c: New. Added: trunk/gcc/testsuite/gcc.dg/va-arg-pack-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33706
[Bug middle-end/33706] gcc_assert failure in verify_eh_edges
--- Comment #7 from aoliva at gcc dot gnu dot org 2007-10-15 17:07 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33706
[Bug tree-optimization/33735] [4.3 Regression] verify_stmts failed: missing PHI def
--- Comment #5 from aoliva at gcc dot gnu dot org 2007-10-15 17:07 --- Subject: Bug 33735 Author: aoliva Date: Mon Oct 15 17:07:20 2007 New Revision: 129356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129356 Log: gcc/ChangeLog: PR tree-optimization/33735 PR tree-optimization/33572 * tree-inline.c (update_ssa_across_abnormal_edges): Revert 2007-10-09's change. * except.c (duplicate_eh_regions): Don't look for prev_try beyond ERT_ALLOWED_EXCEPTIONS with an empty list. gcc/testsuite/ChangeLog: PR tree-optimization/33735 * g++.dg/torture/pr33735.C: New. Added: trunk/gcc/testsuite/g++.dg/torture/pr33735.C Modified: trunk/gcc/ChangeLog trunk/gcc/except.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33735
[Bug tree-optimization/33572] [4.3 Regression] wrong code with -O
--- Comment #22 from aoliva at gcc dot gnu dot org 2007-10-15 17:07 --- Subject: Bug 33572 Author: aoliva Date: Mon Oct 15 17:07:20 2007 New Revision: 129356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129356 Log: gcc/ChangeLog: PR tree-optimization/33735 PR tree-optimization/33572 * tree-inline.c (update_ssa_across_abnormal_edges): Revert 2007-10-09's change. * except.c (duplicate_eh_regions): Don't look for prev_try beyond ERT_ALLOWED_EXCEPTIONS with an empty list. gcc/testsuite/ChangeLog: PR tree-optimization/33735 * g++.dg/torture/pr33735.C: New. Added: trunk/gcc/testsuite/g++.dg/torture/pr33735.C Modified: trunk/gcc/ChangeLog trunk/gcc/except.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33572
[Bug middle-end/25445] -fpic/-fPIC failure in gcc.dg/tree-ssa/wholeprogram-1.c
--- Comment #3 from froydnj at gcc dot gnu dot org 2007-10-15 17:30 --- Marking as fixed. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25445
[Bug middle-end/25446] -fpic/-fPIC failure in gcc.dg/vect/vect-ifcvt-9.c
--- Comment #3 from froydnj at gcc dot gnu dot org 2007-10-15 17:31 --- Marking as fixed. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25446
[Bug tree-optimization/33784] New: Disabled -fipa-type-escape
-fipa-type-escape needs to be reenabled when the problems with that pass are fixed and on sufficient number of testcases we can test that the pass actually performs the optimizations it is supposed to do. -- Summary: Disabled -fipa-type-escape Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu BugsThisDependsOn: 33136 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33784
[Bug tree-optimization/33784] Disabled -fipa-type-escape
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-15 18:14 --- Created an attachment (id=14353) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14353action=view) gcc43-pr33784-test.patch Some tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33784
[Bug target/33785] New: TARGET_C99_FUNCTIONS default wrong in tm.texi
tm.texi has:
@defmac TARGET_C99_FUNCTIONS
When this macro is nonzero, GCC will implicitly optimize @code{sin} calls into
@code{sinf} and similarly for other functions defined by C99 standard. The
default is nonzero that should be proper value for most modern systems, however
number of existing systems lacks support for these functions in the runtime so
they needs this macro to be redefined to 0.
@end defmac
but defaults.h has:
gcc/defaults.h:825:#ifndef TARGET_C99_FUNCTIONS
gcc/defaults.h:826:#define TARGET_C99_FUNCTIONS 0
(revision 127595)
--
Summary: TARGET_C99_FUNCTIONS default wrong in tm.texi
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kai-gcc-bugs at khms dot westfalen dot de
GCC build triplet: n/a
GCC host triplet: n/a
GCC target triplet: n/a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33785
[Bug libfortran/31726] minloc/maxloc: wrong results with empty array (F2003 only)
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-10-15 18:23 --- Subject: Bug 31726 Author: tkoenig Date: Mon Oct 15 18:23:39 2007 New Revision: 129365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129365 Log: 2007-10-25 Thomas Koenig [EMAIL PROTECTED] Paul Thomas [EMAIL PROTECTED] PR fortran/32298 PR fortran/31726 PR fortran/33354 Backport from trunk * trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): Calculate the offset between the loop counter and the position as defined. Add the offset within the loop so that the mask acts correctly. Do not advance the location on the basis that it is zero. 2007-10-15 Thomas Koenig [EMAIL PROTECTED] PR fortran/33354 * gfortran.dg/minmaxloc_4.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/minmaxloc_4.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31726
[Bug fortran/32298] MINLOC / MAXLOC: off-by one for PARAMETER arrays
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-10-15 18:23 --- Subject: Bug 32298 Author: tkoenig Date: Mon Oct 15 18:23:39 2007 New Revision: 129365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129365 Log: 2007-10-25 Thomas Koenig [EMAIL PROTECTED] Paul Thomas [EMAIL PROTECTED] PR fortran/32298 PR fortran/31726 PR fortran/33354 Backport from trunk * trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): Calculate the offset between the loop counter and the position as defined. Add the offset within the loop so that the mask acts correctly. Do not advance the location on the basis that it is zero. 2007-10-15 Thomas Koenig [EMAIL PROTECTED] PR fortran/33354 * gfortran.dg/minmaxloc_4.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/minmaxloc_4.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32298
[Bug fortran/33354] [4.2 only] MINLOC in combination with SUM gives wrong result
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-10-15 18:24 --- Fixed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.3.0 |4.3.0 4.2.3 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33354
[Bug tree-optimization/33784] Disabled -fipa-type-escape
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-15 18:26 --- Created an attachment (id=14354) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14354action=view) gcc43-pr33784.patch Partial patch which needs finishing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33784
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #30 from jakub at gcc dot gnu dot org 2007-10-15 18:30 --- Subject: Bug 33136 Author: jakub Date: Mon Oct 15 18:29:54 2007 New Revision: 129366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129366 Log: PR tree-optimization/33136 * opts.c (decode_options): Don't enable flag_ipa_type_escape. * gcc.c-torture/execute/20070824-1.c: New test. * gcc.dg/pr33136-1.c: New test. * gcc.dg/pr33136-2.c: New test. * gcc.dg/pr33136-3.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20070824-1.c trunk/gcc/testsuite/gcc.dg/pr33136-1.c trunk/gcc/testsuite/gcc.dg/pr33136-2.c trunk/gcc/testsuite/gcc.dg/pr33136-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug c++/33786] C data and static const data members mangled the same
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-15 18:31 --- On the trunk, I get the following error: t.cc:5: error: previous declaration of 'const int N::S::foobar' with 'C++' linkage t.cc:6: error: conflicts with new declaration with 'C' linkage -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33786
[Bug tree-optimization/33619] [4.1/4.2 Regression] TER breaks some inline-asm code (again)
--- Comment #8 from jakub at gcc dot gnu dot org 2007-10-15 18:49 --- Fixed so far on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression] TER|[4.1/4.2 Regression] TER |breaks some inline-asm code |breaks some inline-asm code |(again) |(again) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33619
[Bug c/33787] New: remove globals from c-format.c
This patch moves some globals in c-format.c into a structure. It was bootstrapped and regtested on x86 FC 6 2007-10-12 Tom Tromey [EMAIL PROTECTED] * c-format.c (dollar_argument_info): New struct. (dollar_arguments_used, dollar_arguments_pointer_p, dollar_arguments_alloc, dollar_arguments_count, dollar_first_arg_num, dollar_max_arg_used, dollar_format_warned): Remove. (init_dollar_format_checking): Add 'state' argument. (maybe_read_dollar_number): Likewise. (finish_dollar_format_checking): Likewise. (check_format_info_inner): Likewise. Renamed from check_format_info_main. (check_format_info_main): New function. -- Summary: remove globals from c-format.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org OtherBugsDependingO 33702 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33787
[Bug c/33787] remove globals from c-format.c
--- Comment #1 from tromey at gcc dot gnu dot org 2007-10-15 19:59 --- Created an attachment (id=14355) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14355action=view) remove globals from c-format.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33787
[Bug fortran/32600] [ISO Bind C] C_ASSOCIATED/C_F_POINTER w/o SHAPE should not be library functions
--- Comment #12 from burnus at gcc dot gnu dot org 2007-10-15 19:59 --- Subject: Bug 32600 Author: burnus Date: Mon Oct 15 19:58:55 2007 New Revision: 129367 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129367 Log: 2007-10-15 Christopher D. Rickett [EMAIL PROTECTED] PR fortran/32600 * trans-expr.c (gfc_conv_function_call): Generate code to inline c_associated. * symbol.c (get_iso_c_sym): Preserve from_intmod and * intmod_sym_id attributes in the resolved symbol. * resolve.c (gfc_iso_c_sub_interface): Remove dead code. 2007-10-15 Christopher D. Rickett [EMAIL PROTECTED] PR fortran/32600 * libgfortran/intrinsics/iso_c_binding.c: Remove c_associated_1 and c_associated_2. * libgfortran/intrinsics/iso_c_binding.h: Ditto. * libgfortran/gfortran.map: Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-expr.c trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/iso_c_binding.c trunk/libgfortran/intrinsics/iso_c_binding.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32600
[Bug fortran/32600] [ISO Bind C] C_F_POINTER w/o SHAPE should not be a library function
--- Comment #13 from burnus at gcc dot gnu dot org 2007-10-15 20:00 --- Last missing part: C_F_POINTER() in the absence of SHAPE should be in the front end and not a library call. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|[ISO Bind C]|[ISO Bind C] C_F_POINTER w/o |C_ASSOCIATED/C_F_POINTER w/o|SHAPE should not be a |SHAPE should not be library |library function |functions | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32600
[Bug ada/33788] New: GNAT bug box in expand_expr_addr_expr_1, at expr.c:6862
Also tried this with the 20071005 snapshot, same result: $ gcc -c -v -g mac6dw.adb Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../SOURCES/gcc/configure --prefix=/opt/gcc4 --enable-debug --enable-languages=c,ada,c++ Thread model: posix gcc version 4.3.0 20070929 (experimental) (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-g' '-mtune=generic' /opt/gcc4/libexec/gcc/i686-pc-linux-gnu/4.3.0/gnat1 -quiet -dumpbase mac6dw.adb -g -mtune=generic mac6dw.adb -o /tmp/cc3KSBQs.s +===GNAT BUG DETECTED==+ | 4.3.0 20070929 (experimental) (i686-pc-linux-gnu) GCC error: | | in expand_expr_addr_expr_1, at expr.c:6862 | | Error detected around mac6dw.adb:11 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. mac6dw.adb mac6dw.ads mcc.ads mcc-gui.ads peer.ads tcl.ads cargv.ads chelper.ads tcl-ada.ads mcc-gui-widget.ads mcc-gui-container.ads mcc-gui-widget-text_entry.ads p_portable.ads corba.ads isf_dbase.ads mdlp_messages.ads p_spare.ads basic_isf_types.ads p_gedef.ads l16_data_types.ads l16_ada_types.ads l16_data_2_types.ads l16_if_types.ads compilation abandoned -- Summary: GNAT bug box in expand_expr_addr_expr_1, at expr.c:6862 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oliver dot kellogg at eads dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33788
[Bug ada/33788] GNAT bug box in expand_expr_addr_expr_1, at expr.c:6862
--- Comment #1 from oliver dot kellogg at eads dot com 2007-10-15 20:41 --- Created an attachment (id=14356) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14356action=view) source files for reproducing the compiler bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33788
[Bug target/30271] -mstrict-align can an extra for struct agrument passing
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-15 21:36 --- Note comment #1 compiles to: srdi 0,3,32 std 3,48(1) add 3,3,0 extsw 3,3 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
[Bug target/30271] -mstrict-align can an extra for struct agrument passing
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |Kenneth dot Zadeck at |dot org |NaturalBridge dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
[Bug java/33789] New: gij crashes when sending serialized objects through a pipe
I can crash gij when I read multiple serialized objects (type does not matter)
from a PipedInputStream. You can reproduce the bug with the following small
example:
public class Test {
public static void main(String[] args) throws Throwable {
java.io.PipedOutputStream mout = new java.io.PipedOutputStream();
new Reader(new java.io.PipedInputStream(mout)).start();
java.io.ObjectOutputStream os = new java.io.ObjectOutputStream(mout);
for (int i = 0; i 1000; ++i)
os.writeObject(new Integer(1));
}
static class Reader extends Thread {
java.io.PipedInputStream pin;
Reader(java.io.PipedInputStream in) {
pin = in;
}
public void run() {
try {
java.io.ObjectInputStream is =
new java.io.ObjectInputStream(pin);
for (int i = 0; i 1000; ++i)
is.readObject();
} catch (Exception t) {
System.err.println(Exception: + t);
System.exit(1);
}
}
}
}
It does not matter whether you compile this with gcj or the Sun Java compiler
thus the compiler is obviously not the problem.
Running this in gij with
gij Test
leads to a random exception. Running the same code in the Sun JVM does not
cause any problems.
This is tested with the current SVN tree (trunk revision 129368) and with
several released versions as shipped with various Linux distributions (tested
on Redhat/Fedora and SUSE).
--
Summary: gij crashes when sending serialized objects through a
pipe
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rschiele at gmail dot com
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=33789
[Bug rtl-optimization/33790] New: postreload can handle the case where the memory locations use different modes
Take the following testcase (either on spu-elf or powerpc-linux-gnu with
-maltivec):
#define vector __attribute__((__vector_size__(16) ))
typedef vector float vec_float4;
typedef struct {
vec_float4 data;
} VecFloat4;
typedef struct {
vec_float4 a;
vec_float4 b;
} VecFloat4x2;
VecFloat4 test1(VecFloat4 a, VecFloat4 b)
{
a.data = a.data+b.data;
return a;
}
VecFloat4x2 test2(VecFloat4x2 data)
{
data.a = data.a+data.a;
data.b = data.b+data.b;
return data;
}
- cut -
Right now we do (for spu-elf, it is a similar issue for PPC):
_Z5test211VecFloat4x2:
hbr .L5,$lr
stqd$sp,-128($sp)
ai $sp,$sp,-128
stqd$3,64($sp)
stqd$4,80($sp)
lqd $5,80($sp)
lqd $4,64($sp)
fa $2,$5,$5
fa $3,$4,$4
stqd$2,48($sp)
stqd$3,32($sp)
lqd $4,48($sp)
lqd $3,32($sp)
ai $sp,$sp,128
.L5:
bi $lr
cut
With the patch which I will attach, we get:
_Z5test211VecFloat4x2:
fa $2,$3,$3
hbr .L5,$lr
stqd$sp,-128($sp)
ai $sp,$sp,-128
nop 127
stqd$3,64($sp)
fa $3,$4,$4
stqd$4,80($sp)
nop 127
stqd$2,32($sp)
ori $4,$3,0
stqd$3,48($sp)
ori $3,$2,0
ai $sp,$sp,128
.L5:
bi $lr
--- cut --
Notice how the loads are gone.
Note dse could do the same.
--
Summary: postreload can handle the case where the memory
locations use different modes
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33790
[Bug rtl-optimization/33790] postreload can handle the case where the memory locations use different modes
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-16 01:37 --- Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-16 01:37:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33790
[Bug rtl-optimization/33790] postreload can handle the case where the memory locations use different modes
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-16 01:39 --- Created an attachment (id=14357) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14357action=view) Patch This patch has been tested on powerpc64-linux-gnu with no regressions and also test for spu-elf with no regressions. I have not looked into the code size differences though but it should just decrease them instead of increase them as we change a load to a move which then maybe register rename can rename registers around to get one less register usage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33790
[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers
--- Comment #4 from jv244 at cam dot ac dot uk 2007-10-16 04:32 --- (In reply to comment #2) Resolution of this bug requires the PROCEDURE POINTER feature from Fortran 2003. Janus Weil, a Google SoC participant, is working on this feature. SoC is over, I assume this has been put on ice ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32580
[Bug target/33791] New: x86 out of registers ICE with -fschedule-insns -march=core2
/usr/local/gcc43/bin/gcc -vUsing built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: ../gcc/configure --prefix=/usr/local/gcc43 --with-arch=nocona
--with-tune=nocona --with-gmp=/sw --with-system-zlib
--enable-languages=c,c++,objc,obj-c++
Thread model: posix
gcc version 4.3.0 20071015 (experimental) (GCC)
/usr/local/gcc43/bin/gcc -O1 -fschedule-insns -march=core2 -S
gcc-sched-ice-32.i
gcc-sched-ice-32.i: In function 'decode_init':
gcc-sched-ice-32.i:177: warning: assignment from incompatible pointer type
gcc-sched-ice-32.i: In function 'decode_nal_units':
gcc-sched-ice-32.i:332: warning: assignment from incompatible pointer type
gcc-sched-ice-32.i: In function 'hl_decode_mb_internal':
gcc-sched-ice-32.i:275: error: unable to find a register to spill in class
'GENERAL_REGS'
gcc-sched-ice-32.i:275: error: this is the insn:
(insn 222 221 232 26 gcc-sched-ice-32.i:183 (set (mem:DI (plus:SI (reg:SI 170)
(reg/f:SI 169 [ variable.top_borders ])) [0 S8 A64])
(reg:DI 172)) 88 {*movdi_2} (expr_list:REG_DEAD (reg:DI 172)
(expr_list:REG_DEAD (reg:SI 170)
(expr_list:REG_DEAD (reg/f:SI 169 [ variable.top_borders ])
(nil)
gcc-sched-ice-32.i:275: internal compiler error: in spill_failure, at
reload1.c:2001
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Delta-reduced so warnings don't mean anything.
The original (large) source has variants on the same error (different insns)
with and without -m64/no-pic/omit-frame-pointer.
--
Summary: x86 out of registers ICE with -fschedule-insns -
march=core2
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
GCC build triplet: i386-apple-darwin8.10.1
GCC host triplet: i386-apple-darwin8.10.1
GCC target triplet: i386-apple-darwin8.10.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33791
