[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #13 from julian1844 at yahoo dot com 2009-05-04 06:23 --- (In reply to comment #12) Should I conclude that the MinGW site is now www.equation.com? (In reply to comment #11) (In reply to comment #9, comment #10) I did not build MinGW 4.3.0. I got it from the official MinGW site (gcc-4.3.0-20080502-mingw32-alpha). I have also found that on www.equation.com there are even newer versions (binaries), like 4.3.3 with OpenMP 2.5, 4.4.0 with OpenMP 3.0 and MinGW 4.5 compilation snapshot. They seem to work fine with OpenMP. Its a shame that www.equation.com doesn't tell us how to obtain their source code for the gcc, gdb ands make binaries. They aren't present on the official MinGW site. Why? No one has had put them there. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #2 from dominiq at lps dot ens dot fr 2009-05-04 06:30 --- Confirmed on i686-apple-darwin9, array_memcpy_4.f90.003t.original is MAIN__ () { struct t d[5]; struct t s[5]; static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1}; _gfortran_set_options (8, (void *) options.0); (void) __builtin_memcpy ((void *) d, (void *) s, 60); } and does not depend on the optimization level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #3 from dominiq at lps dot ens dot fr 2009-05-04 06:32 --- At revision 147065 I get: MAIN__ () { struct t d[5]; struct t s[5]; static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1}; _gfortran_set_options (8, (void *) options.0); d = VIEW_CONVERT_EXPRstruct t[5](s); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #20 from kreckel at ginac dot de 2009-05-04 06:47 --- So, Joseph explained that the code should execute as expected, at least with -frounding-math as a workaround. However, with GCC 4.4 it is still not possible to write code that takes advantage of those advanced features of IEEE754, even on hardware that supports it directly. Could someone, please, set this bug's status to something less inappropriate than unconfirmed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug fortran/39997] Procedure(), pointer implicit typing: rejects-valid / accepts-invalid?
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-04 07:11 --- Wrong comp.lang.fortran link; the correct one is: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b3a7e94ddf6b8ff3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #10 from jv244 at cam dot ac dot uk 2009-05-04 07:12 --- This is the outermost stack trace to the segfault (with default 8M stack), shows the depth of the recursion, and the location: #174699 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174700 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174701 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174702 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174703 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174704 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:337 #174705 0x0052884d in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:213 #174706 0x005283e7 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:315 #174707 0x00528831 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:211 #174708 0x005283e7 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:315 #174709 0x005283d9 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:314 #174710 0x005283d9 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:314 #174711 0x00528041 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:457 #174712 0x005283e7 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:315 #174713 0x00528519 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-fortran-f95-lang.h:291 #174714 0x006f6955 in gt_ggc_mx_cgraph_node (x_p=value optimized out) at gtype-desc.c:228 #174715 0x006f6a76 in gt_ggc_m_P11cgraph_node4htab (x_p=value optimized out) at gtype-desc.c:2142 #174716 0x006c0bce in ggc_mark_roots () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:107 #174717 0x00572108 in ggc_collect () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1941 #174718 0x00543253 in gfc_generate_function_code (ns=0x3603e890) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-decl.c:4140 #174719 0x005298eb in gfc_generate_module_code (ns=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans.c:1322 #174720 0x004f6404 in gfc_parse_file () at /data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:3865 #174721 0x00526bbd in gfc_be_parse_file (set_yydebug=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:236 #174722 0x007f39b4 in toplev_main (argc=13, argv=0x7fff5db02a88) at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:977 #174723 0x7f9454765436 in __libc_start_main () from /lib64/libc.so.6 #174724 0x00499679 in _start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #11 from jv244 at cam dot ac dot uk 2009-05-04 07:49 --- I have a gdb session open, but I'm rather clueless. I have this: (gdb) print (*x).generic.type $5 = {common = {base = {code = RECORD_TYPE, side_effects_flag = 0, constant_flag = 0, addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0, type = 0x0}, values = 0x7f94536c6780, size = 0x7f9453fada80, size_unit = 0x7f9453e43cc0, attributes = 0x0, uid = 769447, precision = 0, mode = BLKmode, string_flag = 0, no_force_blk_flag = 0, needs_constructing_flag = 0, transparent_union_flag = 0, packed_flag = 0, restrict_flag = 0, contains_placeholder_bits = 0, lang_flag_0 = 0, lang_flag_1 = 1, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, user_align = 0, align = 64, alias_set = -1, pointer_to = 0x0, reference_to = 0x0, symtab = {address = 0, pointer = 0x0, die = 0x0}, name = 0x7f9452151150, minval = 0x0, maxval = 0x0, next_variant = 0x7f941d7c60c0, main_variant = 0x7f9453d66e40, binfo = 0x0, context = 0x0, canonical = 0x7f9453d66e40, lang_specific = 0x7f941d7c7600} but the following fails: (gdb) call debug_tree((*x).generic.type.next_variant) Cannot access memory at address 0x7fff5d302f78 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57
--- Comment #10 from dennis dot wassel at googlemail dot com 2009-05-04 08:50 --- Edited the Known to fail instead of Reported against. -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Known to fail||4.3.2 4.3.3 Version|4.3.3 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37951
[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57
--- Comment #9 from dennis dot wassel at googlemail dot com 2009-05-04 08:45 --- Also fails with 4.3.3 (precisely the same error message as 4.3.2) gfortran -O2 -ftree-parallelize-loops=2 -c ma57.f -o ma57.o ma57.f: In function 'ma57od': ma57.f:2724: error: edge from 676 to 686 should be marked irreducible ma57.f:2724: error: basic block 686 should be marked irreducible ma57.f:2724: error: edge from 686 to 679 should be marked irreducible ma57.f:2724: error: basic block 679 should be marked irreducible ma57.f:2724: error: edge from 679 to 124 should be marked irreducible ma57.f:2724: confused by earlier errors, bailing out Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/localdata --program-suffix=-4.3.3 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --enable-version-specific-runtime-libs Thread model: posix gcc version 4.3.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-O2' '-ftree-parallelize-loops=2' '-c' '-o' 'ma57.o' '-mtune=generic' '-pthread' /localdata/libexec/gcc/i686-pc-linux-gnu/4.3.3/f951 ma57.f -ffixed-form -quiet -dumpbase ma57.f -mtune=generic -auxbase-strip ma57.o -O2 -version -ftree-parallelize-loops=2 -fintrinsic-modules-path /localdata/lib/gcc/i686-pc-linux-gnu/4.3.3/finclude -o /tmp/ccHYlhlQ.s GNU F95 (GCC) version 4.3.3 (i686-pc-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.3, MPFR version 2.4.1-p5. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Is anyone interested in fixing this? I think it would not infringe the spirit of license agreement, if I provided someone off-list with the source _for debugging purposes only_. -- dennis dot wassel at googlemail dot com changed: What|Removed |Added CC||dennis dot wassel at ||googlemail dot com Version|4.3.2 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37951
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING and TYPEs
--- Comment #3 from dennis dot wassel at googlemail dot com 2009-05-04 08:55 --- Also fails with 4.3.3: gfortran -v pr37744.f90 Driving: gfortran -v pr37744.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/localdata --program-suffix=-4.3.3 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --enable-version-specific-runtime-libs Thread model: posix gcc version 4.3.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' /localdata/libexec/gcc/i686-pc-linux-gnu/4.3.3/f951 pr37744.f90 -quiet -dumpbase pr37744.f90 -mtune=generic -auxbase pr37744 -version -fintrinsic-modules-path /localdata/lib/gcc/i686-pc-linux-gnu/4.3.3/finclude -o /tmp/ccQTr6UN.s GNU F95 (GCC) version 4.3.3 (i686-pc-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.3, MPFR version 2.4.1-p5. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 pr37744.f90:22.19: foo%flags(trouble) = .FALSE._C_BOOL 1 Error: Symbol 'trouble' at (1) has no IMPLICIT type f951: internal compiler error: Segmentation fault -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Known to fail|4.3.2 4.4.0 |4.3.2 4.3.3 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #5 from rguenther at suse dot de 2009-05-04 09:01 --- Subject: Re: [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90 On Mon, 4 May 2009, dominiq at lps dot ens dot fr wrote: --- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59 --- This test has been introduced by the patch in http://gcc.gnu.org/ml/fortran/2007-01/msg00425.html. The tests gfortran.dg/array_memcpy_[1-3].f90 use ! { dg-final { scan-tree-dump-times memcpy * original } } So a simple fix would be to replace ! { dg-final { scan-tree-dump-times d = 1 original } } with ! { dg-final { scan-tree-dump-times memcpy 1 original } } but I don't understand why array_memcpy_4.f90 used to give a different construct and this change could mask a more serious problem. I will investigate - we really should get the memcpy removed. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING and TYPEs
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 09:06 --- Also ICE on trunk r147065 powerpc-apple-darwin9 or r147085 i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #1 from pault at gcc dot gnu dot org 2009-05-04 09:10 --- Dominique, Thanks for setting this up. I'll poll everybody involved for contributions and have assigned myself the bug(s). Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 09:10:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #2 from pault at gcc dot gnu dot org 2009-05-04 09:29 --- see PR40006: allow type cheating for procedures with an implicit interface -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||40006 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-05-04 09:41 --- (In reply to comment #6) We can compute the maximum possible function length first. If the length is not large enough far jump is not necessary, and we can do this optimization safely. No, it's not that easy, since reload can add instructions. Realistically, there is a finite limit beyond which even reload couldn't generate sufficiently large numbers of instructions to cause failure, but it's hard to *prove* what that lower bound is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #3 from pault at gcc dot gnu dot org 2009-05-04 09:31 --- ...and PR39896 : ICE with -fwhole-file -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39896 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #8 from carrot at google dot com 2009-05-04 10:08 --- Sorry for my ignorance to gcc. What types of instructions reload will add? Spilling and loading registers? and more? By reading the the implementation of thumb_far_jump_used_p() I can get the conclusion that if reload thinks there is a far jump, later pass won't change this decision. But if reload thinks there is no far jump, later pass still need to re-check the far jump existence and may change this decision. So if reload occasionally makes a wrong decision later pass should correct it, is it right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #5 from pault at gcc dot gnu dot org 2009-05-04 10:19 --- (In reply to comment #2) It may be worth noting that there are no warnings in the application about labels not being in the same block as the corresponding GOTO if compiled without -fwhole-file, but if compiled with -fwhole-file some of these warnings appear. If these warnings are missed without -fwhole-file or spurious with -fwhole-file, I can not say yet. I'll try to get a testcase ... For some reason that I do not see right now, cs_base in resolve.c is not being pushed or popped correctly. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-04 09:25 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-05-04 05:54:58 |2009-05-04 09:25:57 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59 --- This test has been introduced by the patch in http://gcc.gnu.org/ml/fortran/2007-01/msg00425.html. The tests gfortran.dg/array_memcpy_[1-3].f90 use ! { dg-final { scan-tree-dump-times memcpy * original } } So a simple fix would be to replace ! { dg-final { scan-tree-dump-times d = 1 original } } with ! { dg-final { scan-tree-dump-times memcpy 1 original } } but I don't understand why array_memcpy_4.f90 used to give a different construct and this change could mask a more serious problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c++/40013] [4.4 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.3 Summary|[4.4 regression] ICE when |[4.4 Regression] ICE when |creating a local array with |creating a local array with |size from the return value |size from the return value |of a member function of an |of a member function of an |object in a nested class in |object in a nested class in |a template class|a template class Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #6 from pault at gcc dot gnu dot org 2009-05-04 10:31 --- For some reason that I do not see right now, cs_base in resolve.c is not being pushed or popped correctly. Ah yes! resolve_codes nulls out cs_base. The problem is fixed by storing cs_base before calling gfc_resolve, at line 1674, and then restoring the value afterwards. It might be cleaner to do this in gfc_resolve - I'll check later. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #7 from pault at gcc dot gnu dot org 2009-05-04 10:32 --- I guess that I should take it :-) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 10:32:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-04 11:02 --- Subject: Bug 40015 Author: rguenth Date: Mon May 4 11:01:59 2009 New Revision: 147094 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147094 Log: 2009-05-04 Richard Guenther rguent...@suse.de PR middle-end/40015 * builtins.c (fold_builtin_memory_op): Do not decay to element type if the size matches the whole array. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c++/40013] [4.4 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-04 11:26 --- http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00116.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 11:26:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug bootstrap/39968] [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 11:42 --- This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #3 to #5, I don't close it as fixed. If someone wants to keep this PR open, (s)he should change subject and priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968
[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-apple-darwin9 and powerpc-ibm-aix
--- Comment #15 from dominiq at lps dot ens dot fr 2009-05-04 11:45 --- This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #11 to #13, I don't close it as fixed. If someone wants to keep this PR open, (s)he should change subject, platform, and priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-04 12:43 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c++/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #9 from manu at gcc dot gnu dot org 2009-05-04 12:48 --- Subject: Bug 28152 Author: manu Date: Mon May 4 12:47:53 2009 New Revision: 147097 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147097 Log: 2009-05-04 Manuel Lopez-Ibanez m...@gcc.gnu.org PR c++/28152 cp/ * parser.c (cp_lexer_get_preprocessor_token): Do not store the canonical spelling for keywords. (cp_parser_attribute_list): Use the canonical spelling for keywords in attributes. testsuite/ * g++.dg/parse/parser-pr28152.C: New. * g++.dg/parse/parser-pr28152-2.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/parser-pr28152-2.C trunk/gcc/testsuite/g++.dg/parse/parser-pr28152.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c++/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #10 from manu at gcc dot gnu dot org 2009-05-04 12:49 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c/40016] New: regex_internal.h:185: error: integer overflow in preprocessor expression
Hi, when i compiling gnu parted 1.8.8 with gcc 4.5.0, got error include regex.i TIA = /bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -I. -Os -Werror -MT regex.lo -MD -MP -MF .deps/regex.Tpo -c -o regex.lo regex.c gcc -std=gnu99 -I. -Os -Werror -MT regex.lo -MD -MP -MF .deps/regex.Tpo -c regex.c -fPIC -DPIC -o .libs/regex.o cc1: warnings being treated as errors In file included from regex.c:58: regex_internal.h:185: error: integer overflow in preprocessor expression make[2]: *** [regex.lo] Error 1 make[2]: Leaving directory `/home/user/d/parted-1.8.8/lib' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/user/d/parted-1.8.8/lib' make: *** [all-recursive] Error 1 bash-4.0$ cc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap --disable-multilib Thread model: posix gcc version 4.5.0 20090503 (experimental) (GCC) bash-4.0$ -- Summary: regex_internal.h:185: error: integer overflow in preprocessor expression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: happyarch at gmail dot com GCC build triplet: x86_64 GCC host triplet: x86_64 GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug c/40016] regex_internal.h:185: error: integer overflow in preprocessor expression
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-04 14:23 --- Works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug target/40017] New: [4.4/4.5 Regression] stdbool.h/altivec.h
#include stdbool.h #include altivec.h vector bool int b; int main (void) { return 0; } used to compile up to 4.3, doesn't any longer. I wonder what can be done here though, for C++ with the conditional macros bool keywords can coexist well with the context sensitive keywords, but unfortunately #define bool _Bool kills the conditional keyword behavior. -- Summary: [4.4/4.5 Regression] stdbool.h/altivec.h Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target 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=40017
[Bug bootstrap/39849] [4.3/4.4 Regression] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #8 from dennis dot wassel at googlemail dot com 2009-05-04 14:18 --- Marked as 4.3/4.4 regression. What should I try next? Need I provide any additional info? Any help is much appreciated! -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Severity|normal |major Summary|segfault for '__divtf3' |[4.3/4.4 Regression] |during bootstrap and non- |segfault for '__divtf3' |bootstrap install |during bootstrap and non- ||bootstrap install http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug bootstrap/39849] [4.3/4.4 Regression] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-04 14:28 --- Do not set CFLAGS in make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' profiledbootstrap or specify your host compiler version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-04 14:29 --- It obviously works for me, you system seems to be messed up / special. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 Regression]|segfault for '__divtf3' |segfault for '__divtf3' |during bootstrap and non- |during bootstrap and non- |bootstrap install |bootstrap install | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-04 14:30 --- I'd say handling _Bool the same way as bool after vector would be a good idea. It has a disadvantage that in addition to the (I'd say desirable): #include stdbool.h #include altivec.h ... vector bool int i; also vector _Bool int i; would be accepted, but the advantages IMHO outweight disadvantages. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org, ||bje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-04 14:32 --- Yes that seems like the right idea; the altivec specs was written before C99 was out. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #13 from dennis dot wassel at googlemail dot com 2009-05-04 14:55 --- I just noticed/remembered that [x]gcc only drives the compilers, so I plugged cc1 into gdb and here is the (somewhat messy, slightly edited) result: gdb /localdata/install/gcc/gcc-4.4.0-build/./gcc/cc1 GNU gdb 6.8 This GDB was configured as i686-pc-linux-gnu... run -quiet -v -I. -I. -I../.././gcc -I../../../gcc-4.4.0/libgcc -I../../../gcc-4.4.0/libgcc/. -I../../../gcc-4.4.0/libgcc/../gcc -I../../../gcc-4.4.0/libgcc/../include -I../../../gcc-4.4.0/libgcc/config/libbid -iprefix /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/ -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include-fixed -MD divtf3.d -MF divtf3.dep -MP -MT divtf3.o -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -DHIDE_EXPORTS -isystem /localdata/i686-pc-linux-gnu/include -isystem /localdata/i686-pc-linux-gnu/sys-include -isystem ./include ../../../gcc-4.4.0/libgcc/../gcc/config/soft-fp/divtf3.c -quiet -dumpbase divtf3.c -mtune=generic -auxbase-strip divtf3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wcast-qual -Wold-style-definition -Wno-missing-prototypes -Wno-type-limits -version -fPIC -fexceptions -fvisibility=hidden -o /tmp/ccuJ4Jyu.s Starting program: /localdata/install/gcc/gcc-4.4.0-build/gcc/cc1 -quiet -v -I. -I. -I../.././gcc -I../../../gcc-4.4.0/libgcc -I../../../gcc-4.4.0/libgcc/. -I../../../gcc-4.4.0/libgcc/../gcc -I../../../gcc-4.4.0/libgcc/../include -I../../../gcc-4.4.0/libgcc/config/libbid -iprefix /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/ -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include-fixed -MD divtf3.d -MF divtf3.dep -MP -MT divtf3.o -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -DHIDE_EXPORTS -isystem /localdata/i686-pc-linux-gnu/include -isystem /localdata/i686-pc-linux-gnu/sys-include -isystem ./include ../../../gcc-4.4.0/libgcc/../gcc/config/soft-fp/divtf3.c -quiet -dumpbase divtf3.c -mtune=generic -auxbase-strip divtf3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wcast-qual -Wold-style-definition -Wno-missing-prototypes -Wno-type-limits -version -fPIC -fexceptions -fvisibility=hidden -o /tmp/ccuJ4Jyu.s Failed to read a valid object file image from memory. ignoring nonexistent directory /localdata/i686-pc-linux-gnu/include ignoring nonexistent directory /localdata/i686-pc-linux-gnu/sys-include ignoring nonexistent directory ./include ignoring nonexistent directory /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/include ignoring nonexistent directory /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed ignoring nonexistent directory /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include ignoring nonexistent directory /localdata/lib/gcc/i686-pc-linux-gnu/4.4.0/include ignoring nonexistent directory /localdata/lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed ignoring nonexistent directory /localdata/lib/gcc/i686-pc-linux-gnu/../../../i686-pc-linux-gnu/include ignoring duplicate directory . ignoring duplicate directory ../../../gcc-4.4.0/libgcc/. #include ... search starts here: #include ... search starts here: . ../.././gcc ../../../gcc-4.4.0/libgcc ../../../gcc-4.4.0/libgcc/../gcc ../../../gcc-4.4.0/libgcc/../include ../../../gcc-4.4.0/libgcc/config/libbid /localdata/install/gcc/gcc-4.4.0-build/./gcc/include /localdata/install/gcc/gcc-4.4.0-build/./gcc/include-fixed /usr/local/include /localdata/include /usr/include End of search list. GNU C (GCC) version 4.4.0 (i686-pc-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.3, MPFR version 2.4.1-p5. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: ac242e6eff36fdeb132b194aac7540a7 Program received signal SIGSEGV, Segmentation fault. 0x0816a5ba in c_tree_printer (pp=0x9e3d288, text=0xbfd3ca04, spec=0x9e23129 D, precision=0, wide=0 '\0', set_locus=0 '\0', hash=0 '\0') at ../../gcc-4.4.0/gcc/c-objc-common.c:99 99tree t = va_arg (*text-args_ptr, tree); (gdb) bt #0 0x0816a5ba in c_tree_printer (pp=0x9e3d288, text=0xbfd3ca04, spec=0x9e23129 D, precision=0, wide=0 '\0', set_locus=0 '\0', hash=0 '\0') at ../../gcc-4.4.0/gcc/c-objc-common.c:99 #1 0x088568b4 in pp_base_format (pp=0x9e3d288, text=0xbfd3ca04) at ../../gcc-4.4.0/gcc/pretty-print.c:557 #2 0x083cc846 in diagnostic_report_diagnostic (context=0x9dc3aa0, diagnostic=0xbfd3ca04) at ../../gcc-4.4.0/gcc/diagnostic.c:402 #3 0x083ccbb1 in
[Bug bootstrap/38523] [4.4/4.5 regression] arm build fails to link cc1-dummy
--- Comment #21 from laurent at guerby dot net 2009-05-04 14:50 --- No objection in one week, so closing as WORKSFORME with binutils from CVS = 20090423 -- laurent at guerby dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #15 from dennis dot wassel at googlemail dot com 2009-05-04 15:09 --- Created an attachment (id=17796) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17796action=view) Preprocessed source Sure! Attaching preprocessed source of gcc-4.4.0/gcc/config/soft-fp/divtf3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug c/40016] regex_internal.h:185: error: integer overflow in preprocessor expression
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-04 14:52 --- Not surprisingly when the error is during preprocessing. regex.h parted ships (why?) is broken by the #elif changes, there is: #if some_condition_that_is_true_on_sane_targets ... #elif BITSET_WORD_MAX == (0x + 2) * 0x /* Work around a bug in 64-bit PGC (before version 6.1-2), where the preprocessor mishandles large unsigned values as if they were signed. */ ... #endif To make GCC happy about this at least the #elif should be changed into #else #if ... #endif. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-05-04 15:00 --- Yes slightly, it is trying to warn about something which is unitialized. This works for me on i686-linux-gnu. Can you provide the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug ada/38874] gnatmake doesn't pass through --param options
--- Comment #3 from guerby at gcc dot gnu dot org 2009-05-04 15:32 --- Subject: Bug 38874 Author: guerby Date: Mon May 4 15:32:00 2009 New Revision: 147102 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147102 Log: 2009-05-04 Laurent GUERBY laur...@guerby.net PR ada/38874 * make.adb (Scan_Make_Arg): Pass --param= to compiler and linker. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/make.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38874
[Bug bootstrap/39977] [4.5 Regression] r146817 broke bootstrap on PA
--- Comment #7 from danglin at gcc dot gnu dot org 2009-05-04 15:35 --- The patch from comment #4 was installed here: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00018.html From my perspective, this fixes the 4.5 regression reported here. Possibly the change should be back ported to fix PR 29209. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #8 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04 15:41 --- Oops... forgot about that bit, sorry. Compile flags: -m32 -O3 -mcpu=power[4|5|6] -ffast-math -ftree-loop-linear -funroll-loops -fpeel-loops This reproduces on both 32-bit and 64-bit. Luis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #9 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04 15:50 --- Follows the configure options, although i think you'll be able to reproduce it with the flags i've mentioned. /gcc/HEAD/configure --target=powerpc64-linux --host=powerpc64-linux --build=powerpc64-linux --with-cpu=default32 --enable-threads=posix --enable-shared --enable-__cxa_atexit --with-gmp=/gmp --with-mpfr=mpfr --with-long-double-128 --enable-decimal-float --enable-secure-plt --disable-bootstrap --disable-alsa --prefix=/install/gcc/HEAD build_alias=powerpc64-linux host_alias=powerpc64-linux target_alias=powerpc64-linux --enable-languages=c,c++,fortran --no-create --no-recursion -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #11 from dennis dot wassel at googlemail dot com 2009-05-04 14:35 --- (In reply to comment #9) Do not set CFLAGS in make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' profiledbootstrap This ^ was only in my first iteration, and I've omitted it in the following ones. My last (unsuccessful) attempt was a plain: ../gcc-4.4.0/configure --prefix=/localdata --program-suffix=-4.4.0 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --with-ppl=/localdata --with-cloog=/localdata --enable-version-specific-runtime-libs make and nothing out of the ordinary. or specify your host compiler version. My host compiler is gcc 4.3.3 gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/localdata --program-suffix=-4.3.3 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --enable-version-specific-runtime-libs Thread model: posix gcc version 4.3.3 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-04 13:48 --- Subject: Re: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2 Which pass? p *pass in frame 20 should tell you. (gdb) p *pass $1 = {type = GIMPLE_PASS, name = 0x27bb734 forwprop, gate = 0x152d6d4 gate_forwprop, execute = 0x152cc8c tree_ssa_forward_propagate_single_use_vars, sub = 0x0, next = 0x2a806c8, static_pass_number = 123, tv_id = TV_TREE_FORWPROP, properties_required = 40, properties_provided = 0, properties_destroyed = 0, todo_flags_start = 0, todo_flags_finish = 2055} Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #7 from matz at gcc dot gnu dot org 2009-05-04 14:37 --- Compile options please. I can't reproduce it with a powerpc64 compiler with -O2, neither with -m32 nor -m64, -ffast-math or no -ffast-math. Also 'gcc -v' can't hurt to make sure our compilers are configured the same. Hint: I use this command to quickly skim over the situation with labels and bdnz: % egrep '^.L|bdnz' thin6d.s If the bdnz lines always mention the label from a line above it's a single basic block loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug c/40016] regex_internal.h:185: error: integer overflow in preprocessor expression
--- Comment #1 from happyarch at gmail dot com 2009-05-04 13:59 --- Created an attachment (id=17795) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17795action=view) .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #10 from matz at gcc dot gnu dot org 2009-05-04 16:10 --- Yes, I can now, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #12 from dennis dot wassel at googlemail dot com 2009-05-04 14:43 --- (In reply to comment #10) It obviously works for me, you system seems to be messed up / special. Seems so, although it is a Debian 4 with an unknown amount of modifications by our admin. One symptom of specialness is the fact that neither the system nor the gcc's headers define SSIZE_MAX, but I have a workaround for that (namely defining it as SHRT_MAX in config/host-linux.c, if it is undefined). Shall I dig around somewhere to find out the exact amount of my system's specialness? Is there a way to build the bootstrap compiler with debugging info, so I can use gdb to figure out where the segfault happens? PS: I think this *is* a regression, because I can build 4.3, but not 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-04 14:39 --- _Bool would need to be a conditional macro too though, I wonder if some ISO C99 pedantry can't test that _Bool isn't defined or something like that. But then for C++ it is similar with defined(bool) also being true with -maltivec instead of false. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #6 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04 13:50 --- Just for the sake of information, -fselective-scheduling doesn't help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 17:54 --- With thee patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html without type cheating, all the ICEs in my tests are gone. It even fixes pr37744!-(it may give a clue on how to fix it without -fwhole-file). For the test arr_fun.f90, I now get: arr_fun.f90:10.6: res = test(2) 1 Error: The reference to function 'test' at (1) either needs an explicit INTERFACE or the rank is incorrect which seems right (without -fwhole-file I get a bus error at run time). Test gcc/testsuite/gfortran.dg/hollerith.f90 and friends won't probably pass regtesting: call test (8h hello) 1 Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8) I have to run the polyhedron tests and to regtest, so it is all for this time. Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-05-04 18:08 --- Paul, your patch fixes all issues I came across when compiling my largish set of fortran sources with -fwhole-file. So, now I just need to sort out all the warnings that came up *cough* ;) Many thanks! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2009-05/msg00046.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug fortran/40018] New: ICE in output_constructor
$ cat a.f90 integer(kind=8) :: i write(*,*) [(i, i = 1, 10)] end $ gfortran a.f90 a.f90:2: internal compiler error: in output_constructor, at varasm.c:4712 The GDB backtrace is: #0 fancy_abort (file=0xd7999a ../../trunk/gcc/varasm.c, line=4716, function=0xd792d0 output_constructor) at ../../trunk/gcc/diagnostic.c:723 #1 0x0094b762 in output_constructor (exp=value optimized out, size=value optimized out, align=value optimized out) at ../../trunk/gcc/varasm.c:4716 #2 0x009bec65 in varpool_assemble_decl (node=0x2ace99df7a40) at ../../trunk/gcc/varpool.c:364 #3 0x0098f991 in cgraph_output_in_order () at ../../trunk/gcc/cgraphunit.c:1202 #4 0x00991622 in cgraph_optimize () at ../../trunk/gcc/cgraphunit.c:1318 #5 0x005125e5 in gfc_be_parse_file (set_yydebug=value optimized out) at ../../trunk/gcc/fortran/f95-lang.c:237 #6 0x007e0324 in toplev_main (argc=2, argv=0x7fff143ae1b8) at ../../trunk/gcc/toplev.c:977 Happens on x86_64-linux with current trunk (rev. 147105), and i686-apple-darwin9 rev. 144983. -- Summary: ICE in output_constructor Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org OtherBugsDependingO 32834 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
[Bug fortran/40018] ICE in output_constructor
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-04 19:19 --- Confirmed on trunk and 4.4.0. Works with 4.3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
[Bug fortran/40019] New: LEADZ and TRAILZ give wrong results
LEADZ and TRAILZ can give wrong results for kinds other than 4 and 8. For example, the following code: integer(kind=1) :: i1 integer(kind=2) :: i2 integer(kind=4) :: i4 integer(kind=8) :: i8 integer(kind=16) :: i16 i1 = -1 i2 = -1 i4 = -1 i8 = -1 i16 = -1 print *, leadz(i1), leadz(i2), leadz(i4), leadz(i8), leadz(i16) gives -24 -16 0 0 64 as results, while it should only yield zeros! There are a few reasons: - for kinds 1 and 2, we should not cast directly to (unsigned int), but do a double cast: (unsigned int)(unsigned char) for kind=1, for example; otherwise, negative values are screwed. - trans-intrinsic.c uses a correspondance, kinds == 1, 2 and 4 use BUILT_IN_CLZ, kind 8 uses BUILT_IN_CLZL and kind 16 uses BUILT_IN_CLZLL; in reality, there is no such correspondance, as kind==16 is larger than long long! This, of course, makes it harder, because there is no function ready for use in kind==16. -- Summary: LEADZ and TRAILZ give wrong results Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40019
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-04 19:37 --- About POPCNT and POPPAR, beware! Implementations are much harder than simply using the GCC __builtin_popcount{,l,ll}: see PR40019 for similar issue with LEADZ and TRAILZ. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug c/33466] mixed-case suffix for decimal float constants
--- Comment #10 from janis at gcc dot gnu dot org 2009-05-04 19:50 --- Fixed for trunk, expected to become GCC 4.5.0. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug target/39027] double floating point suffix of 'd' and 'D' not accepted
--- Comment #5 from janis at gcc dot gnu dot org 2009-05-04 19:55 --- This was fixed in trunk, expected to become GCC 4.5.0, on 2009-04-01 as revision 145422. The ChangeLog entries have the correct PR number but the svn log messages use 29027, which is why the checkins were not recorded here. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027
[Bug fortran/39772] add a correctness check for the size intrinsic to -fbounds-check
--- Comment #10 from mikael at gcc dot gnu dot org 2009-05-04 20:24 --- cf PR36462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
[Bug fortran/39971] kinds.h fails at building libgfortran
--- Comment #13 from mikael at gcc dot gnu dot org 2009-05-04 20:27 --- (In reply to comment #12) don't know how to use it to compile gcc being a normal user (no root privileges) without scrambling everything else. Any help on this direction? Thanks export LD_LIBRARY_PATH=/your/libc/path ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39971
[Bug middle-end/39973] [4.5 Regression] Revision 146817 miscompiled 416.gamess in SPEC CPU 2006
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-04 20:44 --- blas.fppized.f was miscompiled by -m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
[Bug middle-end/39972] [4.5 Regression] Revision 146817 miscompiled 465.tonto in SPEC CPU 2006
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 20:52 --- blas.f90 was miscompiled by -m32 -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
[Bug target/39986] decimal float constant is incorrect when cc1 is a 64-bit binary
--- Comment #3 from janis at gcc dot gnu dot org 2009-05-04 21:24 --- On x86_64 with a 64-bit compiler, positive decimal float constants are OK, negative decimal float constants are wrong for both -m64 (the default) and -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39986
[Bug fortran/40020] New: Bad value during floating point read
I tried to migrate well running program from g77 to gfortran. I found a problem with new gfortan: Fortran runtime error: Bad value during floating point read to read REAL from file. read(nin,'(6e11.0)') a and numbers were: 7.73118- 3 4.26617+ 0 8.17285- 3 ... It helps to add number '0' to exponent instead of space 7.73118-03 4.26617+00 8.17285-03 ... Input decks are very old so I'm not sure if it was some feature off g77. -- Summary: Bad value during floating point read Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ased at cce dot cz GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40020
[Bug middle-end/40021] New: [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
On Linux/ia32, revision 146817 miscompiled DAXPY in BLAS with -m32 O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form -- Summary: [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end 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=40021
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-04 21:52 --- With the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html gas_dyn.f90 fails as in commet #0, except for -O1: [ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90 gas_dyn.f90: In function 'chozdt': gas_dyn.f90:216: internal compiler error: Bus error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-04 21:52 --- *** Bug 39972 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug middle-end/39972] [4.5 Regression] Revision 146817 miscompiled 465.tonto in SPEC CPU 2006
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-04 21:52 --- *** This bug has been marked as a duplicate of 40021 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
[Bug middle-end/39973] [4.5 Regression] Revision 146817 miscompiled 416.gamess in SPEC CPU 2006
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 21:53 --- *** This bug has been marked as a duplicate of 40021 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-04 21:53 --- *** Bug 39973 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug fortran/40020] Bad value during floating point read
--- Comment #1 from kargl at gcc dot gnu dot org 2009-05-04 22:17 --- (In reply to comment #0) I tried to migrate well running program from g77 to gfortran. I found a problem with new gfortan: Fortran runtime error: Bad value during floating point read to read REAL from file. read(nin,'(6e11.0)') a and numbers were: 7.73118- 3 4.26617+ 0 8.17285- 3 ... It helps to add number '0' to exponent instead of space 7.73118-03 4.26617+00 8.17285-03 ... Input decks are very old so I'm not sure if it was some feature off g77. Works fine with 4.5.0 and I suspect 4.4.0. Please try 4.4.0. REMOVE:kargl[30] gfc4x -o z gf.f90 REMOVE:kargl[31] ./z 0.12345e- 3 1.23449994E-04 REMOVE:kargl[32] gfc43 -o z gf.f90 REMOVE:kargl[33] ./z 0.12345e- 3 At line 3 of file gf.f90 (unit = 5, file = 'stdin') Fortran runtime error: Bad value during floating point read REMOVE:kargl[34] cat gf.f90 program gf real x read(*,'(e11.0)') x write(*,*) x end program gf -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40020
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 22:20 --- Regtest gives: === gfortran Summary === # of expected passes117714 # of unexpected failures576 # of expected failures 78 # of unsupported tests 906 for RUNTESTFLAGS=--target_board=unix'{,-m64,/-fwhole-file,-m64/-fwhole-file}' with no unexpected failures for {,-m64}. 444 failures come from cc1: warning: command line option -fwhole-file is valid for Fortran but not for C I think I know how to filter them. --- generic_actual_arg.f90 fails with /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/generic_actual_arg.f90:40.64: CALL F(CALCULATION2) ! OK because there is a same name specific 1 Error: More actual than formal arguments in procedure call at (1) False positive? --- global_references_1.f90 fails with SUBROUTINE j (x)! { dg-error is already being used as a FUNCTION } 2 Error: Global name 'j' at (1) is already being used as a SUBROUTINE at (2) /opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:39.6: T = j () ! { dg-error is already being used as a FUNCTION } 1 Error: Missing actual argument for argument 'x' at (1) /opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:68.64: --- hollerith.f90 fails with call test (8h hello) 1 Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8) --- hollerith_legacy.f90 same failure --- import6.f90 fails with opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13: call func1(x) 1 Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to TYPE(my_type) Obviously some tests will require adjustments to pass with -fwhole-file. More tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug libstdc++/39382] FAIL: abi_check on trunk revision 144629
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-05-04 22:33 --- No feedback. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39382
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-04 22:44 --- Also gfortran.dg/contained_3.f90 is miscompiled with -fwhole-file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-04 23:07 --- Created an attachment (id=17797) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17797action=view) A testcase [...@gnu-33 pr40021]$ make /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form test.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form daxpy.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -Wl,-rpath,/export/gnu/import/rrs/146817/usr/lib -o daxpy test.o daxpy.o ./daxpy 2 -2.20932289958000183E-002 != -2.22017297318430201E-002 4.88703976462625395E-003 [...@gnu-33 pr40021]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug c/40022] New: 4.4 regression breaks reply to all in alpine
Hello, I have to admit I'm clueless about how to debug this. On Fedora 11 preview release with gcc-4.4.0 alpine reply to all does not include the list of cc'd addresses. Linus found that if you compile the pith/reply.cc without optimizations it works properly (see Fedora bug report at http://bugzilla.redhat.com/show_bug.cgi?id=496400 ). Here is how to reproduce: mkdir alpinetest cd alpinetest svn checkout https://svn.cac.washington.edu/public/alpine/snapshots/ cd snapshots _sysconfdir=/etc/ touch imap/ip6 ./configure \ --enable-debug=no \ --without-tcl \ --with-c-client-target=lfd \ --with-passfile=.alpine.passfile \ --with-spellcheck-prog=aspell \ --with-system-pinerc=%{_sysconfdir}/pine.conf \ --with-system-fixed-pinerc=%{_sysconfdir}/pine.conf.fixed make alpine/alpine # try Reply to all and see bug cd pith make clean make CFLAGS=-O0 cd .. make alpine/alpine # try Reply to all and see it working -- Summary: 4.4 regression breaks reply to all in alpine Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joshuadfranklin at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 23:09 --- The vectorizer seems broken: /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectorize -msse2 -mfpmath=sse -ffast-math -ffixed-form test.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectorize -msse2 -mfpmath=sse -ffast-math -ffixed-form daxpy.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -Wl,-rpath,/export/gnu/import/rrs/146817/usr/lib -o daxpy test.o daxpy.o ./daxpy 2 -2.20932289958000183E-002 != -2.22017297318430201E-002 4.88703976462625395E-003 [...@gnu-33 pr40021]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-04 23:16 --- Hmm, so -fwrapv and -fno-strict-aliasing fixes the problem which case it might be a bug in the source. Can you provide the preprocessed source of pith/reply.cc? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
--- Comment #2 from joshuadfranklin at yahoo dot com 2009-05-04 23:36 --- Created an attachment (id=17798) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17798action=view) alpine pith/reply.c compiled with O0 and save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
-- joshuadfranklin at yahoo dot com changed: What|Removed |Added CC||joshuadfranklin at yahoo dot ||com Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-04 23:55 --- That is the assembler that is produced not the preprocessed source, use -save-temps and attach the .ii file. Thanks, Andrew Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
--- Comment #4 from joshuadfranklin at yahoo dot com 2009-05-05 00:00 --- Created an attachment (id=17799) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17799action=view) alpine pith/reply.c compiled with save-temps ' My compile line: gcc -c -save-temps -std=gnu99 -DHAVE_CONFIG_H -I../include -I../include -I/etc/pki/tls/include -c -o reply.o reply.c Make output: cc -save-temps -std=gnu99 -DHAVE_CONFIG_H -I../include -I../include -I/etc/pki/tls/include -O0 -MT reply.o -MD -MP -MF .deps/reply.Tpo -c -o reply.o reply.c -- joshuadfranklin at yahoo dot com changed: What|Removed |Added Attachment #17798|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
--- Comment #5 from joshuadfranklin at yahoo dot com 2009-05-05 00:01 --- (In reply to comment #3) That is the assembler that is produced not the preprocessed source, use -save-temps and attach the .ii file. Sorry. Does this one look right? It's actually .c I typo'd the .cc. -- joshuadfranklin at yahoo dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-05 00:45 --- Created an attachment (id=17800) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17800action=view) A testcase [...@gnu-33 pr40021]$ make /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectorize -msse2 -mfpmath=sse -ffast-math -ffixed-form test.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -Wl,-rpath,/export/gnu/import/rrs/146817/usr/lib -o daxpy test.o ./daxpy 2 -1. != -2. [...@gnu-33 pr40021]$ -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #17797|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #8 from jv244 at cam dot ac dot uk 2009-05-05 04:18 --- (In reply to comment #6) opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13: call func1(x) 1 Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to TYPE(my_type) that's a proper error as well, TYPE(my_type) needs to have the SEQUENCE attribute for this to be correct -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011