[Bug c++/37093] [4.2/4.3/4.4/4.5 Regression] ICE with pointer to member template parameters
--- Comment #20 from dodji at gcc dot gnu dot org 2009-10-31 07:05 --- Patch posted to http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01827.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37093
[Bug bootstrap/41345] [4.5 Regression] bootstrap comparison failure with --disable-checking
--- Comment #11 from sezeroz at gmail dot com 2009-10-31 07:50 --- (In reply to comment #10) > > Author: hjl > Date: Fri Oct 30 16:04:41 2009 > New Revision: 153759 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759 > Log: > 2009-10-30 H.J. Lu > > Backport from mainline: > PR bootstrap/41345 > * gcc.dg/pr41345.c: New test. This one fails: Executing on host: /home/ozzie/gcc44.build/gcc/xgcc -B/home/ozzie/gcc44.build/gcc/ /home/ozzie/gcc44.r153759/gcc/testsuite/gcc.dg/pr41345.c -O2 -g -fcompare -debug -S -o pr41345.s(timeout = 300) cc1: error: unrecognized command line option "-fcompare-debug" compiler exited with status 1 output is: cc1: error: unrecognized command line option "-fcompare-debug" FAIL: gcc.dg/pr41345.c (test for excess errors) Is it not a 4.5-only thing? -- sezeroz at gmail dot com changed: What|Removed |Added CC||sezeroz at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41345
[Bug c/41882] gcc bug when comparing x to -x (linux, 32-bit)
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-10-31 09:38 --- > Thanks for your quick response. I would like to point out that on every > compiler and machine I've used, the behavior of signed overflow may not be > defined -- but it's always been consistent. Consistency on undefined behavior is not mandated (it's a tautology) and would have a substantial cost. You can use -Wstrict-overflow to detect these cases. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41882
[Bug middle-end/41883] [4.5 Regression] ICE from '-O -fprofile-arcs -fsched2-use-superblocks -ftree-vrp -fschedule-insns2 -freorder-blocks'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Summary|ICE from '-O -fprofile-arcs|[4.5 Regression] ICE from '- |-fsched2-use-superblocks - |O -fprofile-arcs -fsched2- |ftree-vrp -fschedule-insns2 |use-superblocks -ftree-vrp - |-freorder-blocks' |fschedule-insns2 -freorder- ||blocks' Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41883
[Bug middle-end/41886] [4.5 Regression] ICE from '-O -ftree-loop-distribution -ftree-vectorize -g'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Component|c |middle-end Summary|ICE from '-O -ftree-loop- |[4.5 Regression] ICE from '- |distribution -ftree-|O -ftree-loop-distribution - |vectorize -g' |ftree-vectorize -g' Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41886
[Bug tree-optimization/41887] ICE from '-O -ftree-loop-distribution -fgraphite-identity -g'
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-31 11:31 --- I suspect another VTA issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41887
[Bug tree-optimization/41888] [4.5 Regression] ICE from '-O -ftree-loop-distribution -fgraphite-identity -g'
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-31 11:32 --- Likewise. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Component|c |tree-optimization Summary|ICE from '-O -ftree-loop- |[4.5 Regression] ICE from '- |distribution -fgraphite-|O -ftree-loop-distribution - |identity -g'|fgraphite-identity -g' Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41888
[Bug middle-end/41889] [4.5 Regression] ICE from '-O2 -fno-omit-frame-pointer -ftracer -fsched2-use-superblocks'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Summary|ICE from '-O2 -fno-omit-|[4.5 Regression] ICE from '- |frame-pointer -ftracer -|O2 -fno-omit-frame-pointer - |fsched2-use-superblocks'|ftracer -fsched2-use- ||superblocks' Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41889
[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-10-31 11:46 --- To reproduce the issue do ../configure --enable-lto --enable-gold --enable-languages=c --prefix=/tmp/install make make install it fails at the make install step because it re-builds lto-plugin there and fails to link. It doesn't fail when not bootstrapping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41569
[Bug c/41567] Too small .bss stack
--- Comment #11 from mans at mansr dot com 2009-10-31 12:28 --- Adding -mno-sdata does not help. Note that the error messages are always referring to .bss, never to .sbss. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41567
[Bug lto/41554] -flto and -fwhopr should be moved to common.opt
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-31 12:52 --- Hmm, -flto and -fwhopr are in common.opt. The -Wpsabi and -Wabi options are not, but I fail to see why this is the fault of LTO. I have a patch to move the -flto / -fwhopr postprocessing to common code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41554
[Bug c/41567] Too small .bss stack
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-10-31 13:01 --- Try dropping -Bsymbolic -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41567
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-10-31 13:05 --- Well, LTO problem fixed. The plugin (GCC plugin, not linker plugin!) testsuite should be fixed up. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/41550] Fix security and portability issues in lto-plugin
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-31 13:11 ---
Some things were fixed. Still open are
> +/* Pass files generated by the lto-wrapper to the linker. FD is lto-wrapper's
> + stdout. */
> +
> +static void
> +add_output_files (FILE *f)
> +{
> + char fname[1000]; /* FIXME: Is this big enough? */
I don't know what sort of strings go there, but if they can be filenames
with user-controlled components then the GNU Coding Standards say to avoid
arbitrary limits.
> + output_files = realloc (output_files, num_output_files * sizeof (char
> *));
> + output_files[num_output_files - 1] = strdup (s);
Use xrealloc and xstrdup. Other places have the same issue with realloc
or calloc or strdup.
Also there are still asserts that look fishy.
assert (lto_wrapper_argv);
temp_obj_dir_name = strdup ("tmp_objectsXX");
t = mkdtemp (temp_obj_dir_name);
assert (t == temp_obj_dir_name);
(see also PR39023)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41550
[Bug target/21080] Excecution test failure for avr for pr17377 test case.
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2009-10-31 15:27 --- *** Bug 21078 has been marked as a duplicate of this bug. *** -- Bug 21080 depends on bug 21078, which changed state. Bug 21078 Summary: Testsuite reports excecution failure for gcc.c-torture/execute/20010122.c for some optimization levels http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21080
[Bug target/21078] Testsuite reports excecution failure for gcc.c-torture/execute/20010122.c for some optimization levels
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2009-10-31 15:27 --- *** This bug has been marked as a duplicate of 21080 *** -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078
[Bug testsuite/41890] New: Invalid g++.dg/lookup/extern-c-redecl[34].Cg++.dg
g++.dg/lookup/extern-c-redecl[34].C have
// { dg-final { scan-assembler-not "call\[\t \]+_Z4forkv" } }
// { dg-final { scan-assembler "call\[\t \]+fork" } }
But asm insns are target specific.
--
Summary: Invalid g++.dg/lookup/extern-c-redecl[34].Cg++.dg
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41890
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #65 from hjl dot tools at gmail dot com 2009-10-31 16:47 --- Here are the differences of "-m32 -O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops" vs. "-m32 -O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops -mstackrealign" using ix86/gcc-4_4-branch on Intel Core i7: 164.gzip -0.604595% 175.vpr -0.0831255% 176.gcc -0.567698% 181.mcf 0.142653% 186.crafty 0.0783699% 197.parser -0.355714% 252.eon -2.32775% 253.perlbmk 0.943693% 254.gap 0.553825% 255.vortex 0.226978% 256.bzip20.291971% 300.twolf0.183936% SPECint_base2000 -0.126734% 168.wupwise -0.345871% 171.swim -1.42753% 172.mgrid0.496166% 173.applu0.467758% 177.mesa 0.151791% 178.galgel -0.227652% 179.art 0.338073% 183.equake -0.308569% 187.facerec 0.189798% 188.ammp 1.00536% 189.lucas-2.18097% 191.fma3d-1.0162% 200.sixtrack 0.237906% 301.apsi 1.00138% SPECfp_base2000 -0.121114% 400.perlbench0.4% 401.bzip20% 403.gcc 0% 429.mcf 0% 445.gobmk-0.478469% 456.hmmer0% 458.sjeng0.452489% 462.libquantum -0.689655% 464.h264ref -0.331126% 471.omnetpp 0.483092% 473.astar0.67% 483.xalancbmk-0.358423% SPECint(R)_base2006 0% 410.bwaves 11.2108% 416.gamess -0.543478% 433.milc 1.37615% 434.zeusmp -0.497512% 435.gromacs 0% 436.cactusADM-0.763359% 437.leslie3d 0.625% 444.namd 0% 447.dealII -0.689655% 450.soplex -1.2987% 453.povray -0.904977% 454.calculix 0.621118% 459.GemsFDTD -0.625% 465.tonto0% 470.lbm 0.925926% 481.wrf -0.588235% 482.sphinx3 -0.96463% SPECfp(R)_base2006 0% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug c/41891] New: ICE in move_loop_invariants
With this compiler frying-pan:~/programs/gambc-v4_5_2-devel> /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline --enable-checking=release --enable-languages=c Thread model: posix gcc version 4.5.0 20091031 (experimental) [trunk revision 153773] (GCC) I get an ICE: frying-pan:~/programs/gambc-v4_5_2-devel> /pkgs/gcc-mainline/bin/gcc -march=core2 -msse4 -save-temps -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -c -o "_io.o" _io.i _io.i: In function ___H__23__23_read_2d_six_2d_datum_2d_or_2d_eof: _io.i:15174:1: internal compiler error: Segmentation fault In gdb I get frying-pan:~/programs/gambc-v4_5_2-devel> gdb /pkgs/gcc-mainline/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1 GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /pkgs/gcc-mainline/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1...done. (gdb) run -march=core2 -msse4 -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp _io.i Starting program: /pkgs/gcc-mainline/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1 -march=core2 -msse4 -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp _io.i btowc wctob mbrlen __signbitf __signbit __signbitl ___H__23__23_read_2d_six_2d_datum_2d_or_2d_eof Analyzing compilation unit Performing interprocedural optimizations <> Assembling functions: ___H__23__23_read_2d_six_2d_datum_2d_or_2d_eof Program received signal SIGSEGV, Segmentation fault. bitmap_clear (head=0x78) at ../../../mainline/gcc/bitmap.c:297 297 if (head->first) (gdb) where #0 bitmap_clear (head=0x78) at ../../../mainline/gcc/bitmap.c:297 #1 0x00622c78 in free_loop_data () at ../../../mainline/gcc/loop-invariant.c:1568 #2 move_loop_invariants () at ../../../mainline/gcc/loop-invariant.c:1906 #3 0x006206d7 in rtl_move_loop_invariants () at ../../../mainline/gcc/loop-init.c:254 #4 0x006544f0 in execute_one_pass (pass=0xf8fc60) at ../../../mainline/gcc/passes.c:1518 #5 0x00654705 in execute_pass_list (pass=0xf8fc60) at ../../../mainline/gcc/passes.c:1567 #6 0x00654717 in execute_pass_list (pass=0xf8fb40) at ../../../mainline/gcc/passes.c:1568 #7 0x00654717 in execute_pass_list (pass=0x1010d60) at ../../../mainline/gcc/passes.c:1568 #8 0x007263dc in tree_rest_of_compilation (fndecl=0x7713fe00) at ../../../mainline/gcc/tree-optimize.c:392 #9 0x00851b7c in cgraph_expand_function (node=0x7713fd00) at ../../../mainline/gcc/cgraphunit.c:1160 #10 0x00853485 in cgraph_expand_all_functions () at ../../../mainline/gcc/cgraphunit.c:1219 #11 cgraph_optimize () at ../../../mainline/gcc/cgraphunit.c:1465 #12 0x0085383f in cgraph_finalize_compilation_unit () at ../../../mainline/gcc/cgraphunit.c:1089 #13 0x0048e45b in c_write_global_declarations () at ../../../mainline/gcc/c-decl.c:9489 #14 0x006e98ac in compile_file (argc=15, argv=0x7fffe5d8) at ../../../mainline/gcc/toplev.c:1061 #15 do_compile (argc=15, argv=0x7fffe5d8) at ../../../mainline/gcc/toplev.c:2408 #16 toplev_main (argc=15, argv=0x7fffe5d8) at ../../../mainline/gcc/toplev.c:2450 #17 0x773d8abd in __libc_start_main () from /lib/libc.so.6 #18 0x0047af09 in _start () at ../sysdeps/x86_64/elf/start.S:113 (gdb) print head $1 = (bitmap) 0x78 I'll add the (unfortunately very long) input file as an attachment. Brad -- Summary: ICE in move_loop_invariants Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41891
[Bug c/41891] ICE in move_loop_invariants
--- Comment #1 from lucier at math dot purdue dot edu 2009-10-31 16:56 --- Created an attachment (id=18942) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18942&action=view) test case This is the test case. BTW, this works in 4.4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41891
[Bug middle-end/39315] Unaligned move used on aligned stack variable
--- Comment #12 from hjl at gcc dot gnu dot org 2009-10-31 16:58 --- Subject: Bug 39315 Author: hjl Date: Sat Oct 31 16:58:17 2009 New Revision: 153780 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153780 Log: gcc/ 2009-10-31 H.J. Lu Backport from mainline: 2009-03-27 H.J. Lu PR middle-end/39315 * cfgexpand.c (expand_one_stack_var_at): Change alignment limit to MAX_SUPPORTED_STACK_ALIGNMENT. gcc/testsuite/ 2009-10-31 H.J. Lu Backport from mainline: 2009-03-27 H.J. Lu PR middle-end/39315 * gcc.target/i386/pr39315-1.c: New. * gcc.target/i386/pr39315-2.c: Likewise. * gcc.target/i386/pr39315-3.c: Likewise. * gcc.target/i386/pr39315-4.c: Likewise. * gcc.target/i386/pr39315-check.c: Likewise. Added: branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39315-1.c branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39315-2.c branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39315-3.c branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39315-4.c branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39315-check.c Modified: branches/ix86/gcc-4_4-branch/gcc/ChangeLog.ix86 branches/ix86/gcc-4_4-branch/gcc/cfgexpand.c branches/ix86/gcc-4_4-branch/gcc/testsuite/ChangeLog.ix86 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39315
[Bug target/21080] Excecution test failure for avr for pr17377 test case.
--- Comment #5 from hutchinsonandy at gcc dot gnu dot org 2009-10-31 17:02 --- Anatoly, can we implement this patch to correct __builtin_return_address and thus remove these old bug reports and associated testsuite failures? It also provides a means to document stack usage which would seem useful. -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added CC||aesok at pautinka dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21080
[Bug testsuite/41890] Invalid g++.dg/lookup/extern-c-redecl[34].Cg++.dg
--- Comment #1 from dominiq at lps dot ens dot fr 2009-10-31 17:10 --- Isn't it a duplicate of pr41856? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41890
[Bug c++/41856] g++.dg/lookup/extern-c-redecl[3,4] .C scan-assembler fails on darwin
--- Comment #9 from dominiq at lps dot ens dot fr 2009-10-31 17:13 --- > The '.*?' is the non greedy form of '.*'. I have learnt regexps at a time when this was not available on all regexp engines, so I always forget such constructs. I think pr41890 is a duplicate of this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41856
[Bug testsuite/41890] Invalid g++.dg/lookup/extern-c-redecl[34].Cg++.dg
--- Comment #2 from hjl dot tools at gmail dot com 2009-10-31 17:31 --- *** This bug has been marked as a duplicate of 41856 *** -- 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=41890
[Bug c++/41856] g++.dg/lookup/extern-c-redecl[3,4] .C scan-assembler fails on darwin
--- Comment #10 from hjl dot tools at gmail dot com 2009-10-31 17:31 --- *** Bug 41890 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41856
[Bug middle-end/41891] ICE in move_loop_invariants
--- Comment #2 from lucier at math dot purdue dot edu 2009-10-31 17:32 --- There is no ICE with heine:~/Desktop> /pkgs/gcc-mainline/bin/gcc -vUsing built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline --enable-languages=c --disable-multilib Thread model: posix gcc version 4.5.0 20091005 (experimental) [trunk revision 152459] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41891
[Bug c/41867] Translation time Floating Point precision is too small
--- Comment #4 from tydeman at tybor dot com 2009-10-31 17:42 --- The requirement that translation time precision be at least as great as runtime precision existed in C89, C90, C95, and C99 (so has been around for 20 years). My code is a test of translation time precision versus runtime precision. The first code I saw in bug 323 involved 3 auto variables (so is just runtime). That is a different issue, so I believe that this bug is not a duplicate of 323. I used gnu99 instead of c99 for the std because I also am testing Decimal FP in addition to Binary FP. Where should I find documentation on compiler options to get as close to C99 conformance as possible? Also, C99 + Decimal FP conformance? The output you show is what I expected. -- tydeman at tybor dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41867
[Bug c++/41892] New: generated code increments past enum boundary
i.e. the attached code is fine on x86_64 but crashes on s390x with g++ -O2 -fpic demo.cxx it does not crash with g++ -O2 demo.cxx or g++ -fpic demo.cxx expected output is... 0 3 0 3 0 3 1 3 2 3 1 3 0 3 1 3 1 3 2 3 2 3 0 3 2 3 1 3 2 3 0 3 0 3 0 3 1 3 2 3 1 3 0 3 1 3 1 3 2 3 2 3 0 3 2 3 1 3 2 3 0 3 0 3 1 3 1 3 2 3 2 3 actual output is... 0 3 0 3 0 3 1 3 2 3 0 3 3 3 0 3 4 3 0 3 5 3 0 3 6 3 0 3 7 3 0 3 8 ... crash -- Summary: generated code increments past enum boundary Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: caolanm at redhat dot com GCC host triplet: s390x-ibm-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41892
[Bug c++/41892] generated code increments past enum boundary
--- Comment #1 from caolanm at redhat dot com 2009-10-31 17:51 --- Created an attachment (id=18943) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18943&action=view) demo code s390x-redhat-linux-g++ -O2 -fpic demo.cxx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41892
[Bug c++/41892] generated code increments past enum boundary
--- Comment #2 from caolanm at redhat dot com 2009-10-31 17:52 --- $ gcc --version gcc (GCC) 4.4.2 20091019 (Red Hat 4.4.2-5) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41892
[Bug c++/41847] warning: array subscript is above array bounds
--- Comment #5 from caolanm at redhat dot com 2009-10-31 17:59 --- bug 41892 now logged for the concrete runtime problem I'm encountering. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41847
[Bug c/41867] Translation time Floating Point precision is too small
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-10-31 18:37 ---
323 covers all excess precision issues. Predictable results that do
not depend on when a computation is carried out require
-fexcess-precision=standard which requires 4.5. It so happens that all
C conformance options, including -std=c89, enable -fexcess-precision=standard;
although C90 does not define any standard binding to excess precision such
as C99 does with FLT_EVAL_METHOD, enabling it for C90 conformance seemed the
best compromise.
Options are documented in the GCC manual (specifically, invoke.texi
in the GCC sources). The closest conformance options are
-std={c89,iso9899:199409,c99} -pedantic (or -pedantic-errors if you want
errors for constraint violations). There are no known target-independent
conformance bugs in -std=c89 -pedantic or -std=iso9899:199409 -pedantic
(excess precision issues are target-dependent) in 4.5 (there are various
such bugs in 4.4).
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
is the online version of the documentation for conformance options;
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
includes the floating-point options and
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
describes -pedantic.
There are no options to enable C99 conformance except for allowing decimal
floating point. If you want -fdecimal-fp or similar to enable decimal
floating point in a strict conformance mode, that would be a separate issue.
*** This bug has been marked as a duplicate of 323 ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41867
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #135 from jsm28 at gcc dot gnu dot org 2009-10-31 18:37 --- *** Bug 41867 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug debug/41893] New: ICE with -combine and debug
[From https://bugzilla.redhat.com/show_bug.cgi?id=531385 ]
Testcase:
cat > file1.c << EOF
struct s1_s {
int v;
};
struct s1_s g1;
void __attribute__((externally_visible)) func1() {
struct s1_s *l1 = &g1;
}
EOF
cat > file2.c << EOF
extern struct s1_s g1;
void func2() {
&g1;
}
EOF
cc -O -g -fwhole-program -combine -c file1.c file2.c
Caused by SVN r152403:
PR debug/41404
PR debug/41353
* cfgexpand.c (expand_debug_expr) : Don't create
CONST_STRING if STRING_CST contains embedded '\0's or doesn't end with
'\0'.
(expand_debug_expr) : For TREE_STATIC !DECL_EXTERNAL
vars use DECL_RTL with resetting it back to NULL afterwards.
* dwarf2out.c (same_dw_val_p): For dw_val_class_addr compare with
rtx_equal_p instead of asserting it is a SYMBOL_REF.
(value_format): For dw_val_class_addr only use DW_FORM_addr if
the attribute type allows it, otherwise use DW_FORM_dataN.
(mem_loc_descriptor): Handle CONST_STRING.
(add_const_value_attribute): Handle CONST_STRING using add_AT_addr.
Handle MEM with CONST_STRING address using add_AT_string.
(rtl_for_decl_init): Return MEM with CONST_STRING address instead of
CONST_STRING for const arrays initialized with a string literal.
(resolve_one_addr, resolve_addr_in_expr, resolve_addr): New functions.
(dwarf2out_finish): Call resolve_addr.
* gcc.dg/guality/pr41404-1.c: New test.
* gcc.dg/guality/pr41353-2.c: New test.
--
Summary: ICE with -combine and debug
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segher at kernel dot crashing dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41893
[Bug c++/41754] initializer list internal compiler segfault
--- Comment #1 from jason at gcc dot gnu dot org 2009-10-31 21:12 --- Confirmed with current 4.4 branch. 4.5 doesn't segfault for some reason, but we run into the same invalid code. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-31 21:12:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41754
[Bug c/41894] New: wrong code with -fno-split-wide-types
Commandline:
avr-gcc -S -mmcu=atmega128 -Os
-fno-inline-small-functions -fno-split-wide-types bug.c
Sourcecode:
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef union
{
struct {
uint8_t sekunden;
uint8_t minuten;
} x;
uint16_t sekmin;
} zeit_t;
void testmich2 (zeit_t tmp) {
// just something that cannot be optimized out
asm volatile("nop");
}
void testmich (zeit_t zeit) {
zeit_t tmp;
tmp.x = zeit.x;
do {
testmich2(tmp);
if (tmp.x.sekunden)
tmp.x.sekunden--;
else {
tmp.x.sekunden = 59;
tmp.x.minuten--;
}
} while (tmp.x.sekunden || tmp.x.minuten);
}
int main (void) {
zeit_t zeit;
zeit.x.minuten = 1;
zeit.x.sekunden = 2;
testmich(zeit);
return 0;
}
The statements
if (tmp.x.sekunden)
tmp.x.sekunden--;
translate to:
mov r18,r28
subi r18,lo8(-(-1))
movw r28,r18
which is wrong; r19 (used by movw) has a not defined value.
--
Summary: wrong code with -fno-split-wide-types
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frank at mynety dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
[Bug testsuite/41856] g++.dg/lookup/extern-c-redecl[3,4] .C should be target specific
--- Comment #11 from danglin at gcc dot gnu dot org 2009-10-31 22:00 --- Also fail on hppa*-*-hpux*. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41856
[Bug target/41894] wrong code with -fno-split-wide-types
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2009-10-31 23:02 --- Please post entire assembler code. -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added CC||hutchinsonandy at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
[Bug target/41894] wrong code with -fno-split-wide-types
--- Comment #2 from j at uriah dot heep dot sax dot de 2009-10-31 23:10 --- Created an attachment (id=18944) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18944&action=view) Full assembler code I get from GCC 4.3.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
[Bug target/41894] wrong code with -fno-split-wide-types
--- Comment #3 from j at uriah dot heep dot sax dot de 2009-10-31 23:11 --- The bug was originally reported in the (Germany-language) mikrocontroller.net forum, and I confirmed the bug on my local GCC 4.3.2 setup before asking Frank to submit it as an official bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
[Bug target/41894] wrong code with -fno-split-wide-types
-- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.2 Last reconfirmed|-00-00 00:00:00 |2009-10-31 23:55:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
[Bug c++/41754] initializer list internal compiler segfault
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-01 05:06 --- Subject: Bug 41754 Author: jason Date: Sun Nov 1 05:06:42 2009 New Revision: 153788 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153788 Log: PR c++/41754 * call.c (compare_ics): Avoid bad union use when comparing two ck_lists. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist25.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41754
[Bug c++/41754] initializer list internal compiler segfault
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-01 05:27 --- Subject: Bug 41754 Author: jason Date: Sun Nov 1 05:27:04 2009 New Revision: 153791 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153791 Log: PR c++/41754 * call.c (compare_ics): Avoid bad union use when comparing two ck_lists. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/initlist25.C - copied unchanged from r153788, trunk/gcc/testsuite/g++.dg/cpp0x/initlist25.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/call.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41754
