[Bug c/36614] New: incorrect warning: array subscript is above array bounds
In some circumstances gcc 4.3.1 and later give the above warning incorrectly.
I have tried this with:
gcc (Debian 4.3.1-2) 4.3.1 on x86_64 (This is the compiler in current Debian
unstable)
gcc (GCC) 4.4.0 20080624 (experimental) [trunk revision 137057] on PowerPC -
this was built with --disable-bootstrap --enable-languages=c)
The .i version of my test program is as follows:
# 1 arrtest.c
# 1 built-in
# 1 command-line
# 1 arrtest.c
struct pt_regs {
unsigned long gpr[32];
unsigned long nip;
unsigned long msr;
unsigned long orig_gpr3;
unsigned long ctr;
unsigned long link;
unsigned long xer;
unsigned long ccr;
unsigned long softe;
unsigned long trap;
unsigned long dar;
unsigned long dsisr;
unsigned long result;
};
void restore_sigcontext(struct pt_regs *regs)
{
unsigned long *gregs = (unsigned long *)regs;
int i;
for (i = 31; i = 43; i++)
gregs[i] = 1;
for (i = 32; i = 43; i++)
gregs[i] = 1;
for (i = 31; i = 60; i++)
gregs[i] = 1;
}
I compiled this with gcc -Wall -O2 -c arrtest.c and get the warning for the
seond gregs[i] = 1; but not either of the others. This is a cut down from a
file in the current Linux kernel PowerPC arch code.
Compiler output:
arrtest.c: In function ârestore_sigcontextâ:
arrtest.c:29: warning: array subscript is above array bounds
--
Summary: incorrect warning: array subscript is above array
bounds
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at rothwell dot id dot au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36614
[Bug middle-end/36614] incorrect warning: array subscript is above array bounds
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-24 07:14 --- I think this is undefined code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36614
[Bug target/36584] [4.3/4.4 Regression] Stack is not aligned correctly in recursive function
--- Comment #5 from uros at gcc dot gnu dot org 2008-06-24 07:59 --- Subject: Bug 36584 Author: uros Date: Tue Jun 24 07:58:17 2008 New Revision: 137059 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137059 Log: PR middle-end/36584 * calls.c (expand_call): Increase alignment for recursive functions. testsuite/ChangeLog: PR middle-end/36584 * testsuite/gcc.dg/pr36584.c: New test. * testsuite/gcc.target/i386/local2.c: Remove invalid test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr36584.c - copied, changed from r137045, trunk/gcc/testsuite/gcc.dg/pr36584.c Removed: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/local2.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/calls.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36584
[Bug target/36584] [4.3/4.4 Regression] Stack is not aligned correctly in recursive function
--- Comment #6 from ubizjak at gmail dot com 2008-06-24 08:02 --- Fixed for mainline and 4.3 branch. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36584
[Bug target/27682] float to int conversion doesn't raise invalid exception
--- Comment #8 from aldot at gcc dot gnu dot org 2008-06-24 08:22 --- It looks like several improvements were installed since then. Can somebody perhaps retry with the 4.3 branch and trunk? -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
[Bug target/36615] New: gcc-4.3.1 fails to compile linux kernel sk_stream_wait_connect()
Compiling linux kernel 2.6.25.7 with gcc cross compiler for cris 4.3.1 produces internal compiler error in net/core/stream.c sk_stream_wait_connect(). -- Summary: gcc-4.3.1 fails to compile linux kernel sk_stream_wait_connect() Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hinko dot kocevar at cetrtapot dot si GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: cris-linux-uclibc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36615
[Bug target/36615] gcc-4.3.1 fails to compile linux kernel sk_stream_wait_connect()
--- Comment #1 from hinko dot kocevar at cetrtapot dot si 2008-06-24 08:39 --- Created an attachment (id=15808) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15808action=view) preprocessed source that caused the internal compiler error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36615
[Bug target/36615] gcc-4.3.1 fails to compile linux kernel sk_stream_wait_connect()
--- Comment #2 from hinko dot kocevar at cetrtapot dot si 2008-06-24 08:41
---
[EMAIL PROTECTED] /work/stage/git.br/project_build_cris/uclibc/linux-2.6.25.7 $
/work/stage/git.br/build_cris/staging_dir/usr/bin/cris-linux-uclibc-gcc
-Wp,-MD,net/core/.stream.o.d -nostdinc -isystem
/work/stage/git.br/build_cris/staging_dir/usr/bin/../lib/gcc/cris-linux-uclibc/4.3.1/include
-D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Os -fno-stack-protector -mlinux
-march=v10 -pipe -Iinclude/asm/arch/mach -Iinclude/asm/arch
-fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign
--sysroot=/work/stage/git.br/build_cris/staging_dir/ -isysroot
/work/stage/git.br/build_cris/staging_dir -I=/usr/include -Os -pipe
-I/work/stage/git.br/build_cris/staging_dir/usr/include -mtune=v10 -march=v10
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(stream)
-DKBUILD_MODNAME=KBUILD_STR(stream) -c -o net/core/stream.o net/core/stream.c
(const_int -13 [0xfff3])
net/core/stream.c: In function 'sk_stream_wait_connect':
net/core/stream.c:78: internal compiler error: output_operand: invalid operand
for 'p' modifier
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
{standard input}: Assembler messages:
{standard input}:488: Warning: partial line at end of file ignored
[EMAIL PROTECTED] /work/stage/git.br/project_build_cris/uclibc/linux-2.6.25.7 $
/work/stage/git.br/build_cris/staging_dir/usr/bin/cris-linux-uclibc-gcc
--version
cris-linux-uclibc-gcc (GCC) 4.3.1
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36615
[Bug libstdc++/36616] New: Open issues from a test run
The tool generation worked by the following command on my openSUSE 11.0 system with the configuration parameter --enable-languages=c,c++,fortran,java,objc,obj-c++,treelang. [EMAIL PROTECTED]:~/Projekte/GNU/GCC/erzeugt/4.3.1/Auswahl date echo 'erzeugen...' make -j6 Bauprotokoll.txt 21 date echo 'prüfen...' make check Prüfprotokoll.txt 2 Prüfprotokoll_Fehlerausgabe.txt date The log contains the following. === libstdc++ tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/elfring/Projekte/GNU/GCC/Quellen/4.3.1/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/elfring/Projekte/GNU/GCC/Quellen/4.3.1/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ... Running /home/elfring/Projekte/GNU/GCC/Quellen/4.3.1/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 22_locale/money_put/put/char/9780-3.cc execution test FAIL: 22_locale/time_put/put/char/4.cc execution test FAIL: 22_locale/time_put/put/char/wrapped_env.cc execution test FAIL: 22_locale/time_put/put/char/wrapped_locale.cc execution test FAIL: 22_locale/time_put/put/wchar_t/4.cc execution test FAIL: 22_locale/time_put/put/wchar_t/wrapped_env.cc execution test FAIL: 22_locale/time_put/put/wchar_t/wrapped_locale.cc execution test XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) === libstdc++ Summary === # of expected passes5564 # of unexpected failures7 # of unexpected successes 1 # of expected failures 59 # of unsupported tests 10 The error log contains the following. All fixinclude tests pass WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator WARNING: Could not compile g++.dg/compat/struct-layout-1 generator WARNING: Could not compile objc.dg/gnu-encoding/struct-layout-encoding-1 generator WARNING: obj-c++.dg/lookup-2.mm compilation failed to produce executable WARNING: obj-c++.dg/try-catch-2.mm compilation failed to produce executable WARNING: obj-c++.dg/try-catch-9.mm compilation failed to produce executable mkdir: kann Verzeichnis testsuite/treelang nicht anlegen: Die Datei existiert bereits make[2]: [treelang.check] Fehler 1 (ignoriert) make[4]: *** [check-DEJAGNU] Fehler 1 make[3]: *** [check-am] Fehler 2 make[2]: *** [check-recursive] Fehler 1 make[1]: *** [check-target-libstdc++-v3] Fehler 2 make: *** [do-check] Fehler 2 -- Summary: Open issues from a test run Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Markus dot Elfring at web dot de 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=36616
[Bug target/36615] gcc-4.3.1 fails to compile linux kernel sk_stream_wait_connect()
--- Comment #3 from hinko dot kocevar at cetrtapot dot si 2008-06-24 09:03 --- I can NOT reproduce the error with i686 toolchain. [EMAIL PROTECTED] /work/stage/git.br/project_build_i686/uclibc/linux-2.6.25.7 $ /work/stage/git.br/build_i686/staging_dir/usr/bin/i686-linux-uclibc-gcc --version i686-linux-uclibc-gcc (GCC) 4.3.1 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36615
[Bug tree-optimization/36504] [4.3/4.4 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||06/msg01479.html Status|NEW |ASSIGNED Last reconfirmed|2008-06-12 09:29:19 |2008-06-24 09:05:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
[Bug rtl-optimization/36419] [4.1/4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||06/msg01305.html Status|NEW |ASSIGNED Last reconfirmed|2008-06-03 12:26:37 |2008-06-24 09:08:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug debug/36617] New: Debug info for OpenMP code is almost non-existent
While we have VAR_DECLs with DECL_VALUE_EXPR pointing to where various shared etc. vars really live, those don't make it into the debug info at all, as the newly created function has just one BLOCK with all the vars and that doesn't have TREE_USED set on it. A quick hack: --- omp-low.c.jj4 2008-06-20 00:27:49.0 +0200 +++ omp-low.c 2008-06-23 22:21:46.0 +0200 @@ -3251,6 +3251,7 @@ expand_omp_taskreg (struct omp_region *r block = DECL_INITIAL (child_fn); BLOCK_VARS (block) = list2chain (child_cfun-local_decls); DECL_SAVED_TREE (child_fn) = bb_stmt_list (single_succ (entry_bb)); + TREE_USED (block) = 1; /* Reset DECL_CONTEXT on function arguments. */ for (t = DECL_ARGUMENTS (child_fn); t; t = TREE_CHAIN (t)) outputs some debug info for the vars, the problem is that the same var can be then multiple times in the debug info. I guess we really should duplicate all the BLOCKs within #pragma omp parallel or #pragma omp task (not sure if we just should set BLOCK_ABSTRACT_ORIGIN to the original BLOCK), and stick the vars for debuginfo purposes into those BLOCKs. -- Summary: Debug info for OpenMP code is almost non-existent Product: gcc Version: 4.3.1 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36617
[Bug debug/36617] Debug info for OpenMP code is almost non-existent
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-24 10:01 ---
A testcase can be e.g.
int
foo (int *a, int *b, int *c, int *d)
{
return *a + *b + *c + *d;
}
int
main (void)
{
int vara = 1, varb = 0, varc, vard = 4;
#pragma omp parallel shared (vara, varb) private (varc) firstprivate (vard)
{
int vari, varj;
#pragma omp master
vara++;
varc = 3;
vard++;
varj = 6;
foo (vara, varb, varc, vard);
#pragma omp for reduction (+:varb)
for (vari = 0; vari 10; vari++)
varb += 2;
}
return 0;
}
at -g -O0 -fopenmp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36617
[Bug tree-optimization/36504] [4.3/4.4 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays
--- Comment #5 from jakub at gcc dot gnu dot org 2008-06-24 10:07 --- Subject: Bug 36504 Author: jakub Date: Tue Jun 24 10:06:17 2008 New Revision: 137061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137061 Log: PR tree-optimization/36504 * tree-ssa-loop-prefetch.c (gather_memory_references_ref): Skip references without base address. * gcc.dg/pr36504.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr36504.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-prefetch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
[Bug tree-optimization/36504] [4.3/4.4 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays
--- Comment #6 from jakub at gcc dot gnu dot org 2008-06-24 10:11 --- Subject: Bug 36504 Author: jakub Date: Tue Jun 24 10:10:44 2008 New Revision: 137062 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137062 Log: PR tree-optimization/36504 * tree-ssa-loop-prefetch.c (gather_memory_references_ref): Skip references without base address. * gcc.dg/pr36504.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr36504.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-loop-prefetch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
[Bug tree-optimization/36504] [4.3/4.4 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays
--- Comment #7 from jakub at gcc dot gnu dot org 2008-06-24 10:12 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
[Bug target/36615] gcc-4.3.1 fails to compile linux kernel sk_stream_wait_connect()
--- Comment #4 from hinko dot kocevar at cetrtapot dot si 2008-06-24 10:14 --- I can NOT reproduce the error with cris toolchain based on gcc 4.2.3. [EMAIL PROTECTED] /work/stage/git.br/project_build_cris/uclibc/linux-2.6.25.7 $ /work/stage/git.br/build_cris/staging_dir/usr/bin/cris-linux-uclibc-gcc --version cris-linux-uclibc-gcc (GCC) 4.2.3 Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36615
[Bug target/36615] gcc-4.3.1 fails to compile linux kernel sk_stream_wait_connect()
--- Comment #5 from hinko dot kocevar at cetrtapot dot si 2008-06-24 11:01
---
I can reproduce the error with cris toolchain based on gcc 4.4-20080620
snapshot.
[EMAIL PROTECTED] /work/stage/git.br/project_build_cris/uclibc/linux-2.6.25.7 $
/work/stage/git.br/build_cris/staging_dir/usr/bin/cris-linux-uclibc-gcc
-Wp,-MD,net/core/.stream.o.d -nostdinc -isystem
/work/stage/git.br/build_cris/staging_dir/usr/bin/../lib/gcc/cris-linux-uclibc/4.4.0/include
-D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Os -fno-stack-protector -mlinux
-march=v10 -pipe -Iinclude/asm/arch/mach -Iinclude/asm/arch
-fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign
--sysroot=/work/stage/git.br/build_cris/staging_dir/ -isysroot
/work/stage/git.br/build_cris/staging_dir -I=/usr/include -Os -pipe
-I/work/stage/git.br/build_cris/staging_dir/usr/include -mtune=v10 -march=v10
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(stream)
-DKBUILD_MODNAME=KBUILD_STR(stream) -c -o net/core/stream.o net/core/stream.c
(const_int -13 [0xfff3])
net/core/stream.c: In function 'sk_stream_wait_connect':
net/core/stream.c:78: internal compiler error: output_operand: invalid operand
for 'p' modifier
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
{standard input}: Assembler messages:
{standard input}:488: Warning: partial line at end of file ignored
[EMAIL PROTECTED] /work/stage/git.br $
/work/stage/git.br/build_cris/staging_dir/usr/bin/cris-linux-uclibc-gcc
--version
cris-linux-uclibc-gcc (GCC) 4.4.0 20080620 (experimental)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36615
[Bug target/36615] gcc-4.3.1 fails to compile linux kernel sk_stream_wait_connect()
--- Comment #6 from hinko dot kocevar at cetrtapot dot si 2008-06-24 11:03 --- Created an attachment (id=15809) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15809action=view) preprocessed source that caused the internal compiler error (with gcc4.4-20080620) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36615
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #10 from aldot at gcc dot gnu dot org 2008-06-24 11:19 --- (In reply to comment #9) DFP needs floating point exception support. If your C library doesn't support it, you can disable DFP. libdecnumber's configury should thus check whether fenv.h is available or not and default to no if no fenv.h was found. Looks like the enable_decimal_float handling is duplicated both in gcc/configure.ac as well as libdecnumber/configure.ac. Is there a reason for this duplication or is it pure oversight? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #11 from aldot at gcc dot gnu dot org 2008-06-24 11:21 --- libdecnumber hunk could look like this: Index: libdecnumber/configure.ac === --- libdecnumber/configure.ac (revision 137059) +++ libdecnumber/configure.ac (working copy) @@ -49,6 +49,7 @@ ACX_PROG_CC_WARNINGS_ARE_ERRORS([manual] # Checks for header files. AC_CHECK_HEADERS(ctype.h stddef.h string.h stdio.h) +AC_CHECK_HEADER([fenv.h],[],[libdecnumber_cv_fenv=no]) GCC_HEADER_STDINT(gstdint.h) # Checks for typedefs, structures, and compiler characteristics. @@ -99,10 +100,13 @@ Valid choices are 'yes', 'bid', 'dpd', a esac ]) +if test x$libdecnumber_cv_fenv = xno; then + enable_decimal_float=no +elif test x$enable_decimal_float = xyes -o x$enable_decimal_float = xno; then # x86's use BID format instead of DPD # In theory --enable-decimal-float=no should not compile anything # For the sake of simplicity, just use the default format in this directory -if test x$enable_decimal_float = xyes -o x$enable_decimal_float = xno; then + case $target in i?86*-*-linux* | x86_64*-*-linux*) enable_decimal_float=bid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug c++/36608] internal compiler error: in find_outermost_region_in_block, at tree-cfg.c:4739
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-24 11:33 --- You can compress the preprocessed source before attaching. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36608
[Bug middle-end/36613] [4.1/4.2/4.3/4.4 Regression] likely codegen bug
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-24 11:42 --- Fails since 4.1.0, still broken on the trunk. -- 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 Keywords||wrong-code Known to fail||4.0.2 4.1.0 Known to work||3.4.6 4.0.3 4.0.4 Last reconfirmed|-00-00 00:00:00 |2008-06-24 11:42:22 date|| Summary|likely codegen bug |[4.1/4.2/4.3/4.4 Regression] ||likely codegen bug Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
[Bug middle-end/36614] incorrect warning: array subscript is above array bounds
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-24 11:44 --- The warning is correct. The second access is always outside of the array. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36614
[Bug libstdc++/36612] __throw_* functions in ext/pb_ds/exception.hpp cause multiple definition errors
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-24 11:54 --- Hi. Yes, your solution seems a good one, barring larger changes to the code, I'll just do it, thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-24 11:54:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36612
[Bug libstdc++/36612] __throw_* functions in ext/pb_ds/exception.hpp cause multiple definition errors
--- Comment #2 from paolo dot carlini at oracle dot com 2008-06-24 12:14 --- Fixed mainline and 4_3-branch. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36612
[Bug middle-end/35492] ICE building kernel sk_stream_wait_connect output_operand: invalid operand for 'p' modifier
--- Comment #3 from hp at gcc dot gnu dot org 2008-06-24 12:16 --- *** Bug 36615 has been marked as a duplicate of this bug. *** -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hinko dot kocevar at ||cetrtapot dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35492
[Bug target/36615] gcc-4.3.1 fails to compile linux kernel sk_stream_wait_connect()
--- Comment #7 from hp at gcc dot gnu dot org 2008-06-24 12:16 --- Thanks for th report, I hope you don't feel bad that I have to close it as a duplicate: your work is appreciated. There's a hint in PR35492 if you want a local patch. (I guess I should up the priority for fixing PR35492; I thought we'd only ever see this problem locally at Axis. A solution that works is quite simple; the correct solution is harder.) *** This bug has been marked as a duplicate of 35492 *** -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36615
[Bug other/35858] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #10 from pluto at agmk dot net 2008-06-24 12:17 --- (In reply to comment #9) 4.3.0: 334s 1.6GB trunk: 62.20s 640MB trunk with SFTs: 327s 1.2GB so, fixed for 4.4.0. current 4.3 branch stats: -O1 -g0 : ~615MB, 0m58s -O2 -g0 : ~935MB, 2m13s looks far better than 4.3.0. can we close this as fixed for 4.3.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
[Bug target/36613] [4.1/4.2/4.3/4.4 Regression] likely codegen bug
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-24 12:28 --- We expand 25return left right; to sall%cl, %ecx but we initialized %ecx from movb%dl, %cl so later the comparison against zero fails due to the upper part of ecx being uninitialized. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||uros at gcc dot gnu dot org Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
[Bug libstdc++/36616] Open issues from a test run
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-24 12:34 --- This is essentially because openSUSE 11.0 uses glibc2.8 (at variance with 10.3, for example). Likely, there are some small changes in the localedata, not worrisome, but let's look a bit into it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-24 12:34:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #12 from joseph at codesourcery dot com 2008-06-24 12:36
---
Subject: Re: pulls in allegedly unneeded floatingpoint
exception access funcs
On Tue, 24 Jun 2008, aldot at gcc dot gnu dot org wrote:
libdecnumber hunk could look like this:
libdecnumber's configure.ac is for the host, not the target. As such, it
needs to remain in sync with gcc's. I'm pretty sure it's deliberate that
it still needs to select a format even with --disable-decimal-float.
The logic selecting for the target is in libgcc/configure.ac. That's the
only place disabling without fenv.h might make sense (and if an explicit
--enable-decimal-float={yes,bid,dpd} is given without fenv.h, give an
error). The only reason this really makes sense is that you can
legitimately have both glibc and uClibc multilibs, some with fenv.h and
some without, and libgcc's configure is run once for each multilib.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/36613] [4.1/4.2/4.3/4.4 Regression] likely codegen bug
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-24 12:40 ---
Actually this may be a reload/df problem -- in reload we have
;; bb 4 artificial_defs: { }
;; bb 4 artificial_uses: { u-1(6){ }u-1(7){ }}
;; lr in1 [dx] 6 [bp] 7 [sp] 20 [frame]
;; lr use 1 [dx] 6 [bp] 7 [sp]
;; lr def 2 [cx] 17 [flags]
;; live in 1 [dx] 6 [bp] 7 [sp] 20 [frame]
;; live gen 2 [cx]
;; live kill17 [flags]
;; Pred edge 3 [50.0%] (fallthru)
(note:HI 14 13 15 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn:HI 15 14 65 4 t.c:25 (parallel [
(set (reg/v:SI 2 cx [orig:58 p_48.12 ] [58])
(ashift:SI (reg/v:SI 2 cx [orig:58 p_48.12 ] [58])
(reg:QI 2 cx)))
(clobber (reg:CC 17 flags))
]) 459 {*ashlsi3_1} (nil))
but cx should be live in as it is used by the ashift.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||matz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
[Bug other/35858] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-06-24 12:46 --- Yes. Fixed for 4.3.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.3.0 |4.3.0 4.3.1 Resolution||FIXED Target Milestone|4.4.0 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
[Bug target/36615] gcc-4.3.1 fails to compile linux kernel sk_stream_wait_connect()
--- Comment #8 from hinko dot kocevar at cetrtapot dot si 2008-06-24 12:48 --- I have no problem with that - if it is a duplicate it is a duplicate.. The PR35492 is explaining something but I'm too lame to understand the compiler talk. I guess I'll wait for the trunk fix. OTOH if someone could provide the 'quick' fix for 4.3 I could stress test it right now.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36615
[Bug libstdc++/36616] Open issues from a test run
--- Comment #2 from ubizjak at gmail dot com 2008-06-24 12:59 --- (In reply to comment #1) This is essentially because openSUSE 11.0 uses glibc2.8 (at variance with 10.3, for example). Likely, there are some small changes in the localedata, not worrisome, but let's look a bit into it. FYI, FAIL: 22_locale/money_put/put/char/9780-3.cc execution test also fails on Fedora9. IIRC, EUR is put at the end of result string. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug libstdc++/36616] Open issues from a test run
--- Comment #3 from paolo dot carlini at oracle dot com 2008-06-24 13:07 --- Yes, I suppose Fedora also uses glibc2.8? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug java/36618] New: gcc-4.4-20080620 ICE in gcj/gnu.CORBA.OrbFunctional
bootstrap failure when building gcc-4.4-20080620. Did NOT happen with gcc-4.4-20080613. Let me know if you want more details. /bin/sh ./libtool --tag=GCJ --mode=compile /usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/gcc/gcj -B/usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/x86_64-unknown-linux-gnu/32/libjava/ -B/usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/usr/local/gcc-4.4-20080620/src/gcc-4.4-20080620/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m32 -fsource-filename=/usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/x86_64-unknown-linux-gnu/32/libjava/classpath/lib/classes -fjni -findirect-dispatch -fno-indirect-classes -c -o gnu-CORBA.lo @gnu-CORBA.list libtool: compile: /usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/gcc/gcj -B/usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/x86_64-unknown-linux-gnu/32/libjava/ -B/usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/usr/local/gcc-4.4-20080620/src/gcc-4.4-20080620/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m32 -fsource-filename=/usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/x86_64-unknown-linux-gnu/32/libjava/classpath/lib/classes -fjni -findirect-dispatch -fno-indirect-classes -c @gnu-CORBA.list -fPIC -o .libs/gnu-CORBA.o /usr/local/gcc-4.4-20080620/src/gcc-4.4-20080620/libjava/classpath/gnu/CORBA/OrbFunctional.java: In class 'gnu.CORBA.OrbFunctional': /usr/local/gcc-4.4-20080620/src/gcc-4.4-20080620/libjava/classpath/gnu/CORBA/OrbFunctional.java: In method 'gnu.CORBA.OrbFunctional.serveStep(java.net.Socket,bo620/src/gcc-4.4-20080620/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m32 -fsource-filename=/usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/x86_64-unknown-linux-gnu/32/libjava/classpath/lib/classes -fjni -findirect-dispatch -fno-indirect-classes -c @gnu-CORBA.list -fPIC -o .libs/gnu-CORBA.o /usr/local/gcc-4.4-20080620/src/gcc-4.4-20080620/libjava/classpath/gnu/CORBA/OrbFunctional.java: In class 'gnu.CORBA.OrbFunctional': /usr/local/gcc-4.4-20080620/src/gcc-4.4-20080620/libjava/classpath/gnu/CORBA/OrbFunctional.java: In method 'gnu.CORBA.OrbFunctional.serveStep(java.net.Socket,boolean)': In file included from built-in:4: /usr/local/gcc-4.4-20080620/src/gcc-4.4-20080620/libjava/classpath/gnu/CORBA/OrbFunctional.java:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [gnu-CORBA.lo] Error 1 make[5]: Leaving directory `/usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/x86_64-unknown-linux-gnu/32/libjava' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/local/gcc-4.4-20080620/src/obj-x86_64-Linux-fc8/x86_64-unknown-linux-gnu/32/libjava' make[3]: *** [multi-do] Error 1 -- Summary: gcc-4.4-20080620 ICE in gcj/gnu.CORBA.OrbFunctional Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mariah dot lenox 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=36618
[Bug java/36618] gcc-4.4-20080620 ICE in gcj/gnu.CORBA.OrbFunctional
--- Comment #1 from ubizjak at gmail dot com 2008-06-24 13:47 --- According to recent testresults, bootstrap works OK on x86_64: http://gcc.gnu.org/ml/gcc-bugs/2008-06/msg01426.html Can you try to build from a clean build dir? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36618
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #11 from jakub at gcc dot gnu dot org 2008-06-24 14:44 --- PROGRAM PR35659 DIMENSION A(1000), B(1010), AUX(8), IPIV(8), X(16) COMMON /TLSDIM/ M1,M,N,L,IER COMMON /SLATE/ V1,V2,IAR(24),DUM(14) DATA A/0, 1, 0, 0, 1, 0, 2, 0, 1, 0, 0, 0, 1, 0.20003, 1 0.039991, 0.0080038, 1, 0.40006, 0.15996, 2 0.06403, 1, 0.60024, 0.36014, 0.21606, 1, 3 0.80012, 0.63986, 0.51224, 1, 1, 1, 1, 968*0./ DATA B/1, 2, 1, 1.22140002, 1.49179995, 1.82210004, 4 2.22550011, 2.7183001, 0, 0, 1000*0./ M1 = 2 M = 8 N = 4 L = 1 IER = 0 V1 = 0 V2 = 1.40129846e-45 IAR(:) = 538976288 DUM(:) = 1.35631564e-19 CALL TLSC(A,B,AUX,IPIV,1.,X) IF (ABS(X(1) - 0.99785352).GE.0.1) CALL ABORT IF (ABS(X(2) - 1.0).GE.0.1) CALL ABORT IF (ABS(X(3) - 0.50107324).GE.0.1) CALL ABORT IF (ABS(X(4) - 0.21670136).GE.0.1) CALL ABORT END SUBROUTINE TLSMSQ (B,L,M,F) COMMON /SLATE/ DUM(38),I,JB DIMENSION B(*) F = 0. JB = 1 DO 10I=1,M F = F + B(JB)*B(JB) 10 JB = JB + L RETURN END SUBROUTINE TLSWOP (A,AD,N,NR) COMMON /SLATE/ DUM(37),H,I,JA DIMENSION A(*), AD(*) JA = 1 DO 10I=1,NR H = A(JA) A(JA) = AD(JA) AD(JA) = H 10 JA = JA + N RETURN END SUBROUTINE TLUK (A,IASEP,NR,SIG,BETA) COMMON /SLATE/ DUM(37),I,JA,LL DIMENSION A(*) SIG= 0. JA = 1 LL = 0 DO 10I=1,NR IF (A(JA).EQ.0.) GO TO 10 LL = I SIG= SIG + A(JA)* A(JA) 10 JA = JA + IASEP NR = LL IF (NR.EQ.0) RETURN SIG = SIGN (SQRT (SIG),A(1)) BETA = A(1) + SIG A(1) = BETA BETA = 1. / (SIG * BETA) RETURN END SUBROUTINE TLSTEP (A,B,IASEP,IBSEP,NR,NC,BETA) COMMON /SLATE/ DUM(34),H,I,IB,J,JA,JB DIMENSION A(*), B(*) IB = 0 DO 30J=1,NC IB = IB + 1 H = 0. JA = 1 JB = IB DO 10I=1,NR H = H + A(JA) * B(JB) JA = JA +IASEP 10 JB = JB + IBSEP H = H * BETA JA = 1 JB = IB DO 20I=1,NR B(JB) = B(JB) - A(JA) * H JA = JA +IASEP 20 JB = JB + IBSEP 30 CONTINUE RETURN END together with tlsc.f can work as a testcase, and reproduces the problem with current 4.3 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #12 from jakub at gcc dot gnu dot org 2008-06-24 15:04 --- Even smaller reproducer: PROGRAM PR35659 DIMENSION A(1000), B(1010), AUX(8), IPIV(8), X(16) COMMON /TLSDIM/ M1,M,N,L,IER COMMON /SLATE/ V1,V2,IAR(24),DUM(14) DATA A/0, 1, 0, 0, 1, 0, 2, 0, 1, 0, 0, 0, 1, 0.20003, 1 0.039991, 0.0080038, 1, 0.40006, 0.15996, 2 0.06403, 1, 0.60024, 0.36014, 0.21606, 1, 3 0.80012, 0.63986, 0.51224, 1, 1, 1, 1, 968*0./ DATA B/1, 2, 1, 1.22140002, 1.49179995, 1.82210004, 4 2.22550011, 2.7183001, 0, 0, 1000*0./ M1 = 2 M = 8 N = 4 L = 1 IER = 0 V1 = 0 V2 = 1.40129846e-45 IAR(:) = 538976288 DUM(:) = 1.35631564e-19 CALL TLSC(A,B,AUX,IPIV,1.,X) END SUBROUTINE TLSMSQ (B,L,M,F) DIMENSION B(*) IF (M.NE.2) CALL ABORT STOP 0 END SUBROUTINE TLSWOP (A,AD,N,NR) DIMENSION A(*), AD(*) CALL ABORT END SUBROUTINE TLUK (A,IASEP,NR,SIG,BETA) DIMENSION A(*) CALL ABORT END SUBROUTINE TLSTEP (A,B,IASEP,IBSEP,NR,NC,BETA) DIMENSION A(*), B(*) CALL ABORT END The miscompiled TLSC calls the first TLSMSQ routine with 8.0 rather than 2.0 as the 3rd argument. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-24 15:04:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug libstdc++/36616] Open issues from a test run
--- Comment #4 from ubizjak at gmail dot com 2008-06-24 15:19 --- (In reply to comment #3) Yes, I suppose Fedora also uses glibc2.8? Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug ada/36619] New: Assignment to classwide leads to constraint error
An attached program being compiled with gnatmake boom crached at runtime with CONSTRAINT_ERROR tag check failed. -- Summary: Assignment to classwide leads to constraint error Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fedya_fedyakoff at inbox dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36619
[Bug ada/36619] Assignment to classwide leads to constraint error
--- Comment #1 from fedya_fedyakoff at inbox dot ru 2008-06-24 15:29 --- Created an attachment (id=15810) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15810action=view) Simple code exposing erroneous behaviour -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36619
[Bug testsuite/36620] New: gcc.dg/pr36504.c doesn't work on 32bit
I got Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/pr36504.c -O3 -fprefetch-loop-arrays -fno-show-column -S -m32 -o pr36504.s(timeout = 300) /export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/pr36504.c:1: warning: -fprefetch-loop-arrays not supported for this target (try -march switches)^M -- Summary: gcc.dg/pr36504.c doesn't work on 32bit 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=36620
[Bug libstdc++/36616] Open issues from a test run
--- Comment #5 from paolo at gcc dot gnu dot org 2008-06-24 16:31 --- Subject: Bug 36616 Author: paolo Date: Tue Jun 24 16:31:06 2008 New Revision: 137073 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137073 Log: 2008-06-24 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/36616 * testsuite/22_locale/money_put/put/char/9780-3.cc: Fix expected results for recent glibcs (2.8 and later). * testsuite/22_locale/time_put/put/wchar_t/4.cc: Likewise. * testsuite/22_locale/time_put/put/char/4.cc: Likewise. Modified: trunk/libstdc++-v3/testsuite/22_locale/money_put/put/char/9780-3.cc trunk/libstdc++-v3/testsuite/22_locale/time_put/put/char/4.cc trunk/libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/4.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug libstdc++/36616] Open issues from a test run
--- Comment #6 from paolo at gcc dot gnu dot org 2008-06-24 16:32 --- Subject: Bug 36616 Author: paolo Date: Tue Jun 24 16:31:22 2008 New Revision: 137074 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137074 Log: 2008-06-24 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/36616 * testsuite/22_locale/money_put/put/char/9780-3.cc: Fix expected results for recent glibcs (2.8 and later). * testsuite/22_locale/time_put/put/wchar_t/4.cc: Likewise. * testsuite/22_locale/time_put/put/char/4.cc: Likewise. Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/testsuite/22_locale/money_put/put/char/9780-3.cc branches/gcc-4_3-branch/libstdc++-v3/testsuite/22_locale/time_put/put/char/4.cc branches/gcc-4_3-branch/libstdc++-v3/testsuite/22_locale/time_put/put/wchar_t/4.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug libstdc++/36616] Open issues from a test run
--- Comment #7 from paolo dot carlini at oracle dot com 2008-06-24 16:34 --- Fixed for mainline and 4.3.2. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug libstdc++/36616] Open issues from a test run
--- Comment #8 from Markus dot Elfring at web dot de 2008-06-24 17:13 --- Thanks. Were only the test cases affected? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug libstdc++/36616] Open issues from a test run
--- Comment #9 from paolo dot carlini at oracle dot com 2008-06-24 17:18 --- Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug target/36621] New: infinite _Unwind_Backtrace / thread stack unwinding.
$ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20061011 (Red Hat 4.1.1-30) GNU C Library stable release version 2.7, by Roland McGrath et al. GNU gdb Red Hat Linux (6.5-8.fc6rh) +++ This bug was initially created as a clone of Bug #36568 +++ test w/o threads: $ ./u 0x400a74 handler+0x1a 0x400a95 crash+0x10 0x400afd main+0x60 0x7fa92f9e74a4 __libc_start_main+0xf4 test w/ threads: $ ./u threaded 0x400a74 handler+0x1a 0x400a95 crash+0x10 0x7fcea7803a3d clone+0x6d 0x7fcea7803a3d clone+0x6d 0x7fcea7803a3d clone+0x6d 0x7fcea7803a3d clone+0x6d 0x7fcea7803a3d clone+0x6d 0x7fcea7803a3d clone+0x6d 0x7fcea7803a3d clone+0x6d 0x7fcea7803a3d clone+0x6d 0x7fcea7803a3d clone+0x6d (...) gdb stops unwinding at clone(): $ gdb ./u (gdb) set args threaded (gdb) r (...) [New Thread 0x7fdd9636b6f0 (LWP 7318)] [New Thread 0x42501950 (LWP 7322)] (...) Breakpoint 2, handler (signalNumber=11) at u.c:25 25 _Unwind_Backtrace( helper, 0 ); (gdb) bt #0 handler (signalNumber=11) at u.c:25 #1 signal handler called #2 0x00400a95 in crash () at u.c:32 #3 0x7fa0eef04070 in start_thread () from /lib64/libpthread.so.0 #4 0x7fa0eea6da3d in clone () from /lib64/libc.so.6 gcc-4.2.4-1.x86_64 glibc-2.8-3.x86_64 gdb-6.8-1.x86_64 -- Summary: infinite _Unwind_Backtrace / thread stack unwinding. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vinutheraj at gmail dot com GCC target triplet: x86_64-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36621
[Bug libgcj/32198] rmic fails if remote method throws superclass of RemoteException
--- Comment #3 from cvs-commit at developer dot classpath dot org 2008-06-24 17:36 --- Subject: Bug 32198 CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Tom Tromey tromey 08/06/24 17:36:07 Modified files: . : ChangeLog tools/gnu/classpath/tools/rmic: SourceGiopRmicCompiler.java Log message: PR libgcj/32198: * tools/gnu/classpath/tools/rmic/SourceGiopRmicCompiler.java (compile): Reverse isAssignableFrom test. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9660r2=1.9661 http://cvs.savannah.gnu.org/viewcvs/classpath/tools/gnu/classpath/tools/rmic/SourceGiopRmicCompiler.java?cvsroot=classpathr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32198
[Bug target/36621] infinite _Unwind_Backtrace / thread stack unwinding.
--- Comment #1 from vinutheraj at gmail dot com 2008-06-24 18:21 --- This code seems to work against the gcc version in ubuntu 8.04 heres the output : $ ./u threaded 0x400af4 handler+0x1a 0x400b15 crash+0x10 0x7fc507445b2d clone+0x6d $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36621
[Bug libgcj/32198] rmic fails if remote method throws superclass of RemoteException
--- Comment #4 from tromey at gcc dot gnu dot org 2008-06-24 18:32 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32198
[Bug libgcj/32198] rmic fails if remote method throws superclass of RemoteException
--- Comment #5 from tromey at gcc dot gnu dot org 2008-06-24 18:32 --- Subject: Bug 32198 Author: tromey Date: Tue Jun 24 18:31:49 2008 New Revision: 137084 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137084 Log: PR libgcj/32198: * tools/gnu/classpath/tools/rmic/SourceGiopRmicCompiler.java (compile): Reverse isAssignableFrom test. * tools/gnu/classpath/tools/rmic/SourceGiopRmicCompiler.class: Rebuilt. Modified: trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/tools/classes/gnu/classpath/tools/rmic/SourceGiopRmicCompiler.class trunk/libjava/classpath/tools/gnu/classpath/tools/rmic/SourceGiopRmicCompiler.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32198
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-24 19:10 --- Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above This fixes it for me. Can you check on hppa? It also works on hppa. Tested on hhpa-unknown-linux-gnu and hppa64-hp-hpux11.11. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #117 from pepalogik at seznam dot cz 2008-06-24 20:12 --- (In reply to comment #116) Yes, but this requires quite a complicated workaround (solution (4) in my comment #109). The problem is on the compiler side, which could store every result of a cast or an assignment to memory (this is inefficient, but that's what you get with the x87, and the ISO C language could be blamed too for *requiring* something like that instead of being more flexible). So you could say that the IEEE754 double precision type is available even on a processor without any FPU because this can be emulated using integers. Yes, but a conforming implementation would be the processor + a library, not just the processor with its instruction set. Moreover, if we assess things pedantically, the workaround (4) still doesn't fully obey the IEEE single/double precision type(s), because there remains the problem of double rounding of denormals. As I said, in this particular case (underflow/overflow), double rounding is allowed by the IEEE standard. It may not be allowed by some languages (e.g. XPath, and Java in some mode) for good or bad reasons, but this is another problem. OK, thanks for explanation. I think now it's clear. I quote, too: Applies To Microsoft#174; Visual C++#174; Now I assume that it follows the MS-Windows API (though nothing is certain with Microsoft). And the other compilers under MS-Windows could (or should) do the same thing. By a lucky hit, I have found this in the GCC documentation: -mpc32 -mpc64 -mpc80 Set 80387 floating-point precision to 32, 64 or 80 bits. When '-mpc32' is specified, the significands of results of floating-point operations are rounded to 24 bits (single precision); '-mpc64' rounds the the significands of results of floatingpoint operations to 53 bits (double precision) and '-mpc80' rounds the significands of results of floating-point operations to 64 bits (extended double precision), which is the default. When this option is used, floating-point operations in higher precisions are not available to the programmer without setting the FPU control word explicitly. [...] So GCC sets extended precision by default. And it's easy to change it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/35419] [4.3/4.4 Regression] bfin libgcc build error
--- Comment #3 from bunk at stusta dot de 2008-06-24 20:19 --- Yes, bfin-uclinux works for me. It might be nice to get bfin-linux as an alias for bfin-uclinux, but this bug of mine is definitely INVALID. -- bunk at stusta dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35419
[Bug libstdc++/36616] Open issues from a test run
--- Comment #10 from ubizjak at gmail dot com 2008-06-24 20:42 --- Hm, these now fail on my x86_64 Fedora 9: FAIL: 22_locale/time_put/put/char/4.cc execution test FAIL: 22_locale/time_put/put/char/wrapped_env.cc execution test FAIL: 22_locale/time_put/put/char/wrapped_locale.cc execution test FAIL: 22_locale/time_put/put/wchar_t/4.cc execution test FAIL: 22_locale/time_put/put/wchar_t/wrapped_env.cc execution test FAIL: 22_locale/time_put/put/wchar_t/wrapped_locale.cc execution test libc signature is: GNU C Library stable release version 2.8, by Roland McGrath et al. Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.3.0 20080428 (Red Hat 4.3.0-8). Compiled on a Linux 2.6.18-53.1.14.el5xen system on 2008-05-05. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B RT using linux kernel aio For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug c++/23194] Unhelpful diagnostic for incorrect pointer-to-member function syntax
--- Comment #13 from redi at gcc dot gnu dot org 2008-06-24 20:44 --- Subject: Bug 23194 Author: redi Date: Tue Jun 24 20:44:04 2008 New Revision: 137086 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137086 Log: PR c++/23194 * typeck.c (cp_build_function_call): Show example syntax in diagnostic. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23194
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #118 from vincent at vinc17 dot org 2008-06-24 20:45 --- (In reply to comment #117) By a lucky hit, I have found this in the GCC documentation: -mpc32 -mpc64 -mpc80 OK, this is new in gcc 4.3. I haven't tried, but if gcc just changes the precision without changing the values of float.h macros to make them correct, this is just a workaround (better than nothing, though). Also, this is a problem for library code if it requires to have double precision instead of extended precision, as these options won't probably be taken into account at that point. (Unfortunately it's probably too late to have a clean ABI.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug c++/23194] Unhelpful diagnostic for incorrect pointer-to-member function syntax
--- Comment #14 from jwakely dot gcc at gmail dot com 2008-06-24 20:46 --- Fixed for 4.4 -- jwakely dot gcc at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23194
[Bug target/36621] infinite _Unwind_Backtrace / thread stack unwinding.
--- Comment #2 from vinutheraj at gmail dot com 2008-06-24 20:58 --- Created an attachment (id=15811) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15811action=view) Its a patch provided with ubuntu and debian which solves this backtrace problem This patch provided with ubuntu and debian solves this backtrace problem automagically. I chanced upon it by luck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36621
[Bug target/36568] infinite _Unwind_Backtrace / thread stack unwinding.
--- Comment #3 from vinutheraj at gmail dot com 2008-06-24 21:04 --- Created an attachment (id=15812) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15812action=view) A patch which comes with debian and ubuntu which solves this problem A patch which is provided with ubuntu and debian which solves the problem of the infinite _Unwind_Backtrace automagically. I chanced upon this luckily. In ubuntu do apt-get install glibc-source and in patches/amd64/ you will find it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36568
[Bug target/36621] infinite _Unwind_Backtrace / thread stack unwinding.
--- Comment #3 from pluto at agmk dot net 2008-06-24 21:27 --- (In reply to comment #2) Created an attachment (id=15811) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15811action=view) [edit] Its a patch provided with ubuntu and debian which solves this backtrace problem This patch provided with ubuntu and debian solves this backtrace problem automagically. I chanced upon it by luck. so it's a glibc bug, not a gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36621
[Bug libstdc++/36616] Open issues from a test run
--- Comment #11 from paolo dot carlini at oracle dot com 2008-06-24 21:29 --- Frankly, I find that extremely hard to believe, did you fully update? Because of course I tested both on a glibc2.8 machine (openSUSE 11) and a glibc2.6.1 machine. Please post the relevant lines in libstdc++.log or, even better, debug a bit char/4.cc, just print the expected string vs the actual one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36616
[Bug fortran/36371] [4.3/4.4 Regression] Wrong locus for errors in DATA statement
--- Comment #2 from pault at gcc dot gnu dot org 2008-06-24 21:45 --- Subject: Bug 36371 Author: pault Date: Tue Jun 24 21:44:28 2008 New Revision: 137088 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137088 Log: 2008-06-24 Paul Thomas [EMAIL PROTECTED] PR fortran/34371 * expr.c (gfc_check_assign): Change message and locus for error when conform == 0. 2008-06-24 Paul Thomas [EMAIL PROTECTED] PR fortran/36371 * gfortran.dg/data_array_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/data_array_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36371
[Bug tree-optimization/34371] [4.3 Regression] verify_stmts failed (incorrect sharing of tree nodes)
--- Comment #7 from pault at gcc dot gnu dot org 2008-06-24 21:45 --- Subject: Bug 34371 Author: pault Date: Tue Jun 24 21:44:28 2008 New Revision: 137088 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137088 Log: 2008-06-24 Paul Thomas [EMAIL PROTECTED] PR fortran/34371 * expr.c (gfc_check_assign): Change message and locus for error when conform == 0. 2008-06-24 Paul Thomas [EMAIL PROTECTED] PR fortran/36371 * gfortran.dg/data_array_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/data_array_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34371
[Bug target/36568] infinite _Unwind_Backtrace / thread stack unwinding.
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-24 22:02 --- *** Bug 36621 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vinutheraj at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36568
[Bug target/36621] infinite _Unwind_Backtrace / thread stack unwinding.
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-24 22:02 --- *** This bug has been marked as a duplicate of 36568 *** -- 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=36621
[Bug target/36568] infinite _Unwind_Backtrace / thread stack unwinding.
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-06-24 22:03 --- This is a glibc bug then. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36568
[Bug middle-end/36594] [4.4 Regression] multiple regressions on powerpc at rev.136976
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-06-24 22:42 --- Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36594
[Bug middle-end/36594] [4.4 Regression] multiple regressions on powerpc at rev.136976
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-06-24 22:42 --- Subject: Bug 36594 Author: pinskia Date: Tue Jun 24 22:42:10 2008 New Revision: 137089 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137089 Log: 2008-06-24 Andrew Pinski [EMAIL PROTECTED] PR middle-end/36594 * builtins.c (expand_builtin_nonlocal_goto): Stabilize the address of the memory instead of the memory itself for the save area. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36594
[Bug middle-end/36594] [4.4 Regression] multiple regressions on powerpc at rev.136976
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-06-24 22:43 --- Fixed I said. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36594
Template problems
The following code causes this gcc error:
test.c: In member function `void Test2TAnotherClass::Initialize()':
test.c:22: error: expected primary-expression before '' token
test.c:22: error: expected primary-expression before ')' token
template class TSomeClass
class Test1
{
public:
template class TOtherClass
void TestMe()
{
}
};
struct Nothing2
{
};
template class TAnotherClass
class Test2
{
public:
void Initialize()
{
mTest.TestMeNothing2();
}
Test1TAnotherClass mTest;
};
struct Nothing
{
};
void TestFunc()
{
Test2Nothing as;
as.Initialize();
}
Re: Template problems
On Tue, Jun 24, 2008 at 4:06 PM, Andrew McPherson
[EMAIL PROTECTED] wrote:
template class TAnotherClass
class Test2
{
public:
void Initialize()
{
You missed the template keyword here:
mTest.TestMeNothing2();
That should be:
mTest. template TestMeNothing2();
}
Test1TAnotherClass mTest;
};
Thanks,
Andrew Pinski
[Bug c/36622] New: 4.3.1 failed to compile gcse.c file.
Hi,
I am compiling this against SuSE Linux Ent. Server 9 32-bit.
I get the following error at stage2:
---snip---
../../gcc-4.3.1/gcc/gcse.c: In function ?one_cprop_pass?:
../../gcc-4.3.1/gcc/gcse.c:3458: error: invalid rtl sharing found in the insn
(insn 865 862 866 141 ../../gcc-4.3.1/gcc/gcse.c:2151 (parallel [
(set (reg:SI 387)
(udiv:SI (reg/v:SI 175 [ regno ])
(mem/s/c:SI (plus:SI (reg:SI 3 bx)
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI (set_hash_table)
[flags 0x2] var_decl 0x40a98c08 set_hash_table)
] 1)
(const_int 4 [0x4] [3
set_hash_table.size+0 S4 A32])))
(set (reg:SI 386)
(umod:SI (reg/v:SI 175 [ regno ])
(mem/s/c:SI (plus:SI (reg:SI 3 bx)
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI (set_hash_table)
[flags 0x2] var_decl 0x40a98c08 set_hash_table)
] 1)
(const_int 4 [0x4] [3
set_hash_table.size+0 S4 A32])))
(clobber (reg:CC 17 flags))
]) 229 {udivmodsi4} (expr_list:REG_UNUSED (reg:SI 387)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
../../gcc-4.3.1/gcc/gcse.c:3458: error: shared rtx
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI (set_hash_table) [flags 0x2] var_decl
0x40a98c08 set_hash_table)
] 1)
(const_int 4 [0x4])))
../../gcc-4.3.1/gcc/gcse.c:3458: internal compiler error: internal consistency
failure
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
gmake[3]: *** [gcse.o] Error 1
--snip--
Can someone please help out? I looked at bug 36111, tried applyig the patches
suggested there, but no luck.
Thanks in advance.
--
Summary: 4.3.1 failed to compile gcse.c file.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: imam dot toufique at intel dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-24 23:36 --- How did you configure GCC? Do you have CFLAGS set? How did you invoke make? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug c/36623] New: 4.3.1 failed to compile gcse.c file.
Hi,
I am compiling this against SuSE Linux Ent. Server 9 32-bit.
I get the following error at stage2:
---snip---
../../gcc-4.3.1/gcc/gcse.c: In function ?one_cprop_pass?:
../../gcc-4.3.1/gcc/gcse.c:3458: error: invalid rtl sharing found in the insn
(insn 865 862 866 141 ../../gcc-4.3.1/gcc/gcse.c:2151 (parallel [
(set (reg:SI 387)
(udiv:SI (reg/v:SI 175 [ regno ])
(mem/s/c:SI (plus:SI (reg:SI 3 bx)
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI (set_hash_table)
[flags 0x2] var_decl 0x40a98c08 set_hash_table)
] 1)
(const_int 4 [0x4] [3
set_hash_table.size+0 S4 A32])))
(set (reg:SI 386)
(umod:SI (reg/v:SI 175 [ regno ])
(mem/s/c:SI (plus:SI (reg:SI 3 bx)
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI (set_hash_table)
[flags 0x2] var_decl 0x40a98c08 set_hash_table)
] 1)
(const_int 4 [0x4] [3
set_hash_table.size+0 S4 A32])))
(clobber (reg:CC 17 flags))
]) 229 {udivmodsi4} (expr_list:REG_UNUSED (reg:SI 387)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
../../gcc-4.3.1/gcc/gcse.c:3458: error: shared rtx
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI (set_hash_table) [flags 0x2] var_decl
0x40a98c08 set_hash_table)
] 1)
(const_int 4 [0x4])))
../../gcc-4.3.1/gcc/gcse.c:3458: internal compiler error: internal consistency
failure
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
gmake[3]: *** [gcse.o] Error 1
--snip--
Can someone please help out? I looked at bug 36111, tried applyig the patches
suggested there, but no luck.
Thanks in advance.
--
Summary: 4.3.1 failed to compile gcse.c file.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: imam dot toufique at intel dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36623
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-24 23:37 --- (const:SI (plus:SI (unspec:SI [ (symbol_ref:SI (set_hash_table) [flags 0x2] var_decl 0x40a98c08 set_hash_table) ] 1) Should only show up with -fPIC so I think you are using weird options to build GCC. Though it is still a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug c/36624] New: 4.3.1 failed to compile gcse.c file.
Hi,
I am compiling this against SuSE Linux Ent. Server 9 32-bit.
I get the following error at stage2:
---snip---
../../gcc-4.3.1/gcc/gcse.c: In function ?one_cprop_pass?:
../../gcc-4.3.1/gcc/gcse.c:3458: error: invalid rtl sharing found in the insn
(insn 865 862 866 141 ../../gcc-4.3.1/gcc/gcse.c:2151 (parallel [
(set (reg:SI 387)
(udiv:SI (reg/v:SI 175 [ regno ])
(mem/s/c:SI (plus:SI (reg:SI 3 bx)
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI (set_hash_table)
[flags 0x2] var_decl 0x40a98c08 set_hash_table)
] 1)
(const_int 4 [0x4] [3
set_hash_table.size+0 S4 A32])))
(set (reg:SI 386)
(umod:SI (reg/v:SI 175 [ regno ])
(mem/s/c:SI (plus:SI (reg:SI 3 bx)
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI (set_hash_table)
[flags 0x2] var_decl 0x40a98c08 set_hash_table)
] 1)
(const_int 4 [0x4] [3
set_hash_table.size+0 S4 A32])))
(clobber (reg:CC 17 flags))
]) 229 {udivmodsi4} (expr_list:REG_UNUSED (reg:SI 387)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
../../gcc-4.3.1/gcc/gcse.c:3458: error: shared rtx
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI (set_hash_table) [flags 0x2] var_decl
0x40a98c08 set_hash_table)
] 1)
(const_int 4 [0x4])))
../../gcc-4.3.1/gcc/gcse.c:3458: internal compiler error: internal consistency
failure
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
gmake[3]: *** [gcse.o] Error 1
--snip--
Can someone please help out? I looked at bug 36111, tried applyig the patches
suggested there, but no luck.
Thanks in advance.
--
Summary: 4.3.1 failed to compile gcse.c file.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: imam dot toufique at intel dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36624
[Bug target/36621] infinite _Unwind_Backtrace / thread stack unwinding.
--- Comment #5 from vinutheraj at gmail dot com 2008-06-24 23:39 --- Yup its a glibc bug, I was working on porting something when I chanced upon it, and was surprised to see the bug reported here. So if somebody can report it over at glibc bugzilla, it would be very helpful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36621
[Bug c/36623] 4.3.1 failed to compile gcse.c file.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-24 23:40 --- *** This bug has been marked as a duplicate of 36622 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36623
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-06-24 23:40 --- *** Bug 36623 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug c/36624] 4.3.1 failed to compile gcse.c file.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-24 23:40 --- *** This bug has been marked as a duplicate of 36622 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36624
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-06-24 23:40 --- *** Bug 36624 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug c++/36625] New: missing diagnostic on invalid __attribute__((aligned(N)))
I expected to see a diagnostic for the following program regardless of whether
the template is instantiated or not, or whether the nested type is used or not.
Gcc only diagnoses the attribute when the type is used.
That said, rather than diagnosing it, it'd be even more useful to allow non
type template parameters and other constant integral expressions as arguments
to the attribute.
$ cat t.cpp g++ t.cpp echo PASS g++ -DUSE_IT t.cpp
template int N
struct A {
struct S { short f[3]; } __attribute__ ((aligned (N)));
};
int main ()
{
A123 a;
#ifdef USE_IT
A123::S s;
#endif
}
PASS
t.cpp: In instantiation of A123::S:
t.cpp:10: instantiated from here
t.cpp:3: error: N was not declared in this scope
t.cpp:3: error: requested alignment is not a constant
--
Summary: missing diagnostic on invalid
__attribute__((aligned(N)))
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36625
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #5 from imam dot toufique at intel dot com 2008-06-24 23:46 --- (pardon me, I am pretty new for submitting bug reports at this site) From the previous note I just received, it looks like I should not be using fPIC option to compile gcc? is this applicable for both 32 and 64 bit platforms for compiling gcc 4.3.1? This is what I have set set for CFLAGS: CFLAGS='-O2 -fPIC -I/usr/pkgs/libmpfr/2.3.0/include -L/usr/pkgs/libmpfr/2.3.0/lib -I/usr/pkgs/libgmp/4.2.2/include -L/usr/pkgs/libgmp/4.2.2/lib -I/usr/pkgs/g cc/4.3.1/include -L/usr/pkgs/gcc/4.3.1/lib -L/usr/pkgs/gcc/4.3.1/lib' So, you are suggesting that I should remove fPIC option, correct? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug c++/36625] missing diagnostic on invalid __attribute__((aligned(N)))
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-24 23:47 --- I think this is valid thing to do with aligned attribute. On the trunk we just get: t.cc: In instantiation of 'A123::S': t.cc:10: instantiated from here t.cc:3: error: requested alignment is not a constant I think we forgot to change the template argument here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36625
[Bug c++/36625] missing diagnostic on invalid __attribute__((aligned(N)))
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-24 23:49 --- Related to PR 19163. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36625
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-06-25 01:01 --- So, you are suggesting that I should remove fPIC option, correct? Yes. Is there a reason why you have CFLAGS set anyways? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #7 from imam dot toufique at intel dot com 2008-06-25 01:13 --- (In reply to comment #6) So, you are suggesting that I should remove fPIC option, correct? Yes. Is there a reason why you have CFLAGS set anyways? Hi Andrew, I have the CFLAGS for 2 reasons: 1. I have the mpfr and gmp libs in non standard locations, so I want to make sure that the gcc install looks at the correct places. 2. -fPIC has always been set in all the other gcc versions that I have compiled through CFLAGS. So, I did not think about this issue until you pointed it out. Now, I have a question: Do I need to exclude -fPIC for the other platform (e.g. x86_64) builds when I build gcc 4.3.1? I have tried building 4.3.1 in SLES10 with -fPIC option , and it built OK for me. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-06-25 01:15 --- 1. I have the mpfr and gmp libs in non standard locations, so I want to make sure that the gcc install looks at the correct places. That is what --with-gmp=/--with-mpfr= are for. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #9 from imam dot toufique at intel dot com 2008-06-25 01:18 --- (In reply to comment #8) 1. I have the mpfr and gmp libs in non standard locations, so I want to make sure that the gcc install looks at the correct places. That is what --with-gmp=/--with-mpfr= are for. Thanks. I will take that well into consideration. So, do you think I need to exclude all along '-fPIC' for the other platform specific builds of 4.3.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug c++/36626] New: traditional cast not recognized
This:
class a{
public:
static const signed long long int b = 1;
static const unsigned long long int c = unsigned long long int(b);
};
gets you this:
~/ootbc/asm$ g++ foo.cc
foo.cc:4: error: expected primary-expression before unsigned
foo.cc:4: error: expected ; before unsigned
--
Summary: traditional cast not recognized
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36626
