[Bug c++/38780] upgrade warning to error for bad C++ code ?
--- Comment #2 from dcb314 at hotmail dot com 2009-01-10 08:47 --- (In reply to comment #1) You can get an error via -pedantic-errors. Agreed - but switching on that flag opens a whole can of worms. All I'm interested in is getting this *one* warning changed into an error, for default use of the C++ compiler, without any kitchen sink flags that render other C++ code uncompilable. This has always been a warning for the C front-end so this change makes the C++ front-end consistent with the C front-end. AFAIK, both front ends should be erroring this kind of code, because it's neither ISO C nor ISO C++. gcc 4.3.2, at least in the Suse version, does it right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38780
[Bug c/32455] [4.2/4.3/4.4 regression] ICE with modified va_list, allows declaration of __builtin_*
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-10 09:04 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00644.html Ian Taylor's review: I'm not really comfortable with breaking the building of old version of glibc just to fix an ice-on-invalid. I'll approve this for gcc 4.5, to give people more time to update their glibc. So, moving to 4.5.0 target. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |jakub at gcc dot gnu dot org Target Milestone|4.2.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
[Bug testsuite/38790] New: syntax error in target selector
Due to revision 143234:
Author: joel
Date: Fri Jan 9 21:12:36 2009 UTC (14 hours, 12 minutes ago)
Log Message:
2009-01-09 Joel Sherrill joel.sherr...@oarcorp.com
* lib/target-supports.exp: Add method to determine if the effective
target is really a ppc405 after applying all compile options.
* gcc.target/powerpc/405-mulhhwu-2.c: Add dg-skip-if not ppc405.
* gcc.target/powerpc/405-nmachhw-1.c: Likewise.
* gcc.target/powerpc/405-nmaclhw-1.c: Likewise.
...
regtesting gcc fails with:
ERROR: gcc.target/powerpc/405-dlmzb-strlen-1.c: syntax error in target selector
target powerpc_405_nocache for dg-skip-if 6 other options override
-mcpu=405 { ! powerpc_405_nocache } { * } { }
UNRESOLVED: gcc.target/powerpc/405-dlmzb-strlen-1.c: syntax error in target
selector target powerpc_405_nocache for dg-skip-if 6 other options
override -mcpu=405 { ! powerpc_405_nocache } { * } { }
ERROR: gcc.target/powerpc/405-macchw-1.c: syntax error in target selector
target powerpc_405_nocache for dg-skip-if 6 other options override
-mcpu=405 { ! powerpc_405_nocache } { * } { }
UNRESOLVED: gcc.target/powerpc/405-macchw-1.c: syntax error in target selector
target powerpc_405_nocache for dg-skip-if 6 other options override
-mcpu=405 { ! powerpc_405_nocache } { * } { }
ERROR: gcc.target/powerpc/405-macchw-2.c: syntax error in target selector
target powerpc_405_nocache for dg-skip-if 6 other options override
-mcpu=405 { ! powerpc_405_nocache } { * } { }
UNRESOLVED: gcc.target/powerpc/405-macchw-2.c: syntax error in target selector
target powerpc_405_nocache for dg-skip-if 6 other options override
-mcpu=405 { ! powerpc_405_nocache } { * } { }
...
on powerpc (see http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00879.html and
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00883.html).
--
Summary: syntax error in target selector
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc*-*-*
GCC host triplet: powerpc*-*-*
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38790
[Bug testsuite/38791] New: FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
On i686-apple-darwin9 the test gcc/testsuite/gcc.dg/graphite/block-3.c introduced in revision 143159 fails with: [ibook-dhum] f90/bug% gcc44 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/graphite/block-3.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/graphite/block-3.c:6: error: size of array 'A' is too large -- Summary: FAIL: gcc.dg/graphite/block-3.c (test for excess errors) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug c++/36695] [4.3/4.4 Regression] Value-initialization of reference type is allowed.
--- Comment #7 from jakub at gcc dot gnu dot org 2009-01-10 11:48 --- Subject: Bug 36695 Author: jakub Date: Sat Jan 10 11:48:06 2009 New Revision: 143244 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143244 Log: PR c++/36695 * typeck2.c (build_functional_cast): Check for reference type and NULL PARMS. * g++.dg/ext/complex4.C: New test. * g++.dg/ext/complex5.C: New test. * g++.dg/init/reference1.C: New test. * g++.dg/init/reference2.C: New test. * g++.dg/init/reference3.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/complex4.C trunk/gcc/testsuite/g++.dg/ext/complex5.C trunk/gcc/testsuite/g++.dg/init/reference1.C trunk/gcc/testsuite/g++.dg/init/reference2.C trunk/gcc/testsuite/g++.dg/init/reference3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36695
[Bug c++/38648] [4.2/4.3/4.4 regression] ICE with string literal
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-10 11:49 --- Subject: Bug 38648 Author: jakub Date: Sat Jan 10 11:49:04 2009 New Revision: 143245 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143245 Log: PR c++/38648 * typeck.c (cp_build_modify_expr): Check for NULL current_function_decl. * g++.dg/expr/string-1.C: New test. * g++.dg/expr/string-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/string-1.C trunk/gcc/testsuite/g++.dg/expr/string-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38648
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #1 from dominiq at lps dot ens dot fr 2009-01-10 11:49 --- I have forgotten to say that the failure occurs in 32 bit mode, but disappears with -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug c++/36695] [4.3 Regression] Value-initialization of reference type is allowed.
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-10 11:50 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.2 4.3.3 4.4.0 |4.3.2 4.3.3 Known to work|4.1.1 4.0.2 |4.1.1 4.0.2 4.4.0 Summary|[4.3/4.4 Regression] Value- |[4.3 Regression] Value- |initialization of reference |initialization of reference |type is allowed.|type is allowed. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36695
[Bug c++/38648] [4.2/4.3 regression] ICE with string literal
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-10 11:51 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.3.3 4.3.0 4.1.1 4.3.0 |3.3.3 4.3.0 4.1.1 4.3.0 |4.4.0 | Known to work||4.4.0 Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3 regression] ICE |with string literal |with string literal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38648
[Bug target/38695] [4.4 regression] gcc.c-torture/compile/pr37433.c ICE on trunk arm_function_in_section_p
--- Comment #6 from laurent at guerby dot net 2009-01-10 12:41 --- Jakub, your patch fixes all pr37433.c FAIL, thanks! Test results http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00868.html This also seem to fix an ICE I did not report but visible here in previous test results: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00665.html Executing on host: /home/guerby/build-143046/gcc/xgcc -B/home/guerby/build-143046/gcc/ -O1 -w -c -o 920625-1.o /n/50/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c(timeout = 300) /n/50/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c: In function 'synth':^M /n/50/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c:298: internal compiler error: Segmentation fault^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M compiler exited with status 1 output is: /n/50/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c: In function 'synth':^M /n/50/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c:298: internal compiler error: Segmentation fault^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M FAIL: gcc.c-torture/compile/920625-1.c -O1 (internal compiler error) Comparison between test results: --- /tmp/z0 2009-01-10 13:36:02.0 +0100 +++ /tmp/z1 2009-01-10 13:33:37.0 +0100 @@ -1,2 +0,0 @@ -FAIL: gcc.c-torture/compile/920625-1.c -O1 (internal compiler error) -FAIL: gcc.c-torture/compile/920625-1.c -O1 (test for excess errors) @@ -19,10 +16,0 @@ -FAIL: gcc.c-torture/compile/pr37433.c -O1 (internal compiler error) -FAIL: gcc.c-torture/compile/pr37433.c -O1 (test for excess errors) -FAIL: gcc.c-torture/compile/pr37433.c -O2 (internal compiler error) -FAIL: gcc.c-torture/compile/pr37433.c -O2 (test for excess errors) -FAIL: gcc.c-torture/compile/pr37433.c -O3 -fomit-frame-pointer (internal compiler error) -FAIL: gcc.c-torture/compile/pr37433.c -O3 -fomit-frame-pointer (test for excess errors) -FAIL: gcc.c-torture/compile/pr37433.c -O3 -g (internal compiler error) -FAIL: gcc.c-torture/compile/pr37433.c -O3 -g (test for excess errors) -FAIL: gcc.c-torture/compile/pr37433.c -Os (internal compiler error) -FAIL: gcc.c-torture/compile/pr37433.c -Os (test for excess errors) I guess it's okay to seek approval to commit this patch :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38695
[Bug bootstrap/38792] New: RFE - Need Makefile to build using different strategy for coverage vs. profiling
+++ This bug was initially created as a clone of Bug #38776 +++ Request For Enhancement I woukd like the created Makefile to build gcc using a different strategy (compilation course) for coverage versus the strategy it uses for profiling. Both build strategies seems to follow the same course of multi-stage compilation with only small changes in the gcc options depending on whether coverage, profiling or both (really slow) is desired. I'm building gcc 4.4.0 20090109 on i386-pc-solaris2.11 (OpenSolaris 2008.11) using gcc version 4.4.0 20090104. I have configured using --enable-coverage=noopt and started the build using gmake. I have also configured without the --enable-coverage= option and started the make using gmake profiledbootstrap. From what I can tell by observing the output from Make and examining the scripts and Makefiles is that by trying to build for coverage and/or profiling it seems to follow a similar course of: 1. building the option into the compiler early and then 2. using the altered-compiler for the remaining stages. My point: For Profiling (no additional ./configure options and initiate the 'make' by typing gmake profiledbootstrap) it makes (at least some) sense to build-in Profiling early and then profile _all_ parts of the compiler to find the speed of _all_ parts. It is a slow process to check _everything_ but without looking _everywhere_ you can't get the answer you need. For Coverage (use the additional ./configure option of --enable-coverage=noopt and initiate the 'make' by typing gmake) it makes _VERY_ little sense to build-in Coverage early and then check the coverage of _all_ parts of the compiler to find if we use all of _all_ parts. We most likely do not. Will that day ever come? No. If we did not use some portion of the toolchain in the build would we then remove the code ? I think not. We do not care about the coverage _during_ the build, it is likely most useful either for use compiling our own Testsuite (to ensure we test _ALL_ the parts of the Toolchain) or by the end user to test their own code. We need a fast C compiler (and C++ compiler) to compile for coverage the _other_ Tools but we do NOT need the C compiler to check it's own coverage while it builds coverage into everything else that is TOO SLOW. What I propose it that we have a new Makefile Target, we could call it by typing make coveragebootstrap. The NEW course of compilation for building coverage would be to: 1. Build the C and C++ compiler _without_ coverage to create xgcc. 2. Build the remaining Languages _with_ coverage (using the non-coverage- altered-xgcc or xg++ compilers, which will be _much_ faster). 3. Build the Libraries _with_ coverage (using the non-coverage-altered-xgcc or xg++ compiler). 4. Go back and rebuild the C++ compiler _with_ coverage (using the non-coverage-altered-xgcc compiler). 5. Go back and rebuild the C compiler _with_ coverage (using the non- coverage-altered-xgcc compiler). 6. Now all Tools and Libraries will be built _with_ coverage by a compiler _without_ coverage (and the associated constant updating of the statistics files). 7. You can install now by typing make install and get a Toolchain that when executed will save it's statistics files with it's executables (with the source code remaining where it is) 8. You can execute the Testsuite by typing make -i check and check the coverage of the Testsuite. This is probably the 'most-intended' feature of coverage, best to get it operating fast than letting it build slow. The only downside it that in exchange for being able to compile the Toolchain much quicker is that you won't be able to determine if every portion of the C compiler was used to compile the C compiler. Chances are good that we do not use _all_ of the C compiler to compile gcc and that we won't be ripping out all the code we don't use. Loss of this feature means loss of nothing since we can always use the Makefile the old-way if we would wish to. Questions? Thanks for reading this, Rob -- Summary: RFE - Need Makefile to build using different strategy for coverage vs. profiling Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: *-*-*-* GCC host triplet: *-*-*-* GCC target triplet: *-*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38792
[Bug middle-end/38694] gcc.c-torture/compile/pr11832.c and pr33009.c -frtl-abstract-sequences ICE on arm-linux-gnueabi on 4.3.2 and trunk
--- Comment #3 from laurent at guerby dot net 2009-01-10 13:08 --- http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00868.html Might be related to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642 Looks like the solution has been to disable those tests on a long list of platforms. May be it's better to just remove -frtl-abstract-sequences from GCC if it works nearly nowhere? -- laurent at guerby dot net changed: What|Removed |Added Summary|gcc.c- |gcc.c- |torture/compile/pr11832.c |torture/compile/pr11832.c |ICE on arm-linux-gnueabi on |and pr33009.c -frtl- |4.3.2 and trunk |abstract-sequences ICE on ||arm-linux-gnueabi on 4.3.2 ||and trunk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38694
[Bug target/38703] testsuite __gnu_mcount_nc link error when profiling on arm
--- Comment #4 from laurent at guerby dot net 2009-01-10 13:10 --- List of tests with undefined reference to `__gnu_mcount_nc' FAIL: gcc.dg/20021014-1.c (test for excess errors) FAIL: gcc.dg/nest.c (test for excess errors) FAIL: gcc.dg/nested-func-4.c (test for excess errors) FAIL: gcc.dg/pr32450.c (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38703
[Bug c/38793] New: SH: unable to find a register to spill in class 'R0_REGS'
gcc4.3.3 snapshot fail to compile with this message.
ada-lex.l:456: error: unable to find a register to spill in class 'R0_REGS'
ada-lex.l:456: error: this is the insn:
(insn:HI 249 374 275 48 ada-lex.l:451 (set (mem:QI (plus:SI (reg/v/f:SI 12 r12
[
orig:174 value ] [174])
(reg:SI 2 r2 [orig:171 prephitmp.1236 ] [171])) [0 S1 A8])
(reg:QI 1 r1 [244])) 182 {movqi_i} (expr_list:REG_DEAD (reg:QI 1 r1
[244
])
(expr_list:REG_DEAD (reg/v/f:SI 12 r12 [orig:174 value ] [174])
(expr_list:REG_DEAD (reg:SI 2 r2 [orig:171 prephitmp.1236 ] [171])
(expr_list:REG_EQUAL (const_int 0 [0x0])
(nil))
ada-lex.l:456: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/cccHZxYV.out file, please attach this to
yo
ur bugreport.
$ sh4-unknown-linux-gnu-gcc -v
Using built-in specs.
Target: sh4-unknown-linux-gnu
Configured with:
/home/chika/tmp/cross/gcc/crosstool-snv/targets/src/gcc-4.3.3/configure
--build=x86_64-unknown-linux-gnu --target=sh4-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu
--prefix=/home/chika/x-tools/sh4-unknown-linux-gnu
--with-sysroot=/home/chika/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root
--enable-languages=c,c++,fortran,java,objc,obj-c++ --disable-multilib
--with-gmp=/home/chika/x-tools/sh4-unknown-linux-gnu
--with-mpfr=/home/chika/x-tools/sh4-unknown-linux-gnu --enable-__cxa_atexit
--with-local-prefix=/home/chika/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
Thread model: posix
gcc version 4.3.3 20090109 (prerelease) (GCC)
--
Summary: SH: unable to find a register to spill in class
'R0_REGS'
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: masaki dot chikama at gmail dot com
GCC target triplet: sh-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38793
[Bug c/38793] SH: unable to find a register to spill in class 'R0_REGS'
--- Comment #1 from masaki dot chikama at gmail dot com 2009-01-10 13:27 --- Created an attachment (id=17069) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17069action=view) cccHZxYV.out preprocessed file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38793
[Bug c/38793] SH: unable to find a register to spill in class 'R0_REGS'
--- Comment #2 from masaki dot chikama at gmail dot com 2009-01-10 13:29
---
Created an attachment (id=17070)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17070action=view)
test.c
reduced test case for -O2
$ sh4-unknown-linux-gnu-gcc -O2 test.c
test.c: In function 'f2':
test.c:35: error: unable to find a register to spill in class 'R0_REGS'
test.c:35: error: this is the insn:
(insn:HI 17 61 37 4 test.c:31 (set (mem:QI (plus:SI (reg/v/f:SI 3 r3 [orig:162
n ] [162])
(reg/v:SI 1 r1 [orig:161 i ] [161])) [0 S1 A8])
(reg:QI 2 r2 [169])) 182 {movqi_i} (expr_list:REG_DEAD (reg:QI 2 r2
[169])
(expr_list:REG_DEAD (reg/v/f:SI 3 r3 [orig:162 n ] [162])
(expr_list:REG_DEAD (reg/v:SI 1 r1 [orig:161 i ] [161])
(expr_list:REG_EQUAL (const_int 0 [0x0])
(nil))
test.c:35: confused by earlier errors, bailing out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38793
[Bug middle-end/38696] gcc.dg/torture/pr37868.c wrong code at -O2 and above for 4.3 and trunk / bit packing
--- Comment #2 from laurent at guerby dot net 2009-01-10 13:31 ---
You mean adding:
/* { dg-skip-if unaligned access { arm*-*-* } * } */
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38696
[Bug target/38695] [4.4 regression] gcc.c-torture/compile/pr37433.c ICE on trunk arm_function_in_section_p
--- Comment #7 from jakub at gcc dot gnu dot org 2009-01-10 14:02 --- Subject: Bug 38695 Author: jakub Date: Sat Jan 10 14:02:12 2009 New Revision: 143246 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143246 Log: PR target/38695 * config/arm/arm.c (arm_is_long_call_p): Don't call arm_function_in_section_p if decl isn't a FUNCTION_DECL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38695
[Bug target/38695] [4.4 regression] gcc.c-torture/compile/pr37433.c ICE on trunk arm_function_in_section_p
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-10 14:03 --- 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=38695
[Bug c/38778] the result when excuted with loop-linear on is different to that with O0
--- Comment #5 from yu19820428 at 163 dot com 2009-01-10 15:28 --- Of course, it is a weird situation. Nobody use the options like this. However, it is indeed a problem in 4.2.4. I do not know it has been fixed in 4.3.* or not, because some other options may have effect on it so that it did not appear in 4.3.* any more. My study is to verify the correctness of compiler optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38778
[Bug tree-optimization/38785] huge performance regression on EEMBC bitmnp01
--- Comment #6 from amylaar at gcc dot gnu dot org 2009-01-10 16:10 --- (In reply to comment #5) Joern, re. comment #4, Richi refers to my patch to enable PRE at -Os, see [1]. An extension to this patch that we tested on x86 machines, is to disable PRE for scalar integer registers, via SMALL_REGISTER_CLASSES. I changed SMALL_REGISTER_CLASSES into a target hook for this purpose, see [2]. You could play with this, see if you can use this to cure your problem... This is not a problem of having inserted more expressions. The expressions actually go down, 7 add expressions are actually eliminated. The problem is that this comes at the cost of addding 127 phi nodes which are not free. It's a cascade of 64/32/16/8/4/2/1 phi nodes that are used to compute the 7 chained adds through all the possible paths through the 6 consecutive if-blocks, and this requires 64/32/16/8/4/2/1 reg-reg copies to implement inside these if-blocks, plus 64 unconditional constant loads at the start. requiring 64 + x registers for this one computation alone does cause register allocation trouble for ARCompact, but it is in good company here, as lost of other RISC architectures also have no more than 32 general purpose registers. And even if you did this for a processor with lots of registers like the i960, requiring 64 constant loads in the unconditional path and then having 127 conditional reg-reg copies is certainly worse than having 7 conditional add operations. I think the problem is that the algorithm, like many SSA algorithm, has no idea of the run time cost of a phi node, and uses the lower bound 0 as an approximation. As you make more sophisticated algorithms to approximate the cost minimum for a flawed cost function, you will pessimize more and more code. Is there a way to determine when replacing one expression causes the number of phi nodes in a dominator to increase? I would think that this criterion would be a possibly useful indicator of register pressure and instruction count increase. I haven't looked wht the ssa pre does exactly, but from the code transformation performed I would guess that it sees one expression which is fed by a directed acyclic graph (DAG) of phi nodes with constant leaves, and figures it only needs to use a replacement DAG of phi nodes where the expression is evaluated for each constant, assuming that the original DAG will be mostly dead then. However, what happens in the testcase is that the original DAG is still fully live, the replacement DAG is added in parallel, and thus the number of phi nodes from the original DAG has been doubled. For the testcase (and for fbital, if you have access to it), it is interesting to observe that the problem would not arise if pre had a notion of what expressions better to leave for conditional execution. Unfortunately, many architectures, conditional execution requires two-address (wrt the ALU) operations, which cannot be expressed in SSA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-10 16:35 --- Subject: Re: fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath On Fri, 09 Jan 2009, bkoz at gcc dot gnu dot org wrote: Any chance I could get a generated c++config.h from a native HPUX 10.x build as well? Attached. Dave --- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-10 16:35 --- Created an attachment (id=17071) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17071action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug c++/38625] Segmentation fault when dereferencing valid pointer, probably REGRESSION
--- Comment #6 from l dot jirkovsky at gmail dot com 2009-01-10 16:42 --- I've tried it with gcc 4.2.4 and it works perfectly, so it have to be caused by some change between 4.2.4 and 4.3.2. I'll try to use svn to find out which commit causes this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38625
[Bug c++/38794] New: [4.2/4.3/4.4 regression] Function body accepted in typedef
The following invalid code snippet is accepted in GCC 4.2.0:
===
typedef int foo() {}
===
--
Summary: [4.2/4.3/4.4 regression] Function body accepted in
typedef
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38794
[Bug c++/38794] [4.2/4.3/4.4 regression] Function body accepted in typedef
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38794
[Bug c++/38625] Segmentation fault when dereferencing valid pointer, probably REGRESSION
--- Comment #7 from l dot jirkovsky at gmail dot com 2009-01-10 16:47 --- I've forgot to post info about gcc 4.2.4: $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.4/configure --prefix=/home/lukas/gcc --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit Thread model: posix gcc version 4.2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38625
[Bug c++/38794] [4.2/4.3/4.4 regression] Function body accepted in typedef
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-01-10 16:48 --- The following invalid code snippet is accepted in GCC 4.2.0: That should be since GCC 4.2.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38794
[Bug c++/38795] New: [4.3/4.4 regression] ICE with reinterpret_cast and variadic templates
The following invalid code snippet is triggers an ICE since GCC 4.3.0:
templatetypename... T int foo(int i)
{
return *reinterpret_castT*(i);
}
void bar(int i)
{
fooint(i);
}
bug.cc: In function 'int foo(int) [with T = int]':
bug.cc:8: instantiated from here
bug.cc:3: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_conversions,
at cp/search.c:2459
Please submit a full bug report, [etc.]
It's a regression because the code crashes even without -std=gnu++0x.
--
Summary: [4.3/4.4 regression] ICE with reinterpret_cast and
variadic templates
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38795
[Bug c++/38795] [4.3/4.4 regression] ICE with reinterpret_cast and variadic templates
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38795
[Bug c++/38796] New: [c++0x] defaulted operator= with non-default return type accepted
The following invalid code is accepted on the trunk:
struct A
{
void operator= (const A) = default;
};
Because the return type is not A, but void the operator=
cannot be the defaulted.
In fact GCC silently changes the return type, as the following code
snippet is accepted:
struct A
{
void operator= (const A) = default;
};
void foo()
{
A a, b, c;
a = b = c;
}
When I remove the default, I get a correct error message:
bug.cc: In function 'void foo()':
bug.cc:9: error: no match for 'operator=' in 'a = b.A::operator=(((const
A)((const A*)( c'
bug.cc:3: note: candidates are: void A::operator=(const A)
This is probably related to PR38649.
--
Summary: [c++0x] defaulted operator= with non-default return type
accepted
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38796
[Bug libfortran/38772] r143102 breaks xplor-nih
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-01-10
19:57 ---
Jerry,
If I use the following patch to xplor-nih
--- xrmani.f.org2009-01-09 17:48:46.0 -0500
+++ xrmani.f2009-01-10 14:29:42.0 -0500
@@ -363,6 +363,7 @@
END IF
END DO
C
+ write(6,*) 'before if ', H, K, L, WD
IF (.NOT.COND) THEN
CALL SAVEWD
OK=.TRUE.
@@ -375,7 +376,9 @@
CALL XAB(FOBS(REFLCT),AFOBS,PFOBS*RAD)
C
ELSE
+ write(6,*) 'before chkend ', H, K, L, WD
CALL CHKEND('REFLection',DONE)
+ write(6,*) 'after chkend ', H, K, L, WD
END IF
END IF
IF (.NOT. (DONE)) goto 137
I find that without r14310, I get...
before if4 0 7 INDEX
before if4 1 7 END
before chkend4 1 7 END
after chkend4 1 7 END
whereas with r143102, I get...
before if4 0 7 INDEX
before if4 1 7 FWINDOW
before chkend4 1 7 FWINDOW
%REFLection-ERR: unrecognized command:
fwindow
^^^
after chkend4 1 7 FWINDOW
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug fortran/38665] [4.3 Regression] ICE in check_host_association
--- Comment #9 from pault at gcc dot gnu dot org 2009-01-10 21:01 --- Subject: Bug 38665 Author: pault Date: Sat Jan 10 21:01:14 2009 New Revision: 143248 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143248 Log: 2009-01-10 Paul Thomas pa...@gcc.gnu.org PR fortran/38665 * gfortran.h : Add bit to gfc_expr 'user_operator' * interface.c (gfc_extend_expr): Set the above if the operator is substituted by a function. * resolve.c (check_host_association): Return if above is set. 2009-01-10 Paul Thomas pa...@gcc.gnu.org PR fortran/38665 * gfortran.dg/host_assoc_function_5.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_function_5.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/gfortran.h branches/gcc-4_3-branch/gcc/fortran/interface.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
[Bug fortran/38657] [4.3 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #10 from pault at gcc dot gnu dot org 2009-01-10 21:06 --- Subject: Bug 38657 Author: pault Date: Sat Jan 10 21:06:27 2009 New Revision: 143249 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143249 Log: 2009-01-10 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * module.c (write_common_0): Use the name of the symtree rather than the common block, to determine if the common has been written. 2009-01-10 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * gfortran.dg/module_commons_3.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/module_commons_3.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug fortran/38665] [4.3 Regression] ICE in check_host_association
--- Comment #10 from pault at gcc dot gnu dot org 2009-01-10 21:25 --- Subject: Bug 38665 Author: pault Date: Sat Jan 10 21:24:54 2009 New Revision: 143250 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143250 Log: 2009-01-10 Paul Thomas pa...@gcc.gnu.org PR fortran/38665 * gfortran.dg/host_assoc_function_5.f90: Clean up extraneous. Modified: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_function_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #2 from sebpop at gmail dot com 2009-01-10 21:32 --- Subject: Re: FAIL: gcc.dg/graphite/block-3.c (test for excess errors) Does the attached patch fix the fail? Thanks, Sebastian --- Comment #3 from sebpop at gmail dot com 2009-01-10 21:32 --- Created an attachment (id=17072) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17072action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug fortran/38665] [4.3 Regression] ICE in check_host_association
--- Comment #11 from pault at gcc dot gnu dot org 2009-01-10 21:41 --- Subject: Bug 38665 Author: pault Date: Sat Jan 10 21:41:16 2009 New Revision: 143252 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143252 Log: 2009-01-10 Paul Thomas pa...@gcc.gnu.org PR fortran/38665 * gfortran.dg/host_assoc_function_5.f90: Clean up extraneous. Modified: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_function_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
[Bug fortran/38665] [4.3 Regression] ICE in check_host_association
--- Comment #12 from pault at gcc dot gnu dot org 2009-01-10 21:44 --- Fixed on trunk and latest 4.3 Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
[Bug fortran/38665] [4.3 Regression] ICE in check_host_association
--- Comment #13 from pault at gcc dot gnu dot org 2009-01-10 21:44 --- Fixed on trunk and latest 4.3 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
[Bug fortran/38657] [4.3 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #11 from pault at gcc dot gnu dot org 2009-01-10 21:45 --- Fixed on trunk and 4.3 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug c++/38797] New: [c++0x] Missing warning about type qualifiers on late function return types
Compiling the following code snippet with -Wall -Wextra -std=gnu++0x results in a warning for the first line, but not for the second: == const int foo(); auto bar() - const int; == bug.cc:1: warning: type qualifiers ignored on function return type -- Summary: [c++0x] Missing warning about type qualifiers on late function return types Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38797
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #4 from dominiq at lps dot ens dot fr 2009-01-10 22:03 ---
Does the attached patch fix the fail?
With the patch the test compiles (it does with M up to 812) and the Strip
Mining is done for the second nested loops:
for (s_1=0;s_1=1;s_1++) {
for (s_3=0;s_3=1;s_3++) {
for (s_5=0;s_5=1;s_5++) {
for (s_7=64*s_1;s_7=min(64*s_1+63,99);s_7++) {
for (s_9=64*s_3;s_9=min(64*s_3+63,99);s_9++) {
for (s_11=64*s_5;s_11=min(64*s_5+63,99);s_11++) {
S13(s_1,s_3,s_5,s_7,s_9,s_11) ;
}
}
}
}
}
}
I don't know how I can test this file alone without regtesting all gcc (I
tried: make -k check-gcc RUNTESTFLAGS=dg.exp=graphite/block-3.c without
success).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-01-10 22:06 --- I don't know how I can test this file alone without regtesting all gcc (I tried: make -k check-gcc RUNTESTFLAGS=dg.exp=graphite/block-3.c without success). Try make -k check-gcc RUNTESTFLAGS=graphite.exp=block-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #6 from dominiq at lps dot ens dot fr 2009-01-10 22:09 --- Try make -k check-gcc RUNTESTFLAGS=graphite.exp=block-3.c Thanks, then I get: Running /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.dg/graphite/graphite.exp ... === gcc Summary === # of expected passes1 /Volumes/MacBook/opt/gcc/i686-darwin/gcc/xgcc version 4.4.0 20090110 (experimental) [trunk revision 143247p1] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug c++/38798] New: [c++0x] Trouble with struct/class/enum keyword in late return types
The following (IMHO valid) code snippet is rejected on trunk:
==
struct A {};
auto foo() - struct A {}
==
bug.cc:2: error: redefinition of 'struct A'
bug.cc:1: error: previous definition of 'struct A'
bug.cc:2: error: expected initializer at end of input
Apparently {} is not treated as the function body, but as definition
of struct A. According to n2541, late function return types are type-ids.
Therefore {} shouldn't be parsed as type definition IMHO.
Btw, the following invalid code snippet is accepted:
==
auto foo() - struct A {} {}
==
Again the first pair of {}'s is parsed as type definition.
In addition, the compiler doesn't complain about defining types
in a return type which has always been forbidden.
The same happens for enums:
==
enum E { e };
auto foo() - enum E {}
==
==
auto foo() - enum E {} {}
==
--
Summary: [c++0x] Trouble with struct/class/enum keyword in late
return types
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid, accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38798
[Bug c++/38799] New: using declaration appears to hide local declaration
When a namespace declares a function, and then uses another function with the
same name from a different namespace, the using declaration seems to hide the
function declaration. At least, when I define the function body later, the
comiler complains that the function wasn't declared in the namespace. However,
if I use the function first, and THEN declare it in the namespace, the
definition of the function is accepted. (It's easer to show code than explain.
See below.)
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --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.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic'
/usr/lib/gcc/i486-linux-gnu/4.3.2/cc1plus -E -quiet -v -D_GNU_SOURCE asdf.cpp
-D_FORTIFY_SOURCE=2 -mtune=generic -fpch-preprocess -o asdf.ii
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.3
/usr/include/c++/4.3/i486-linux-gnu
/usr/include/c++/4.3/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.3.2/include
/usr/lib/gcc/i486-linux-gnu/4.3.2/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic'
/usr/lib/gcc/i486-linux-gnu/4.3.2/cc1plus -fpreprocessed asdf.ii -quiet
-dumpbase asdf.cpp -mtune=generic -auxbase asdf -version -fstack-protector -o
asdf.s
GNU C++ (Ubuntu 4.3.2-1ubuntu11) version 4.3.2 (i486-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: dc8f858cacda993dd8f70837f0d9565d
asdf.cpp:15: error: void A::f(int) should have been declared inside A
Source Code:
void f() {}
namespace A {
void f(int);
using ::f;
}
//
// With the function declaration in namespace A appearing first, the
// implementation below fails to compile. Switch the order (such that the
// using appears first) and then it compiles.
//
// g++ /tmp/asdf.cpp
// /tmp/asdf.cpp:15: error: void A::f(int) should have been declared inside
A
void A::f(int a) {}
int main() {
A::f(1);
}
--
Summary: using declaration appears to hide local declaration
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cuzdav at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38799
[Bug testsuite/25241] [C++] DejaGNU does not distinguish between errors and warnings
--- Comment #67 from reichelt at gcc dot gnu dot org 2009-01-10 22:37 --- Fixed by Janis' and Manuel's patches. -- reichelt 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=25241
[Bug c++/38799] using declaration appears to hide local declaration
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-10 22:47 --- This is how it should behave. -- 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=38799
[Bug bootstrap/35211] Dist tarball is missing (Bison-generated) java/parse-scan.c
--- Comment #3 from rob1weld at aol dot com 2009-01-10 23:59 --- (In reply to comment #1) Is this still true in newer GCC releases? Also this was removed in 4.3 and above. Yes, on trunk. Searching for dupe before starting a new Bug Report, came here. We might close this Bug with a comment on the Prerequisites page that you _might_ need bison in the event that you (or a Makefile, broken or otherwise) modify a `.y' file. This webpage does not mention the program bison: Prerequisites for GCC http://gcc.gnu.org/install/prerequisites.html # prev-gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --with-long-double-128 --enable-nls --with-included-gettext --enable-gather-detailed-mem-stats --with-stabs --enable-debug -enable-largefile --enable-symvers --without-system-zlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug --enable-libgcj-multifile --enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug --enable-stage1-checking --enable-checking=release --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090109 (experimental) (GCC) # gmake ... gmake[3]: Leaving directory `/usr/share/src/gcc_build/libiberty' gmake[3]: Entering directory `/usr/share/src/gcc_build/intl' rm -f stamp-h1 /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged test -f config.h || (rm -f stamp-h1 gmake stamp-h1) cp ../../gcc_trunk/intl/libgnuintl.h libintl.h /usr/share/src/gcc_build/./prev-gcc/xgcc ... ... /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/gcc_build/./prev-gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -c -fexceptions -g -O2 -fprofile-use -DHAVE_CONFIG_H -I. -I../../gcc_trunk/intl ../../gcc_trunk/intl/ngettext.c ../../gcc_trunk/intl/ngettext.c: In function libintl_ngettext: ../../gcc_trunk/intl/ngettext.c:63: note: file /usr/share/src/gcc_build/intl/ngettext.gcda not found, execution counts estimated bison -y --name-prefix=__gettext --output plural.c ../../gcc_trunk/intl/plural.y rm -f plural.h /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/gcc_build/./prev-gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -c -fexceptions -g -O2 -fprofile-use -DHAVE_CONFIG_H -I. -I../../gcc_trunk/intl plural.c ... I did not modify a `.y' file or play with this part of the code. The reason that I require bison is either: 1. I 'hit it' with my configure option combination and found an untried path. 2. Typing make distclean removed a file (I did not see that happen). 3. Something is broken and bison was not really needed. 4. The Prerequisites for GCC is incorrect, we do need bison. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35211
Re: [Bug bootstrap/35211] Dist tarball is missing (Bison-generated) java/parse-scan.c
On Jan 10, 2009, at 3:59 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from rob1weld at aol dot com 2009-01-10 23:59 --- (In reply to comment #1) Is this still true in newer GCC releases? Also this was removed in 4.3 and above. Yes, on trunk. Searching for dupe before starting a new Bug Report, came here. We might close this Bug with a comment on the Prerequisites page that you _might_ need bison in the event that you (or a Makefile, broken or otherwise) modify a `.y' file. This webpage does not mention the program bison: Prerequisites for GCC http://gcc.gnu.org/install/prerequisites.html We only require yacc (bison is a yacc) when compiling GCC from the svn or from the snapshots. Plus most os's already contain a yacc. # prev-gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --with-long-double-128 -- enable-nls --with-included-gettext --enable-gather-detailed-mem-stats --with- stabs --enable-debug -enable-largefile --enable-symvers --without-system- zlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug --enable-libgcj-multifile --enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug --enable-stage1-checking --enable- checking=release --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090109 (experimental) (GCC) # gmake ... gmake[3]: Leaving directory `/usr/share/src/gcc_build/libiberty' gmake[3]: Entering directory `/usr/share/src/gcc_build/intl' rm -f stamp-h1 /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged test -f config.h || (rm -f stamp-h1 gmake stamp-h1) cp ../../gcc_trunk/intl/libgnuintl.h libintl.h /usr/share/src/gcc_build/./prev-gcc/xgcc ... ... /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/ gcc_build/./prev-gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -c -fexceptions -g -O2 - fprofile-use -DHAVE_CONFIG_H -I. -I../../gcc_trunk/intl ../../gcc_trunk/intl/ ngettext.c ../../gcc_trunk/intl/ngettext.c: In function ‘libintl_ngettext’: ../../gcc_trunk/intl/ngettext.c:63: note: file /usr/share/src/gcc_build/intl/ngettext.gcda not found, execution counts estimated bison -y --name-prefix=__gettext --output plural.c ../../gcc_trunk/intl/plural.y rm -f plural.h /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/ gcc_build/./prev-gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -c -fexceptions -g -O2 - fprofile-use -DHAVE_CONFIG_H -I. -I../../gcc_trunk/intl plural.c ... I did not modify a `.y' file or play with this part of the code. The reason that I require bison is either: 1. I 'hit it' with my configure option combination and found an untried path. 2. Typing make distclean removed a file (I did not see that happen). 3. Something is broken and bison was not really needed. 4. The Prerequisites for GCC is incorrect, we do need bison. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35211
[Bug bootstrap/35211] Dist tarball is missing (Bison-generated) java/parse-scan.c
--- Comment #4 from pinskia at gmail dot com 2009-01-11 00:11 --- Subject: Re: Dist tarball is missing (Bison-generated) java/parse-scan.c On Jan 10, 2009, at 3:59 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from rob1weld at aol dot com 2009-01-10 23:59 --- (In reply to comment #1) Is this still true in newer GCC releases? Also this was removed in 4.3 and above. Yes, on trunk. Searching for dupe before starting a new Bug Report, came here. We might close this Bug with a comment on the Prerequisites page that you _might_ need bison in the event that you (or a Makefile, broken or otherwise) modify a `.y' file. This webpage does not mention the program bison: Prerequisites for GCC http://gcc.gnu.org/install/prerequisites.html We only require yacc (bison is a yacc) when compiling GCC from the svn or from the snapshots. Plus most os's already contain a yacc. # prev-gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --with-long-double-128 -- enable-nls --with-included-gettext --enable-gather-detailed-mem-stats --with- stabs --enable-debug -enable-largefile --enable-symvers --without-system- zlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug --enable-libgcj-multifile --enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug --enable-stage1-checking --enable- checking=release --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090109 (experimental) (GCC) # gmake ... gmake[3]: Leaving directory `/usr/share/src/gcc_build/libiberty' gmake[3]: Entering directory `/usr/share/src/gcc_build/intl' rm -f stamp-h1 /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged test -f config.h || (rm -f stamp-h1 gmake stamp-h1) cp ../../gcc_trunk/intl/libgnuintl.h libintl.h /usr/share/src/gcc_build/./prev-gcc/xgcc ... ... /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/ gcc_build/./prev-gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -c -fexceptions -g -O2 - fprofile-use -DHAVE_CONFIG_H -I. -I../../gcc_trunk/intl ../../gcc_trunk/intl/ ngettext.c ../../gcc_trunk/intl/ngettext.c: In function âlibintl_ngettextâ: ../../gcc_trunk/intl/ngettext.c:63: note: file /usr/share/src/gcc_build/intl/ngettext.gcda not found, execution counts estimated bison -y --name-prefix=__gettext --output plural.c ../../gcc_trunk/intl/plural.y rm -f plural.h /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/ gcc_build/./prev-gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -c -fexceptions -g -O2 - fprofile-use -DHAVE_CONFIG_H -I. -I../../gcc_trunk/intl plural.c ... I did not modify a `.y' file or play with this part of the code. The reason that I require bison is either: 1. I 'hit it' with my configure option combination and found an untried path. 2. Typing make distclean removed a file (I did not see that happen). 3. Something is broken and bison was not really needed. 4. The Prerequisites for GCC is incorrect, we do need bison. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35211 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35211
[Bug target/38621] [4.3/4.4 Regression] sh gcc unable to spill register when building ghostscript-gpl with -O2
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-01-11 01:29 --- *** Bug 38793 has been marked as a duplicate of this bug. *** -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||masaki dot chikama at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38621
[Bug target/38793] SH: unable to find a register to spill in class 'R0_REGS'
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-01-11 01:29 --- Again, the insn scheduling before reload permutes the insns of the exit basic block like as: ;; == ;; -- basic block 5 from 16 to 30 -- before reload ;; == ;;0--49 r162=0x0 :issue,int ;;1--16 r169=0x0 :issue,int ;;1--36 r0=r162 :issue ;;2--50 r159=0x0 :issue,int ;;2--17 [r162+r161]=r169 :(issue+load_store),nothing,memory ;;3--37 r1=r159 :issue ;;3--30 use r0:nothing ;; Ready list (final): ;; total time = 3 ;; new head = 16 ;; new tail = 30 This is a duplicate of 38621. *** This bug has been marked as a duplicate of 38621 *** -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Component|c |target Priority|P3 |P4 Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38793
[Bug bootstrap/38792] RFE - Need Makefile to build using different strategy for coverage vs. profiling
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-11 01:56 --- Coverage means -fprofile-arcs only while profiling means -fprofile-generate/-fprofile-use. Coverage is only useful when you are looking into GCC's sources to see what code is being used and how much. Coverage is not useful for the normal user of GCC, only developers of GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38792
[Bug c++/38780] upgrade warning to error for bad C++ code ?
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-11 02:04 --- (In reply to comment #2) (In reply to comment #1) You can get an error via -pedantic-errors. Agreed - but switching on that flag opens a whole can of worms. Yes but then again as you said later on ... AFAIK, both front ends should be erroring this kind of code, because it's neither ISO C nor ISO C++. So you cannot have it both ways, allow extensions but not allow extensions (well except maybe long long with -Wno-long-long but that is the only one really). It is valid GNU C but not valid ISO C/C++. The behavior changed is to have it be also valid GNU C++ and make the front-end consistent with each other. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38780
[Bug bootstrap/38776] gcc 4.4.0 20090109 - Configure with --enable-coverage=noopt breaks build
--- Comment #5 from rob1weld at aol dot com 2009-01-11 02:50 --- Breaks again here: /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/gcc_build/./prev-gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -c -g -O2 -fprofile-use -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc_trunk/gcc -I../../gcc_trunk/gcc/. -I../../gcc_trunk/gcc/../include -I./../intl -I../../gcc_trunk/gcc/../libcpp/include -I../../gcc_trunk/gcc/../libdecnumber -I../../gcc_trunk/gcc/../libdecnumber/dpd -I../libdecnumber -DCLOOG_PPL_BACKEND -fexceptions ../../gcc_trunk/gcc/varasm.c -o varasm.o ../../gcc_trunk/gcc/varasm.c: In function default_elf_asm_named_section: ../../gcc_trunk/gcc/varasm.c:6791: error: coverage mismatch for function default_elf_asm_named_section while reading counter arcs ../../gcc_trunk/gcc/varasm.c:6791: note: number of counters is 18 instead of 22 ../../gcc_trunk/gcc/varasm.c:6791: error: coverage mismatch for function default_elf_asm_named_section while reading counter indirect_call ../../gcc_trunk/gcc/varasm.c:6791: note: number of counters is 0 instead of 3 ../../gcc_trunk/gcc/varasm.c: In function default_function_rodata_section: ../../gcc_trunk/gcc/varasm.c:6791: error: coverage mismatch for function default_function_rodata_section while reading counter arcs ../../gcc_trunk/gcc/varasm.c:6791: note: number of counters is 10 instead of 12 gmake[3]: *** [varasm.o] Error 1 gmake[3]: Leaving directory `/usr/share/src/gcc_build/gcc' gmake[2]: *** [all-stagefeedback-gcc] Error 2 gmake[2]: Leaving directory `/usr/share/src/gcc_build' gmake[1]: *** [stagefeedback-bubble] Error 2 gmake[1]: Leaving directory `/usr/share/src/gcc_build' gmake: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38776
[Bug bootstrap/38800] New: gcc 4.4.0 20090109 - make -i -k distclean does not remove amd64/ */* fixincludes/* and /gnattools/*
When I type make -i -k distclean not all files are removed.
Each missed directory contains the config.status file which we would not
want to remain (and use to recreate the current configuration) through
using distclean.
# gmake -i -k distclean
gmake[1]: Entering directory `/usr/share/src/gcc_build'
rm -f stage_current
gmake[1]: Leaving directory `/usr/share/src/gcc_build'
rm -rf stage1-*
rm -rf stage2-*
rm -rf stage3-* compare
rm -rf stage4-* compare3
rm -rf stageb2g0-*
rm -rf stageb3g2-* compare-debug
rm -rf stageprofile-*
rm -rf stagefeedback-*
gmake[1]: Entering directory `/usr/share/src/gcc_build'
gmake[1]: Leaving directory `/usr/share/src/gcc_build'
rm -f *.a TEMP errs core *.o *~ \#* TAGS *.E *.log
rm -f Makefile config.status config.cache mh-frag mt-frag
rm -f maybedep.tmp serdep.tmp
if [ i386-pc-solaris2.11 != . ]; then \
rm -rf i386-pc-solaris2.11; \
else true; fi
rm -rf build-i386-pc-solaris2.11
if [ . != . ]; then \
rm -rf .; \
else true; fi
rm -f texinfo/po/Makefile texinfo/po/Makefile.in texinfo/info/Makefile
rm -f texinfo/doc/Makefile texinfo/po/POTFILES
rmdir texinfo/doc texinfo/info texinfo/intl texinfo/lib 2/dev/null
gmake: [local-distclean] Error 1 (ignored)
rmdir texinfo/makeinfo texinfo/po texinfo/util 2/dev/null
gmake: [local-distclean] Error 1 (ignored)
rmdir fastjar gcc libiberty texinfo zlib 2/dev/null
gmake: [local-distclean] Error 1 (ignored)
# ls -l
drwx-- 3 root root 3 2009-01-02 02:04 amd64
drwxr-xr-x 3 root root 19 2009-01-06 00:14 fixincludes
drwxr-xr-x 2 root root 4 2009-01-06 00:14 gnattools
-rw-r--r-- 1 root root 14 2009-01-08 11:06 stage_final
Killing the unwanted files (manually) with:
# find . -name config.status -type f -print -exec rm {} \;
./fixincludes/config.status
./amd64/zlib/config.status
./gnattools/config.status
Thanks,
Rob
--
Summary: gcc 4.4.0 20090109 - make -i -k distclean does not
remove amd64/ */* fixincludes/* and /gnattools/*
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38800
[Bug bootstrap/38792] RFE - Need Makefile to build using different strategy for coverage vs. profiling
--- Comment #2 from rob1weld at aol dot com 2009-01-11 04:43 --- (In reply to comment #1) Coverage means -fprofile-arcs only while profiling means -fprofile-generate/-fprofile-use. Coverage is only useful when you are looking into GCC's sources to see what code is being used and how much. Coverage is not useful for the normal user of GCC, only developers of GCC. That is what I am going to use it for. I intend to build the Toolchain to keep stats of it's coverage and then run make -i check to ensure that the Testsuite is fully exercising _all_ of the Toolchain on this Platform. Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38792
[Bug middle-end/38753] gcc 4.4.0 20090106 - make profiledbootstrap - No .gcda files created in the libiberty/pic directory
--- Comment #11 from rob1weld at aol dot com 2009-01-11 04:50 --- (In reply to comment #10) 3. There is a -Werror to be fixed. Use: i386.o-warn = -Wno-error I already mentioned this was really fixed in trunk already. I re-read this entire thread and still do not see your prior comment but thanks for fixing that (hopefully NOT with i386.o-warn = -Wno-error). 5. The C and Ada Languages are being profiled (for the most part) but the c++,fortran,java,objc,obj-c++ compilers are NOT profiled at all. This is expected. Anyways this is invalid and nothing to be done here really because parts of the compiler are not really tested while doing a bootstrap. OK, we will not test everything. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38753
[Bug middle-end/38786] [graphite] ICE with -floop-block in verify_ssa
--- Comment #2 from spop at gcc dot gnu dot org 2009-01-11 06:54 --- Subject: Bug 38786 Author: spop Date: Sun Jan 11 06:54:19 2009 New Revision: 143260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143260 Log: 2009-01-11 Sebastian Pop sebastian@amd.com PR tree-optimization/38786 * testsuite/gcc.dg/graphite/pr38786.c: New. * graphite.c (expand_scalar_variables_ssa_name): New, outlined from the SSA_NAME case of expand_scalar_variables_expr. (expand_scalar_variables_expr): Also gather the scalar computation used to index the memory access. (expand_scalar_variables_stmt): Pass to expand_scalar_variables_expr the gimple_stmt_iterator where it inserts new code. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr38786.c Modified: branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38786
[Bug middle-end/38786] [graphite] ICE with -floop-block in verify_ssa
--- Comment #3 from spop at gcc dot gnu dot org 2009-01-11 06:55 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38786
[Bug tree-optimization/38529] [4.3 regression] ICE with nested loops
--- Comment #3 from irar at gcc dot gnu dot org 2009-01-11 07:40 --- Subject: Bug 38529 Author: irar Date: Sun Jan 11 07:39:47 2009 New Revision: 143262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143262 Log: Backport from mainline: 2008-12-29 Dorit Nuzman do...@il.ibm.com Ira Rosen i...@il.ibm.com PR tree-optimization/38529 * tree-vect-transform (vect_transform_stmt): Handle inner-loop stmts whose DEF is used in the loop-nest that is being vectorized, but outside the immediately enclosing loop. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/vect/pr38529.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38529
[Bug tree-optimization/38529] [4.3 regression] ICE with nested loops
--- Comment #4 from irar at il dot ibm dot com 2009-01-11 07:48 --- Fixed on 4.3 branch as well. -- irar at il dot ibm dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38529
[Bug tree-optimization/37194] [4.3 Regression] Autovectorization of small constant iteration loop degrades performance
--- Comment #13 from irar at gcc dot gnu dot org 2009-01-11 07:54 --- Subject: Bug 37194 Author: irar Date: Sun Jan 11 07:54:40 2009 New Revision: 143263 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143263 Log: Backport from mainline: 2009-01-08 Ira Rosen i...@il.ibm.com PR tree-optimization/37194 * tree-vect-transform.c (vect_estimate_min_profitable_iters): Don't add the cost of cost model guard in prologue to scalar outside cost in case of known number of iterations. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37194
[Bug tree-optimization/37194] [4.3 Regression] Autovectorization of small constant iteration loop degrades performance
--- Comment #14 from irar at il dot ibm dot com 2009-01-11 07:57 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37194
