[Bug bootstrap/58509] [4.9 regression] ICE in calc_dfs_tree, at dominance.c:397 breaks Ada bootstrap on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58509 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- (gdb) break fancy_abort Breakpoint 2 at 0x9e4a04 (gdb) run -gnatwa -quiet -nostdinc -dumpbase g-awk.adb -auxbase-strip g-awk.o -O2 -Wextra -Wall -fPIC -g -gnatpg -mcpu=ultrasparc -gnatO g-awk.o g-awk.adb -o /tmp/ccUyexwj.s Starting program: /mnt/scratch/objdir49/gcc/gnat1 -gnatwa -quiet -nostdinc -dumpbase g-awk.adb -auxbase-strip g-awk.o -O2 -Wextra -Wall -fPIC -g -gnatpg -mcpu=ultrasparc -gnatO g-awk.o g-awk.adb -o /tmp/ccUyexwj.s Breakpoint 2, 0x009e4a04 in fancy_abort(char const*, int, char const*) () (gdb) bt #0 0x009e4a04 in fancy_abort(char const*, int, char const*) () #1 0x00409bbc in calc_dfs_tree(dom_info*, bool) () at /mnt/scratch/gcc-4.9-20130922/gcc/dominance.c:397 #2 0x0040a234 in calculate_dominance_info(cdi_direction) () at /mnt/scratch/gcc-4.9-20130922/gcc/dominance.c:658 #3 0x003be1f4 in flow_loops_find(loops*) () #4 0x00570630 in loop_optimizer_init(unsigned int) () at /mnt/scratch/gcc-4.9-20130922/gcc/loop-init.c:91 #5 0x00965c30 in if_convert(bool) () at /mnt/scratch/gcc-4.9-20130922/gcc/ifcvt.c:4377 #6 0x009676b0 in (anonymous namespace)::pass_if_after_reload::execute() () at /mnt/scratch/gcc-4.9-20130922/gcc/ifcvt.c:4587 #7 0x005d9ef4 in execute_one_pass(opt_pass*) () at /mnt/scratch/gcc-4.9-20130922/gcc/passes.c:2201 #8 0x005da13c in execute_pass_list(opt_pass*) () at /mnt/scratch/gcc-4.9-20130922/gcc/passes.c:2253 #9 0x005da160 in execute_pass_list(opt_pass*) () at /mnt/scratch/gcc-4.9-20130922/gcc/passes.c:2254 #10 0x005da160 in execute_pass_list(opt_pass*) () at /mnt/scratch/gcc-4.9-20130922/gcc/passes.c:2254 #11 0x003d98f4 in expand_function(cgraph_node*) () at /mnt/scratch/gcc-4.9-20130922/gcc/cgraphunit.c:1750 #12 0x003db730 in compile() () at /mnt/scratch/gcc-4.9-20130922/gcc/cgraphunit.c:1855 #13 0x003dbb80 in finalize_compilation_unit() () at /mnt/scratch/gcc-4.9-20130922/gcc/cgraphunit.c:2269 #14 0x0006bcbc in gnat_write_global_declarations() () at /mnt/scratch/gcc-4.9-20130922/gcc/ada/gcc-interface/utils.c:5630 #15 0x00692200 in compile_file() () #16 0x006940bc in toplev_main(int, char**) () #17 0xf7d44234 in __libc_start_main () from /lib/libc.so.6 #18 0x00044054 in _start () (gdb)
[Bug target/58493] loop is not correctly optimized with O3 and AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58493 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- The C test case started working for 4.9 with Richard's Vectorizer TLC: re-organize data dependence checking patch in r196872. The original patch description http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01238.html doesn't mention any wrong-code fixes in that patch. The code generation difference on the test case at r196872 is: --- pr54893.s-r196871 2013-09-23 14:51:29.441292880 +0200 +++ pr54893.s-r196872 2013-09-23 14:54:55.000501714 +0200 @@ -12,8 +12,6 @@ sarl%edi testl %edi, %edi jle .L25 - cmpl$8, %edi - jbe .L3 leaq64(%rsi), %rax cmpq%rax, %rdx leaq64(%rdx), %rax @@ -22,6 +20,8 @@ setae %al orb %al, %cl je .L3 + cmpl$9, %edi + jbe .L3 leal-1(%rdi), %r9d vmovapd .LC0(%rip), %ymm1 movq%rdx, %rax
[Bug bootstrap/58509] New: [4.9 regression] ICE in calc_dfs_tree, at dominance.c:397 breaks Ada bootstrap on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58509 Bug ID: 58509 Summary: [4.9 regression] ICE in calc_dfs_tree, at dominance.c:397 breaks Ada bootstrap on sparc64-linux Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpe at it dot uu.se Host: sparc64-linux Target: sparc-linux Build: sparc-linux Attempting to bootstrap gcc-4.9-20130922 on sparc64-linux fails with: /mnt/scratch/objdir49/./gcc/xgcc -B/mnt/scratch/objdir49/./gcc/ -B/mnt/scratch/install49/sparc-unknown-linux/bin/ -B/mnt/scratch/install49/sparc-unknown-linux/lib/ -isystem /mnt/scratch/install49/sparc-unknown-linux/include -isystem /mnt/scratch/install49/sparc-unknown-linux/sys-include-c -g -O2 -fPIC -W -Wall -gnatpg -nostdinc g-awk.adb -o g-awk.o +===GNAT BUG DETECTED==+ | 4.9.0 20130922 (experimental) (sparc-unknown-linux) GCC error: | | in calc_dfs_tree, at dominance.c:397 | | Error detected around g-awk.adb:264:9| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). system.ads g-awk.adb g-awk.ads gnat.ads ada.ads a-finali.ads s-finroo.ads g-regpat.ads s-regpat.ads a-except.ads s-parame.ads s-stalib.ads a-unccon.ads s-traent.ads a-textio.ads a-ioexce.ads a-stream.ads s-ficobl.ads interfac.ads i-cstrea.ads s-crtl.ads s-wchcon.ads a-string.ads a-strunb.ads a-strmap.ads a-charac.ads a-chlat1.ads a-strfix.ads a-uncdea.ads g-dirope.ads g-dyntab.ads g-os_lib.ads s-os_lib.ads s-string.ads s-exctab.ads a-tags.ads s-stoele.ads s-stoele.adb s-soflin.ads s-stache.ads s-finmas.ads s-stopoo.ads s-pooglo.ads s-unstyp.ads s-stratt.ads s-secsta.ads s-stposu.ads s-ststop.ads s-imgint.ads s-valint.ads s-valrea.ads g-dyntab.adb g-hesorg.ads s-memory.ads g-hesorg.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:432 make[7]: *** [g-awk.o] Error 1 make[7]: Leaving directory `/mnt/scratch/objdir49/gcc/ada/rts' make[6]: *** [gnatlib] Error 2 make[6]: Leaving directory `/mnt/scratch/objdir49/gcc/ada' make[5]: *** [gnatlib-shared-default] Error 2 make[5]: Leaving directory `/mnt/scratch/objdir49/gcc/ada' make[4]: *** [gnatlib-shared-dual] Error 2 make[4]: Leaving directory `/mnt/scratch/objdir49/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/mnt/scratch/objdir49/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir49/sparc-unknown-linux/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir49' make: *** [bootstrap] Error 2 The previous weekly snapshot, gcc-4.9-20130915, bootstrapped fine on this machine. I haven't seen this failure on x86_64 or powerpc64 (armv5tel is still building). Configuration options: --prefix=/mnt/scratch/install48 --with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-5.1.2 --with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.2 --with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-1.0.1 --enable-multilib --disable-plugin --disable-lto --disable-nls --enable-threads=posix --enable-checking=release --disable-libmudflap --enable-languages=c,c++,fortran,ada --build=sparc-unknown-linux --target=sparc-unknown-linux --with-cpu=ultrasparc --enable-targets=all
[Bug bootstrap/58368] [4.9 regression] bootstrap comparison failure in expr.o and i386.o on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58368 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- This bootstrap failure is gone as of gcc-4.9-20130915 aka rev 202605.
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Earnie from comment #4) Your statement doesn't resolve anything at all. It is fine for gcc to require c++ but it is not fine for configure to continue if I only specify c and c++ is also built without an error being issued by configure stating that c++ is required. Previous versions of GCC I was able to build only c and c++ wasn't considered. Secondly, what is wrong with the process using an already installed c++ version to build gcc when only c is requested to be built? I should be able to expect to build only the language compiler requested without another language compiler being built along with it. Use --disable-bootstrap for a native compiler if you want only C.
[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369
--- Comment #4 from Mikael Pettersson mikpe at it dot uu.se ---
(All source references here are for vanilla gcc-4.8.1.)
The problem appears to start in choose_reload_regs, in the if (inheritance)
block at lines 6497 to 6679. It finds (reg:DF 0 %d0 [orig:109 D.2384 ] [109])
in rld[r].in. The if (regno = 0 ...) test at line 6543 passes so that block
is entered. last_reg is (reg:XF 17 %fp1) and byte is still 0, so it calls
subreg_regno_offset (17, XFmode, 0, DFmode) at line 6560.
subreg_regno_offset in turn just calls subreg_get_info.
In subreg_get_info xmode is XFmode with size 12 and precision 80, while ymode
is DFmode with size 8 and precision 64.
The first if (HARD_REGNO_NREGS_HAS_PADDING ...) is false so that block is
skipped. nregs_xmode and nregs_ymode are computed, both are 1.
The second if for paradoxical subregs is false, so that block is skipped.
The third if If registers store different numbers of bits in the different
modes, we cannot generally form this subreg at line 3345 is true, so that
block is entered. regsize_xmode and regsize_ymode are computed, they are 12
and 8 respectively. None of the inner if:s there are true, because nregs_xmode
and nregs_ymode are both 1, which isn't 1, so we don't return.
The fourth if for lowpart subregs at line 3371 is false, because the input
offset is 0 (byte from choose_reload_regs), but subreg_lowpart_offset
(DFmode, XFmode) returns 4, and 0 != 4. So that block is skipped.
Next we reach the gcc_assert ((GET_MODE_SIZE (xmode) % GET_MODE_SIZE (ymode))
== 0); at line 3387. However, this evaluates as (12 % 8) == 0, which is
false, so the assertion fails and we ICE.
So the problem as I understand it is that choose_reload_regs forms a virtual
subreg with differently-sized modes and offset 0, while on big-endian machines
the offset must be 0 (see subreg_lowpart_offset in emit-rtl.c), so the virtual
subreg is not recognized as a normal lowpart subreg.
I *think* other machines don't see this problem because:
a) offset 0 is correct for little-endian like x86 and most ARMs,
b) many big-endian machines define CANNOT_CHANGE_MODE_CLASS to reject
differently-sized modes in floating-point registers, which can prevent the
bogus subreg_regno_offset call,
c) their larger modes are whole multiples of their smaller modes, so the
assertion doesn't fail.
However, m68k:
d) is big-endian,
e) doesn't define CANNOT_CHANGE_MODE_CLASS,
f) has an XFmode which is 1.5 times as large as its DFmode.
If I add a suitable definition of CANNOT_CHANGE_MODE_CLASS, e.g.
--- gcc-4.8.1/gcc/config/m68k/m68k.h.~1~2013-01-10 21:38:27.0
+0100
+++ gcc-4.8.1/gcc/config/m68k/m68k.h2013-09-11 18:28:58.160242077 +0200
@@ -409,6 +409,11 @@ along with GCC; see the file COPYING3.
#define HARD_REGNO_MODE_OK(REGNO, MODE) \
m68k_regno_mode_ok ((REGNO), (MODE))
+#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
+ (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \
+ ? reg_classes_intersect_p (FP_REGS, CLASS) \
+ : 0)
+
#define SECONDARY_RELOAD_CLASS(CLASS, MODE, X) \
m68k_secondary_reload_class (CLASS, MODE, X)
then the ICE disappears. However, reading the m68k backend I think this is
against its intentions, and I suspect it is stricter than necessary.
Other calls to subreg_regno_offset either take the parameters from an existing
real subreg, or compute a correct lowpart offset (regcprop.c:maybe_mode_change,
var-tracking.c:var_lowpart). So I'm starting to think that the bug is in
choose_reload_regs: it should pass a proper lowpart offset in byte, not the
constant 0 (byte is only set for input subregs that are pseudos). The
following patch:
--- gcc-4.8.1/gcc/reload1.c.~1~ 2013-01-21 15:55:05.0 +0100
+++ gcc-4.8.1/gcc/reload1.c 2013-09-11 19:58:37.979482251 +0200
@@ -6497,6 +6497,7 @@ choose_reload_regs (struct insn_chain *c
if (inheritance)
{
int byte = 0;
+ bool byte_is_fixed = false;
int regno = -1;
enum machine_mode mode = VOIDmode;
@@ -6519,7 +6520,10 @@ choose_reload_regs (struct insn_chain *c
if (regno FIRST_PSEUDO_REGISTER)
regno = subreg_regno (rld[r].in_reg);
else
- byte = SUBREG_BYTE (rld[r].in_reg);
+ {
+ byte = SUBREG_BYTE (rld[r].in_reg);
+ byte_is_fixed = true;
+ }
mode = GET_MODE (rld[r].in_reg);
}
#ifdef AUTO_INC_DEC
@@ -6557,6 +6561,8 @@ choose_reload_regs (struct insn_chain *c
rtx last_reg = reg_last_reload_reg[regno];
i = REGNO (last_reg);
+ if (! byte_is_fixed)
+ byte = subreg_lowpart_offset (mode, GET_MODE (last_reg));
i += subreg_regno_offset (i, GET_MODE (last_reg), byte,
mode);
last_class
[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- Created attachment 30783 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30783action=edit smaller test case, from C-reduce
[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- Created attachment 30787 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30787action=edit hand-reduced test case This is as small as I can get it without losing the ICE.
[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- The ICE occurs because reload is asking for a DFmode (8-byte) subreg of an XFmode (12-byte) hardreg, but 12 % 8 != 0 so the gcc_assert fails.
[Bug bootstrap/58368] New: [4.9 regression] bootstrap comparison failure in expr.o and i386.o on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58368 Bug ID: 58368 Summary: [4.9 regression] bootstrap comparison failure in expr.o and i386.o on x86_64-linux Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpe at it dot uu.se Attempting to bootstrap gcc-4.9-20130908 (r202372) on x86_64-linux fails with: make[3]: Leaving directory `/mnt/scratch/objdir49' Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/expr.o differs gcc/i386.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/mnt/scratch/objdir49' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir49' make: *** [bootstrap] Error 2 The previous weekly snapshot, 4.9-20130901, bootstrapped fine. Configuration: /mnt/scratch/gcc-4.9-20130908/configure --prefix=/mnt/scratch/install49 --with-gmp=/home/mikpe/pkgs/linux-x86_64/gmp-5.1.2 --with-mpfr=/home/mikpe/pkgs/linux-x86_64/mpfr-3.1.2 --with-mpc=/home/mikpe/pkgs/linux-x86_64/mpc-1.0.1 --disable-plugin --disable-lto --disable-nls --enable-threads=posix --enable-checking=release --disable-libmudflap --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go
[Bug bootstrap/58368] [4.9 regression] bootstrap comparison failure in expr.o and i386.o on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58368 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- Applying r202379 didn't fix the comparison failure, but reverting r202345 did.
[Bug rtl-optimization/58369] New: [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369 Bug ID: 58369 Summary: [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mikpe at it dot uu.se Created attachment 30773 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30773action=edit Pre-processed non-reduced test case Attempting to compile boost-1.54 with g++ 4.8 or 4.9 for m68k-linux (after fixing a known boost alignment error that breaks jam) causes an ICE: g++ -O2 -fPIC -S ellint_3f.ii In file included from ./boost/math/special_functions/ellint_3.hpp:22:0, from ./boost/math/special_functions.hpp:27, from libs/math/src/tr1/pch.hpp:9, from libs/math/build/../src/tr1/ellint_3f.cpp:6: ./boost/math/special_functions/ellint_rj.hpp: In function 'T boost::math::detail::ellint_rj_imp(T, T, T, T, const Policy) [with T = double; Policy = boost::math::policies::policyboost::math::policies::domain_error(boost::math::policies::error_policy_type)1u, boost::math::policies::pole_error(boost::math::policies::error_policy_type)1u, boost::math::policies::overflow_error(boost::math::policies::error_policy_type)1u, boost::math::policies::evaluation_error(boost::math::policies::error_policy_type)1u, boost::math::policies::rounding_error(boost::math::policies::error_policy_type)1u, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy]': ./boost/math/special_functions/ellint_rj.hpp:151:1: internal compiler error: in subreg_get_info, at rtlanal.c:3394 0x76ca1c subreg_get_info(unsigned int, machine_mode, unsigned int, machine_mode, subreg_info*) /tmp/gcc-4.8-r193425/gcc/rtlanal.c:3394 0x76ca2b subreg_regno_offset(unsigned int, machine_mode, unsigned int, machine_mode) /tmp/gcc-4.8-r193425/gcc/rtlanal.c:3446 0x75d1f0 choose_reload_regs /tmp/gcc-4.8-r193425/gcc/reload1.c:6564 0x761227 reload_as_needed /tmp/gcc-4.8-r193425/gcc/reload1.c:4648 0x766f5e reload(rtx_def*, int) /tmp/gcc-4.8-r193425/gcc/reload1.c:1055 0x6ab68b do_reload /tmp/gcc-4.8-r193425/gcc/ira.c:4636 0x6ab68b rest_of_handle_reload /tmp/gcc-4.8-r193425/gcc/ira.c:4737 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. 4.7 is Ok. Started with Bin Cheng's r193425. Reproducible with a cross. Originally from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719484. Currently attempting to auto-reduce the test case, but it's a painfully slow process.
[Bug ipa/58345] ICE with SIGFPE at -O1 on x86_64-linux-gnu (affecting trunk and 4.8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58345
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se ---
I can reproduce with 4.8 and trunk. Crashes due to division by zero in
fold_array_ctor_reference:
/* And offset within the access. */
inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
Program received signal SIGFPE, Arithmetic exception.
0x005e2448 in fold_array_ctor_reference (ctor=0x77627ca8,
ctor=0x77627ca8, from_decl=0x77535be0, size=0, offset=0,
type=0x77645540)
at /mnt/scratch/gcc-4.9-20130901/gcc/gimple-fold.c:2816
2816 inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
(gdb) print elt_size
$1 = {low = 0, high = 0}
(gdb) q
Note that the test case has a static array of an empty struct type.
[Bug ipa/58346] ICE with SIGFPE at -O1 and above on x86_64-linux-gnu (affecting trunk, 4.8, 4.7, and 4.6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se ---
Crashes with division-by-zero in the exact same spot as the PR58345 test case
does. However this test case also crashes 4.7 and 4.6.
Program received signal SIGFPE, Arithmetic exception.
0x005e2448 in fold_array_ctor_reference (ctor=0x77627ca8,
ctor=0x77627ca8, from_decl=0x77535be0, size=0, offset=0,
type=0x77645540)
at /mnt/scratch/gcc-4.9-20130901/gcc/gimple-fold.c:2816
2816 inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
(gdb) list
2811 if (index_type)
2812access_index = access_index.ext (TYPE_PRECISION (index_type),
2813 TYPE_UNSIGNED (index_type));
2814
2815 /* And offset within the access. */
2816 inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
2817
2818 /* See if the array field is large enough to span whole access. We
do not
2819 care to fold accesses spanning multiple array indexes. */
2820 if (inner_offset + size elt_size.to_uhwi () * BITS_PER_UNIT)
(gdb) print elt_size
$1 = {low = 0, high = 0}
(gdb) q
[Bug c/58349] ARMv7: ICE in vect_determine_vectorization_factor, at tree-vect-loop.c:349
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58349 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- I can't reproduce the ICE with either one of gcc 4.6.3, 4.6.4, 4.7.3, or 4.8.1, configured as crosses to armv7l-linux-gnueabi from x86_64-linux, with options -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 -mthumb -O3 -fstack-protector. Looks like you're running a heavily modified native compiler from Ubuntu. Please report this ICE to them (unless you can reproduce with a vanilla FSF version).
[Bug bootstrap/58242] [4.9 regression] linux-android.c:40:7: error: 'OPTION_BIONIC' was not declared in this scope breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58242 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se --- Yes, bootstrap is restored on powerpc64-linux with trunk @ 202274. Closing.
[Bug c/58287] [4.9 regression] internal compiler error: in c_builtin_function_ext_scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58287 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- This is a duplicate of PR57848.
[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58260 --- Comment #11 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to anand.karanam from comment #9) Do we need to have a copy of the Linux host includes and libraries to prepare the cross compiler? Or can we avoid this with newlib build and using the same? Attached the config file for libgomp. Yes, to build a fully functional cross to i686-pc-linux-gnu you'll need glibc headers and include files. With newlib you may be able to avoid those dependencies, but you'll then also have to disable non-core functionality, like (apparently) libgomp. This is clearly not a gcc bug. Please direct further questions to the gcc-help list.
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se --- Your examples are invalid C. In one module you present the compiler with a specific declaration, and complain when it utilizes constraints derived from that declaration. Then in another module you have an _incompatible_ declaration for the same object. You can't expect to get away with that, even if it seemed to work with an older compiler. You should use a C99 flexible array member, or a pointer (to an array of unknown size).
[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58260 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to anand.karanam from comment #0) checking for suffix of object files... configure: error: in `/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/ sparc-sun-solaris2.10-i686-pc-linux-gnu/i686-pc-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1 gmake[1]: Leaving directory `/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/ sparc-sun-solaris2.10-i686-pc-linux-gnu' make: *** [all] Error 2 You need to look in that config.log file to see what the error was. There are several config.log files in the build tree, it should be in a `libgcc' sub-directory. I usually do 'find . -name config.log | xargs ls -tl | head' to find the most recent one (which will be the one with the final hard error).
[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58260
--- Comment #4 from Mikael Pettersson mikpe at it dot uu.se ---
You got several 'conftest.c:16:1: internal compiler error: Bus Error' from the
newly built compiler.
You should try one of those compilation attempts manually, in gdb, to see where
the SIGBUS is coming from.
I see that you configured with --with-{gmp,mpfr,mpc} pointing into a private
install. That's OK, but unless you built those libraries with --disable-shared
you also have to set up LD_LIBRARY_PATH so that they can be found by the
dynamic linker. Otherwise it might load incompatible versions installed
elsewhere.
(I always build gmp/mpfr/mpc with --disable-shared exactly to avoid such
issues.)
[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58260 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Jonathan Wakely from comment #6) (In reply to Mikael Pettersson from comment #4) (I always build gmp/mpfr/mpc with --disable-shared exactly to avoid such issues.) Why not just build them in tree and avoid all problems? Because 1. building those libraries with --disable-shared and pointing gcc's configure to them (--with-gmp= etc) is trivial and also avoids the problems, 2. I build gcc a lot (several branches x several architectures), I really don't want to waste time and electricity rebuilding those libraries again and again, 3. I want precise control over which versions of those libraries I'm testing, 4. as a matter of principle I think pre-requisites should be strictly external to the gcc build process, otherwise were do we stop? should we download and build make, bash, coreutils, gdb, expect, glibc, ... just because the build needs them? special-casing gmp/mpfr/mpc is completely unnecessary
[Bug bootstrap/58242] New: [4.9 regression] linux-android.c:40:7: error: 'OPTION_BIONIC' was not declared in this scope breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58242 Bug ID: 58242 Summary: [4.9 regression] linux-android.c:40:7: error: 'OPTION_BIONIC' was not declared in this scope breaks bootstrap on powerpc64-linux Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpe at it dot uu.se Attempting to bootstrap gcc-4.9-20130825 on powerpc64-linux fails with: g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/mnt/archive/gcc-4.9-20130825/gcc -I/mnt/archive/gcc-4.9-20130825/gcc/. -I/mnt/archive/gcc-4.9-20130825/gcc/../include -I/mnt/archive/gcc-4.9-20130825/gcc/../libcpp/include -I/home/mikpe/pkgs/linux-ppc64/gmp-5.1.2/include -I/home/mikpe/pkgs/linux-ppc64/mpfr-3.1.2/include -I/home/mikpe/pkgs/linux-ppc64/mpc-1.0.1/include -I/mnt/archive/gcc-4.9-20130825/gcc/../libdecnumber -I/mnt/archive/gcc-4.9-20130825/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/archive/gcc-4.9-20130825/gcc/../libbacktrace-I. -I. -I/mnt/archive/gcc-4.9-20130825/gcc -I/mnt/archive/gcc-4.9-20130825/gcc/. -I/mnt/archive/gcc-4.9-20130825/gcc/../include -I/mnt/archive/gcc-4.9-20130825/gcc/../libcpp/include -I/home/mikpe/pkgs/linux-ppc64/gmp-5.1.2/include -I/home/mikpe/pkgs/linux-ppc64/mpfr-3.1.2/include -I/home/mikpe/pkgs/linux-ppc64/mpc-1.0.1/include -I/mnt/archive/gcc-4.9-20130825/gcc/../libdecnumber -I/mnt/archive/gcc-4.9-20130825/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/archive/gcc-4.9-20130825/gcc/../libbacktrace \ /mnt/archive/gcc-4.9-20130825/gcc/config/linux-android.c /mnt/archive/gcc-4.9-20130825/gcc/config/linux-android.c: In function 'bool linux_android_libc_has_function(function_class)': /mnt/archive/gcc-4.9-20130825/gcc/config/linux-android.c:40:7: error: 'OPTION_BIONIC' was not declared in this scope make[3]: *** [linux-android.o] Error 1 The previous weekly snapshot, 4.9-20130818, bootstrapped fine on this machine.
[Bug target/58208] dequestd::string 32-bit -O3 bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se --- Unmodified FSF gcc-4.8.1 configured as follows: /tmp/gcc-4.8.1/configure --prefix=/tmp/install --with-gmp=/path/to/my/gmp-5.1.2 --with-mpfr=/path/to/my/mpfr-3.1.2 --with-mpc=/path/to/my/mpc-1.0.1 --enable-multilib --enable-checking=release --enable-languages=c,c++
[Bug target/58208] dequestd::string 32-bit -O3 bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se --- I've just bootstrapped gcc-4.8.1 on CentOS 5.8 (the closest I have to the OP's RHEL 5.5), and LD_LIBRARY_PATH=. ./import does indeed SEGV there.
[Bug target/58208] dequestd::string 32-bit -O3 bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se --- CentOS 5.8 has an old binutils-2.17.50.0.6-20.el5_8.3. Building and installing binutils-2.23.2 and rebuilding gcc-4.8.1 against that makes no difference, ./import still SEGVs. I'm beginning to suspect a glibc-2.5 compatibility issue.
[Bug target/58208] dequestd::string 32-bit -O3 bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- I can't reproduce the SEGV on Fedora 17 with gcc-4.8.1 -m32 or gcc-4.9 -m32. However, I think the build recipe is flawed. If I follow it to the letter (with -Wl,-rpath pointing to where I installed gcc-4.8) the `import' binary fails because it can't find libqt.so: ./import ./import: error while loading shared libraries: libqt.so: cannot open shared object file: No such file or directory ldd ./import linux-gate.so.1 = (0xf76e4000) libqt.so = not found libstdc++.so.6 = /tmp/install/lib/libstdc++.so.6 (0xf75f1000) libm.so.6 = /lib/libm.so.6 (0xf75c6000) libgcc_s.so.1 = /tmp/install/lib/libgcc_s.so.1 (0xf75ac000) libc.so.6 = /lib/libc.so.6 (0xf73f9000) /lib/ld-linux.so.2 (0xf76e5000) With LD_LIBARY_PATH=.: ./import runs fine w/o error with gcc-4.8.1. Perhaps your `import' is picking up another libqt.so from a system directory, and there's a C++ ABI incompatibility between that one and 4.8.1?
[Bug target/58218] -mcmodel=medium cause assembler warning ignoring incorrect section type for .lbss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58218 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- I can reproduce with gcc-4.7.3. It generates: .section.lbss,aw,@progbits gas doesn't like ,@progbits on .lbss and ignores it; readelf on the produced .o file then shows: [ 4] .lbss NOBITS 40 010004 00 WAl 0 0 32 which appears to confirm that @progbits is wrong. (.bss is also NOBITS.)
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #20 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Thorsten Glaser from comment #19) Created attachment 30668 [details] Testcase from qtbase-opensource-src_5.1.0+dfsg-4 and g++ 4.8.1 This issue still appears with GCC 4.8 In GCC 4.6 in Debian/m68k I eventually applied a patch that simply retries the build with -O1 then -O0 to mask this issue, but the underlying issue is still unfixed. This occurs in 4.8 now too, so I guess (from a distro PoV) I need to port said patch, until someone finds out what precisely is going on here. Please try compiling with -O2 -fno-auto-inc-dec before dropping to -O1 or -O0.
[Bug target/58158] internal compiler error: in extract_insn, at recog.c:2150 while compiling ImageMagick on mipsel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58158 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se, ||pinskia at gcc dot gnu.org --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- Started with the Improve COND_EXPR expansion patch in r187183. Still occurs with recent trunk and head of 4.8 branch. Author CC:d.
[Bug middle-end/58143] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- This wrong-code started with the PR54937 patch in r192710. Author CC:d.
[Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a non-aligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Alexander Barkov from comment #4) The vectorizer turns those into larger and still mis-aligned `movdqa' stores, which x86 does not allow, hence the SEGV. Can you please clarify: is it a bug in the recent gcc versions? Note, we've used such performance improvement tricks for years. It worked perfectly fine until now. Has anything changed in how the gcc vectorizer works recently? I know next to nothing about the vectorizer, so I cannot comment on this. Unfortunately it's not possible to avoid mis-aligned stores due to the project architecture. Mis-aligned accesses are Ok, as long as they are expressed using the proper mechanisms (memcpy, attribute packed, or pragma packed). I've read somewhere that gcc vectorizer generates two code branches, for aligned memory and for non-aligned memory (but can't find the reference now). Can you please confirm this? I don't know, see above.
[Bug c/56824] pragma GCC diagnostic push/pop regression for GCC diagnostic ignored -Waggregate-return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56824 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||dehao at gcc dot gnu.org, ||mikpe at it dot uu.se --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se --- Started with Dehao Chen's Combine location with block using block_locations patch in r191494.
[Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a non-aligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039
--- Comment #3 from Mikael Pettersson mikpe at it dot uu.se ---
Your code performs mis-aligned uint16_t stores, which x86 allows. The
vectorizer turns those into larger and still mis-aligned `movdqa' stores, which
x86 does not allow, hence the SEGV.
Replace the non-portable mis-aligned stores with portable code like
#define int2store_little_endian(s,A) memcpy((s), (A), 2)
or gcc-specific code like
struct __attribute__((__packed__)) packed_uint16 {
uint16_t u16;
};
#define int2store_little_endian(s,A) ((struct packed_uint16*)(s))-u16 = (A)
and then the vectorizer generates large `movdqu' stores, which is pretty much
the best you can hope for unless you rewrite the code to avoid mis-aligned
stores.
[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- Please attach the pre-processed test.i (gcc -E or -save-temps).
[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se --- I can't reproduce the wrong-code with 4.6.4. 4.7.2, or 4.8.1. They all generate: test: 0: 24020002li v0,2 4: aca2sw v0,0(a1) 8: 24020004li v0,4 c: 14820002bne a0,v0,18 test+0x18 10: 24020008li v0,8 14: aca20040sw v0,64(a1) 18: 03e8jr ra 1c: nop which looks correct to me (not that I know MIPS very well). Please try with a self-compiled gcc built from unmodified sources, or report this to openwrt as your hacked gcc clearly indicated (see the bugurl in comment #1).
[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- I can reproduce the ICE with 4.9 and 4.8 crosses to mips64-linux, but not with 4.7 or 4.6.
[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||rdsandiford at googlemail dot com --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- Started with Uros' PR54457 patch in r191928. I'm not sure if that patch was wrong or if it exposed a problem in the mips backend. Cc:ing a MIPS maintainer (Richard S.)
[Bug c++/58059] gcc-4.7.2-r1 - g++: internal compiler error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58059 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- The non-preprocessed test case crashes g++ 4.7, 4.8, and 4.9 for me on x86_64-linux.
[Bug libgcc/58061] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- This is clearly a duplicate of PR57848. Then there is PR57897 which crashes with a different error message but still on #pragma target and mingw, I believe that one is at least closely related.
[Bug fortran/58064] Cannot compile gcc-4.8.1 by gcc-3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58064 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- init2.c:37: MPFR assertion failed: (64 - 0) == ((64 - 0)/8) * 8 sizeof(mp_limb_t) == ((64 - 0)/8) seems your mpfr library is broken
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- Running this program throws loads of alignment exceptions when it's compiled by gcc-4.9 or gcc-4.8, targeting armv5tel-linux-gnueabi -O2 -marm. Adding -mno-unaligned-access makes no difference. When compiled by gcc-4.7 it runs cleanly without any exceptions.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment #4 from Mikael Pettersson mikpe at it dot uu.se ---
Started with Bill Schmidt's PR46556 patch in r190037. (Author CC:d.)
Comparing the generated code between 190036 and 190037 clearly shows how the
misaligned accesses were wrongly replaced by aligned accesses:
--- pr58041.s-r190036 2013-08-01 13:30:59.264514025 +0200
+++ pr58041.s-r190037 2013-08-01 13:27:38.874840851 +0200
@@ -18,37 +18,11 @@
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
- stmfd sp!, {r4, r5, r6, r7, r8, r9, r10, fp}
add ip, r0, r1, asl #3
- ldrbr7, [ip, #2]@ zero_extendqisi2
- ldrbr6, [ip, #6]@ zero_extendqisi2
- ldrbr0, [ip, #1]@ zero_extendqisi2
- ldrbr1, [ip, #5]@ zero_extendqisi2
- ldrbr5, [ip, #3]@ zero_extendqisi2
- ldrbr4, [ip, #7]@ zero_extendqisi2
- orr r0, r0, r7, asl #8
- orr r1, r1, r6, asl #8
- ldrbr10, [ip, #4] @ zero_extendqisi2
- ldrbr6, [ip, #8]@ zero_extendqisi2
- mov fp, r2, lsr #8
- orr r0, r0, r5, asl #16
- mov r9, r2, lsr #16
- mov r8, r2, lsr #24
- mov r7, r3, lsr #8
- orr r1, r1, r4, asl #16
- mov r5, r3, lsr #16
- mov r4, r3, lsr #24
- strbfp, [ip, #2]
- strbr2, [ip, #1]
- strbr9, [ip, #3]
- strbr8, [ip, #4]
- strbr7, [ip, #6]
- strbr3, [ip, #5]
- strbr5, [ip, #7]
- strbr4, [ip, #8]
- orr r0, r0, r10, asl #24
- orr r1, r1, r6, asl #24
- ldmfd sp!, {r4, r5, r6, r7, r8, r9, r10, fp}
+ ldr r0, [ip, #1]
+ ldr r1, [ip, #5]
+ str r2, [ip, #1]
+ str r3, [ip, #5]
bx lr
.size foo, .-foo
.section.text.startup,ax,%progbits
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se --- I see the exact same failure pattern on sparc64-linux: 4.7 generates working code, 4.8 and 4.9 generate code that SIGBUS:es, failure starts with r190037, -m32 or -m64 makes no difference.
[Bug c/58048] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- The ICE reproduces on x86_64-linux with gcc-4.9-20130728 and gcc-4.8-20130725, both -m32 and -m64.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #18 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Bill Schmidt from comment #15) Bernd, Mikael, Martin: Could you please test this on your respective targets? This patch eliminates the misalignment faults for me on both ARMv5TE and SPARC.
[Bug rtl-optimization/57967] [4.7 regresssion] Incorrect code generated on ARM with -fexpensive-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57967 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se --- I can reproduce the wrong-code with gcc-4.7.3 on armv5tel-linux-gnueabi. The wrong-code disappeared on 4.7 branch with the recent PR57829 fix in r200773. On trunk the wrong-code disappeared with r186147, Mike Stump's remove wrong code in immed_double_const patch. Backporting that to 4.7.3 (pre-PR57829 fix) also fixes the wrong-code. However, r186147 (a) had some regressions on ARM and s390x (see PR57735), and (b) should be redundant for 4.7 given the PR57829 fix.
[Bug java/57929] gcc-4.8: FTBFS on m68k: ICE compiling libjava/interpret.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57929 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- Dup of PR49847. The patch attached there fixes this ICE.
[Bug c/57896] ICE in in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- I can reproduce the ICE with gcc-4.8.1 and gcc-4.8-20130711 on x86_64-linux, using options -O0 -m64. At higher optimization levels or with -m32 the ICE doesn't occur. gcc-4.9-20130714 doesn't ICE.
[Bug c/57896] ICE in in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- The ICE was fixed for 4.9/trunk by Marc Glisse's Property for vector lowering patch in r196890, originally described here: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00421.html Backporting r196890 to current 4.8 branch fixes the ICE there too, but that may or may not be the appropriate fix. Author CC:d.
[Bug middle-end/57886] Invalid folding of (float)-x to -(float)x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57886 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- Dup of PR55771?
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862
--- Comment #5 from Mikael Pettersson mikpe at it dot uu.se ---
Your test case contains this:
===snip===
struct iphdr
{
...
};
...
int main()
{
char thePacket[1518];
memset(thePacket, 0, 1518);
thePacket[30] = 1;
thePacket[31] = 2;
thePacket[32] = 3;
thePacket[33] = 4;
struct ether_header* theEthHeader = (struct ether_header*)(thePacket);
struct iphdr* theIpHeader = (struct iphdr*)((const unsigned
char*)(theEthHeader) + 14);
struct in_addr myInAddr;
myInAddr.s_addr = theIpHeader-daddr;
===snip===
The alignment of thePacket is arbitrary, so the alignment of theIpHeader is
unknown, and struct iphdr is not declared with attribute packed. The final
load may therefore be misaligned.
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Gaetano Mendola from comment #6) struct in_addr myInAddr; myInAddr.s_addr = theIpHeader-daddr; as not portable, where myInAddr.s_addr and theIpHeader-daddr are of the same type. I'm not a c-standard lawyer but I'm hard believing that in the standard that assignment is marked as: undefined behaviour unless you use memcpy. The assignment is immaterial, it's the load (theIpHeader-daddr) that's problematic because the base pointer (theIpHeader) is not correctly aligned for its declared type (struct iphdr).
[Bug tree-optimization/57861] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57861 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- It's a recent regression, caused by the LRA change in r200723. Author CCd.
[Bug tree-optimization/57860] wrong code for bitwise ops with long long literal on x86_64-linux (32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57860 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- Caused by the LRA changes in r200723. Author CCd.
[Bug middle-end/57859] -ftrapv does not trap on signed overflows for struct fields (32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57859 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- With -m64: both test cases work with gcc-3.2.3, and fail with every release from 3.3.6 up to current trunk. With -m32: the first test case doesn't trap with any release since 3.2.3, the second test case traps with current trunk and 4.8, but not with any release from 3.2.3 to 4.7.3.
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- This has all the indications of a mis-aligned memory access. Since you're on Linux, please make sure that the 'User faults' field in /proc/cpu/alignment shows a value of 2 (fixup) or 3 (fixup+warn). You can 'echo 3 /proc/cpu/alignment' in your startup scripts to ensure this setting, or you can hack it into the kernel source's arch/arm/mm/alignment.c (which is what I do).
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Gaetano Mendola from comment #2) who is faulty? Kernel configuration on this platform, the architecture, the compiler or even me ? All of the above. The architecture for getting mis-alignment very very wrong, the kernel for not enforcing correct handling of alignment faults, the compiler for sometimes generating mis-aligned accesses where the original code had none (there are PRs about that affecting at least ARM and I believe also SPARC), and your code for (apparently) having a load from a mis-aligned address where portable code should use memcpy() (the fact that memcpy() didn't help you is a consequence of one of those PRs). My ARMv5TE box' /proc/cpu/alignment currently reads User: 100669 all of which come from gcc's own test suite. That's just so wrong.
[Bug tree-optimization/57864] [4.7 Regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57864 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- Created attachment 30486 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30486action=edit slightly reduced test case in plain C Doesn't depend on C++, this plain C version also ICEs 4.7.3.
[Bug tree-optimization/57864] [4.7 Regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57864 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- The ICE on 4.7 branch started with the PR55107 backport in r195755.
[Bug target/57847] Compile ARM linux kernel with configuration of SLUB allocator, kernel failed to boot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57847 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- There was a known problem in the Linux kernel on ARM with gcc-4.7+ due to one of the mem* procedures (likely memset or memcpy) being written in such a way that its return value didn't follow normal specs, but gcc-4.7+ optimizes based on those specs, so the kernel broke. This is supposed to have been fixed sometime in the Linux 3.x series.
[Bug target/57848] internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- Reproducible with a 4.9 cross to x86_64-w64-mingw32. Started with r200349, but that may simply have triggered a latent problem.
[Bug target/57848] internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- Created attachment 30475 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30475action=edit reduced test case
[Bug target/57848] internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se --- The reduced test case also ICEs 4.8-20130704, 4.7-20130706, and 4.6-20130405 (haven't checked older versions yet).
[Bug tree-optimization/57829] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57829
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se ---
If I change it to return the computed value of t, I get wrong code for every
single gcc version from 4.9 down to 3.2.3 on both x86_64 and sparc64. For
int main (void)
{
volatile int k = 1;
int t = 2 | ( ( k - 1) 31 );
return t;
}
gcc-4.9 generates
main:
movl$1, -4(%rsp)
movl-4(%rsp), %eax
leal-1(%rax), %eax
sarl$31, %eax
ret
which completely loses all references to the 2 | part.
[Bug tree-optimization/56982] [4.8 Regression] Bad optimization with setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982 --- Comment #14 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Bernd Edlinger from comment #13) Created attachment 30431 [details] another example of wrong compilation This is another example where the optimization can go wrong. The attached program produces expected results if compiled with -O0: x=0, a=1 x=1, a=1 a=1 But if compiled with -O3 and if the value a is placed in a register the result is like this: x=0, a=1 x=1, a=0 a=0 That is because longjmp has more semantic than just a branch: It branches to the setjmp, and restores all callee saved registers to the previos value. Your example is invalid C. Referring to WG14 n1494.pdf (there may be more recent C1x documents, but it's the one I had available right now): - you violate 7.13.1.1 which specifies where setjmp() may be called, an assignment statement is not one of the permitted contexts - more importantly, your auto variable a is not volatile-qualified, which means that its value is indeterminate after the longjmp (7.13.2.1). Please fix these issues and check again if it yields wrong results.
[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to ktkachov from comment #6) After looking at it more closely: Mikael, are you sure the revisions are right? It seems to me that r199813 is just the backport of r199188. Can you please double-check the revision that fixes this current ICE? Oops. The ICE was fixed by r198462, r199188 is the followup. Sorry about that.
[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se --- The ICE on the reduced test case started with r186147 and stopped with r199188. They both touch the same code so I believe r199188 is a proper fix and not just coincidental. Backporting r199188 to current 4.8 branch fixes the ICE there too, but I haven't done a full bootstrap and regression test run on anything except x86_64 yet. r199188 did cause a regression (ICE on s390x), but the fix for that has already been backported to 4.8 branch (at r199813).
[Bug c++/57504] invalid this pointer passed in call to virtual function that returns a struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57504 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- I can reproduce the wrong-code with gcc-4.7.2 targeting x86_64-w64-mingw32 -m32, but not with a similarly configured gcc-4.7.3.
[Bug target/57564] regmove switched operands?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57564 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- This missed-optimization for x86 -m32 started with the LRA merge in r192719. It still occurs on current trunk and 4.8 branch.
[Bug tree-optimization/57719] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Zhendong Su from comment #2) test #2: wrong code from both gcc trunk and 4.8 at -O3 in 32-bit mode only: The wrong-code for test #2 also started with r196174.
[Bug tree-optimization/57719] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Zhendong Su from comment #2) test #3: wrong code from gcc trunk (but not gcc 4.8) at -O3 in 32-bit mode only: The wrong-code for test #3 started with r198121.
[Bug tree-optimization/57719] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Zhendong Su from comment #2) test #4: wrong code from gcc trunk (but not gcc 4.8) at -O3 in both 32-bit and 64-bit modes: The wrong-code for test #4 also started with r198121.
[Bug tree-optimization/57723] Missed optimization: recursion around empty function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723 --- Comment #9 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Michael Matz from comment #8) (the argument being that an infinite loop is in itself a side-effect observable from outside). Exactly. A function containing an infinite loop could be stopped from a different thread. We have production code which does that, except the stopping (and redirection to another context) is done from a separate monitor process via ptrace(). GCC optimizing away infinite loops is just plain wrong, at least for ordinary systems programming languages.
[Bug tree-optimization/57685] GCC stuck in an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- Also affects gcc-4.8-20130620, but not gcc-4.7-20130622, on x86_64-linux. A typical stack trace looks like: 0x008709d5 in register_new_assert_for (expr=0x7f24dc840c60, comp_code=EQ_EXPR, val=0x7f24dc855320, bb=optimized out, e=0x7f24dc975310, si=..., name=optimized out) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:4486 4486 if (loc-comp_code == comp_code Missing separate debuginfos, use: debuginfo-install glibc-2.15-59.fc17.x86_64 (gdb) bt #0 0x008709d5 in register_new_assert_for (expr=0x7f24dc840c60, comp_code=EQ_EXPR, val=0x7f24dc855320, bb=optimized out, e=0x7f24dc975310, si=..., name=optimized out) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:4486 #1 0x0087633b in register_edge_assert_for_1 (op=0x7f24dc840c60, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5217 #2 0x008764aa in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #3 0x008764aa in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #4 0x0087650b in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #5 0x008764aa in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #6 0x008764aa in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #7 0x0087650b in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #8 0x0087650b in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #9 0x0087650b in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #10 0x008764aa in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #11 0x0087650b in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #12 0x008764aa in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #13 0x0087650b in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #14 0x008764aa in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #15 0x008764aa in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #16 0x008764aa in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #17 0x008764aa in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #18 0x0087650b in register_edge_assert_for_1 (op=optimized out, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #19 0x00876886 in register_edge_assert_for (name=0x7f24dc840d38, e=e@entry=0x7f24dc975310, si=..., cond_code=optimized out, cond_op0=optimized out, cond_op1=0x7f24dc855320) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5347 #20 0x008772cb in find_conditional_asserts (last=0x7f24dc960aa0, bb=0x7f24dc9551a0) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5393 #21 find_assert_locations_1 (bb=bb@entry=0x7f24dc9551a0, live=0x26d6640) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5607 #22 0x00882c19 in find_assert_locations () at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5747 #23 insert_range_assertions () at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5935 #24 execute_vrp
[Bug c++/57688] -O3 -march=native generates illegal opcode on AMD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- Run it in gdb, wait for the fault, and disassemble the code around the faulting PC. That valgrind report doesn't really say anything useful.
[Bug tree-optimization/57685] GCC stuck in an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- Started with the PR55079 fix in r193098. The test case uses the values of uninitialized auto variables, perhaps that's confusing the compiler.
[Bug target/57688] -O3 -march=native generates illegal opcode on AMD Phenom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #9 from Mikael Pettersson mikpe at it dot uu.se --- Your toolchain generated an AMD XOP BEXTR insn, but your processor doesn't have the XOP ISA extensions, so it #UDs.
[Bug c/52773] internal error: in replace_pseudos_in, at reload1.c:577
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se --- Bernd Schmidt has posted a patch for review: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01147.html
[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to zhenqiang.chen from comment #3) Created attachment 30330 [details] pr57637.patch This patch breaks Ada bootstrap on x86_64 for me: /tmp/objdir/./prev-gcc/xgcc -B/tmp/objdir/./prev-gcc/ -B/tmp/install49/x86_64-unknown-linux-gnu/bin/ -B/tmp/install49/x86_64-unknown-linux-gnu/bin/ -B/tmp/install49/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/install49/x86_64-unknown-linux-gnu/include -isystem /tmp/install49/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -gtoggle -gnatpg -W -Wall -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I/tmp/gcc-4.9-20130616/gcc/ada -I/tmp/gcc-4.9-20130616/gcc/ada/gcc-interface /tmp/gcc-4.9-20130616/gcc/ada/a-except.adb -o ada/a-except.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[3]: *** [ada/a-except.o] Error 1 make[3]: Leaving directory `/tmp/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/tmp/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/tmp/objdir' make: *** [bootstrap] Error 2
[Bug c/52773] internal error: in replace_pseudos_in, at reload1.c:577
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se --- Created attachment 30319 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30319action=edit reduced test case Still ICEs 4.9-20130616, 4.8-20130613, and 4.7-20130615. Needs -O1 (or higher) -funroll-loops -m68000 (or -m68010). With -m68020 or higher it doesn't ICE. Suspect a target bug, so adding Andreas to cc: list.
[Bug middle-end/57625] internal compiler error: seg fault when building gcc 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57625 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- I can't reproduce with FSF gcc 4.8.1 and 4.7.2 on Fedora 17 x86_64. Your archlinux system compiler is presumably somewhat modified; can you try again with an FSF 4.8.1? Also please make sure the 4.7.2 you're building is unmodified.
[Bug target/57583] large switches with jump tables are horribly broken on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- It's not too difficult to make the m68k backend use 32-bit offsets in its jump tables (adjust CASE_VECTOR_MODE, ASM_OUTPUT_ADDR_DIFF_ELT, ASM_RETURN_CASE_JUMP, drop the sign-extend from the tablejump expander, likewise in the unnamed insn that matches the output from the tablejump expander). I have a crude patch to do that, and make it compile-time selectable via an option. However, it seems to me that the compiler should be able to figure out for itself if a given jump table might need 32-bit offsets. In the worst case every element will overflow a (signed) 16-bit offset (0..32K-1 positive range) and need a GAS-inserted trampoline, for a total of 2 + 6 == 8 bytes per element. So tables with no more than 4K elements should work with 16-bit offsets. Tables larger than that may have their trampolines more than 32K away from the table PC base, which cannot work with 16-bit offsets, so for those the compiler should use 32-bit offsets. Seems to require implementing casesi for m68k though.
[Bug target/57583] New: large switches with jump tables are horribly broken on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 Bug ID: 57583 Summary: large switches with jump tables are horribly broken on m68k Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mikpe at it dot uu.se Created attachment 30288 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30288action=edit test case and generator program Switch jump tables on m68k-linux use 16-bit PC-relative offsets. No verification is made that the offsets actually fit in 16 bits, instead they are silently truncated. As a result, a large switch may branch to a wrong address; in my case it branches into the jump table itself causing a SIGILL. There are two bugs here: 1. GCC seems to hard-code the use of 16-bit offsets in its jump tables on m68k-linux. It should have an option to use 32-bit offsets instead. 2. GAS (not part of GCC I know) truncates .word operands to 16 bits without warning or error when significant bits are lost. I'll file that separately at the sourceware/binutils bugzilla. The test case contains a for (;;) loop with a switch () with 64K cases 0 .. 64K-1, each case containing a function call and a break. That switch becomes the following assembly code on m68k-linux with gcc-4.8.1: .L259: move.l (%a2),-(%sp) move.l %a2,-(%sp) jsr fetch addq.l #8,%sp and.l #65535,%d0 move.w .L262(%pc,%d0.l*2),%d0 jmp %pc@(2,%d0:w) .balignw 2,0x284c .L262: .word .L260-.L262 (64K - 1 more of these with varying labels in the first operand) When run on the target the code SIGILLs: 0x8402 in fetch () 1: x/i $pc = 0x8402 fetch+14: rts (gdb) 0x80001c0c in loop () 1: x/i $pc = 0x80001c0c loop+20:addql #8,%sp (gdb) 0x80001c0e in loop () 1: x/i $pc = 0x80001c0e loop+22:andil #65535,%d0 (gdb) 0x80001c14 in loop () 1: x/i $pc = 0x80001c14 loop+28:movew %pc@(0x80001c1c loop+36,%d0:l:2),%d0 (gdb) 0x80001c18 in loop () 1: x/i $pc = 0x80001c18 loop+32:jmp %pc@(0x80001c1c loop+36,%d0:w) (gdb) print $d0 $3 = 4 *** THIS 4 SHOWS THAT THE JUMP TABLE ENTRY HAS BEEN TRUNCATED (gdb) stepi 0x80001c20 in loop () 1: x/i $pc = 0x80001c20 loop+40:.short 0xfff2 (gdb) stepi Program received signal SIGILL, Illegal instruction. I'm attaching the test case (bug.c) and the program used to generate it (genbug.c). Classifying as a target bug since the code works on x86_64 and powerpc64.
[Bug target/57583] large switches with jump tables are horribly broken on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- http://sourceware.org/bugzilla/show_bug.cgi?id=15602 is the corresponding binutils/gas bug.
[Bug rtl-optimization/57479] [ARM][NEON] internal compiler error: Segmentation fault in add_dependence_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57479 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se --- I can reproduce the SEGV now, it was masked by my standard build's --with-tune=cortex-a9 option. The SEGV doesn't reproduce any more after r188742 + r188743, which changed the way the ARM backend expands epilogues. I don't immediately see the connection between that change and the garbage reg_last-sets value.
[Bug rtl-optimization/57459] [4.8/4.9 Regression] LRA inheritance bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se --- r192718 was OK, started with r192719, the LRA merge and activation on x86.
[Bug target/12081] Gcc can't be compiled with -mregparm=3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12081 --- Comment #22 from Mikael Pettersson mikpe at it dot uu.se --- FWIW, the updated patch for gcc 4.9 bootstraps and regtests cleanly on several hosts (x86_64, sparc64, powerpc64, armv5tel, m68k).
[Bug middle-end/55030] [4.8 Regression]: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os (et al)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55030 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #16 from Mikael Pettersson mikpe at it dot uu.se --- FWIW, I've bootstrapped and regtested gcc 4.9 with r192676 reapplied and the dse.c and cselib.c hunks of r193802 reverted on several hosts (x86_64, sparc64, powerpc64, armv5tel, m68k) without regressions.
[Bug rtl-optimization/57479] [ARM][NEON] internal compiler error: Segmentation fault in add_dependence_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57479 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- I can't reproduce the ICE with gcc-4.7.3 hosted on x86_64-linux configured as a cross to either armv7l-unknown-linux-gnueabi or armv7l-unknown-eabi. How was your gcc configured?
[Bug target/57477] New: gcc generates suboptimal code for a simple and-shift-zeroextend combination on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57477
Bug ID: 57477
Summary: gcc generates suboptimal code for a simple
and-shift-zeroextend combination on x86_64
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpe at it dot uu.se
Consider the following set of trivial functions:
cat q.c
unsigned int g(unsigned int x) { return x 0x1f; }
unsigned long f(unsigned int x) { return x 4; }
unsigned long h(unsigned int x) { return (x 0x1f) 4; }
h(x) == f(g(x)).
The code generated for f and g is good (not much choice there), but the code
for h contains some (suboptimal) surprises:
gcc -O3 -c q.c ; objdump -d q.o
q.o: file format elf64-x86-64
Disassembly of section .text:
g:
0: 89 f8 mov%edi,%eax
2: 83 e0 1fand$0x1f,%eax
5: c3 retq
6: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
d: 00 00 00
0010 f:
10: c1 e7 04shl$0x4,%edi
13: 89 f8 mov%edi,%eax
15: c3 retq
16: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
1d: 00 00 00
0020 h:
20: 48 89 f8mov%rdi,%rax
23: 48 c1 e0 04 shl$0x4,%rax
27: 25 f0 01 00 00 and$0x1f0,%eax
2c: c3 retq
1. In h gcc exchanged the order of the '' and the '', forcing it to use a
larger 4-byte immediate where g could use a 1-byte immediate, resulting in a
2-byte larger instruction encoding.
2. In h the '' is done in 64-bit precision, even though the input clearly is
32-bit ('unsigned int'), and the result clearly also is 32-bit (notice the
absence of a REX.W on the 'and'), resulting in 1-byte larger instruction
encoding.
3. In h the move from rdi to rax is unavoidable (due to the ABI), but it too is
redundantly done in 64-bit precision where 32-bit precision would have
sufficed, resulting in a 1-byte larger instruction encoding.
In short, h compiles to 13 bytes but could have compiled to 9 bytes.
This is with gcc 4.9, but 4.8 and 4.7 generate identical code.
[Bug target/12081] Gcc can't be compiled with -mregparm=3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12081 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #20 from Mikael Pettersson mikpe at it dot uu.se --- Created attachment 30188 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30188action=edit fix up conversion in tilepro_expand_builtin, delete unused 11-arity stuff Looking through the patch I noticed that the conversion in tilepro_expand_builtin was broken (icode was lost). Grepping around I also noticed that nothing used GEN_FCN11 (or is that used by the out-of-tree OpenRISC port?) This add-on fixes those two issues.
[Bug target/12081] Gcc can't be compiled with -mregparm=3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12081 --- Comment #21 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Mikael Pettersson from comment #20) Grepping around I also noticed that nothing used GEN_FCN11 (or is that used by the out-of-tree OpenRISC port?) This add-on fixes those two issues. i386/sync.md appears to generate code that needs the 11-arity version; consider that part of the fixup patch revoked.
[Bug bootstrap/57340] New: [4.9 regression] stage2 miscompiles build/genconditions on armv5tel-linux-gnueabi breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57340 Bug ID: 57340 Summary: [4.9 regression] stage2 miscompiles build/genconditions on armv5tel-linux-gnueabi breaking bootstrap Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpe at it dot uu.se Attempting to bootstrap gcc-4.9-20130519 on armv5tel-linux-gnueabi fails with: /mnt/scratch/objdir49/./prev-gcc/xg++ -B/mnt/scratch/objdir49/./prev-gcc/ -B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/bin/ -nostdinc++ -B/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs -B/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi -I/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/include -I/mnt/scratch/gcc-4.9-20130519/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs -L/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/mnt/scratch/gcc-4.9-20130519/gcc -I/mnt/scratch/gcc-4.9-20130519/gcc/build -I/mnt/scratch/gcc-4.9-20130519/gcc/../include -I/mnt/scratch/gcc-4.9-20130519/gcc/../libcpp/include -I/mnt/scratch/gcc-4.9-20130519/gcc/../libdecnumber -I/mnt/scratch/gcc-4.9-20130519/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/scratch/gcc-4.9-20130519/gcc/../libbacktrace\ -o build/genconditions.o /mnt/scratch/gcc-4.9-20130519/gcc/genconditions.c /mnt/scratch/objdir49/./prev-gcc/xg++ -B/mnt/scratch/objdir49/./prev-gcc/ -B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/bin/ -nostdinc++ -B/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs -B/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi -I/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/include -I/mnt/scratch/gcc-4.9-20130519/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs -L/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o build/genconditions \ build/genconditions.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/read-md.o build/errors.o .././libiberty/libiberty.a build/genconditions /mnt/scratch/gcc-4.9-20130519/gcc/config/arm/arm.md tmp-condmd.c /bin/sh: line 1: 4055 Segmentation fault build/genconditions /mnt/scratch/gcc-4.9-20130519/gcc/config/arm/arm.md tmp-condmd.c make[3]: *** [s-conditions] Error 139 make[3]: Leaving directory `/mnt/scratch/objdir49/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir49' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir49' make: *** [bootstrap] Error 2 Running it in gdb it seems to have followed a NULL function pointer or code label: cd gcc gdb build/genconditions ... (gdb) run /mnt/scratch/gcc-4.9-20130519/gcc/config/arm/arm.md tmp-condmd.c Starting program: /mnt/scratch/objdir49/gcc/build/genconditions /mnt/scratch/gcc-4.9-20130519/gcc/config/arm/arm.md tmp-condmd.c Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x000101b8 in init_rtx_reader_args_cb(int, char**, bool (*)(char const*)) () #2 0x8ec4 in main () This is a regression from gcc-4.9-20130512 which bootstrapped fine on the same system. And build/genconditions was built earlier during stage1 by the system compiler, and that binary didn't SEGV.
[Bug rtl-optimization/57321] static function call miscompiled at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57321 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- I can reproduce the wrong-code. It was fixed on 4.8 branch by r198737 aka PR56988.
[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56548 --- Comment #9 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Ralf Baechle from comment #8) FWIW, I'm also hitting the same compiler bug with vanilla GCC 4.7.2 and 4.8.0 compiling a heavily patched 3.4 kernel with LTO for a mips64-linux target. Please upload a pre-processed test case. Since you're getting this with gcc-4.7.2 it's presumably not caused by r193539 as comment #1 indicated. Have you tried gcc trunk, just to see if it's been fixed there?
[Bug bootstrap/57266] [4.9 regression] comparison between signed and unsigned integer expressions in fold_binary_loc breaks m68k bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57266 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- My m68k bootstrap has now recompiled fold-const.c + your patch three times without warnings or errors. Thanks for the quick fix.
[Bug bootstrap/57266] New: [4.9 regression] comparison between signed and unsigned integer expressions in fold_binary_loc breaks m68k bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57266 Bug ID: 57266 Summary: [4.9 regression] comparison between signed and unsigned integer expressions in fold_binary_loc breaks m68k bootstrap Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpe at it dot uu.se Attempting to bootstrap gcc-4.9-20130512 on m68k-linux fails with: /mnt/scratch/objdir49/./prev-gcc/xg++ -B/mnt/scratch/objdir49/./prev-gcc/ -B/mnt/scratch/install49/m68k-unknown-linux-gnu/bin/ -nostdinc++ -B/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs -B/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/include/m68k-unknown-linux-gnu -I/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/include -I/mnt/scratch/gcc-4.9-20130512/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs -L/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-4.9-20130512/gcc -I/mnt/scratch/gcc-4.9-20130512/gcc/. -I/mnt/scratch/gcc-4.9-20130512/gcc/../include -I/mnt/scratch/gcc-4.9-20130512/gcc/../libcpp/include -I/mnt/scratch/gcc-4.9-20130512/gcc/../libdecnumber -I/mnt/scratch/gcc-4.9-20130512/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/scratch/gcc-4.9-20130512/gcc/../libbacktrace /mnt/scratch/gcc-4.9-20130512/gcc/fold-const.c -o fold-const.o /mnt/scratch/gcc-4.9-20130512/gcc/fold-const.c: In function 'tree_node* fold_binary_loc(location_t, tree_code, tree, tree, tree)': /mnt/scratch/gcc-4.9-20130512/gcc/fold-const.c:12430:15: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] if (low = prec) ^ cc1plus: all warnings being treated as errors make[3]: *** [fold-const.o] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir49/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir49' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir49' make: *** [bootstrap] Error 2 At this point in the source, 'low' is of type HOST_WIDE_INT which is 'long' (32 bits on m68k) while 'prec' is of type 'unsigned int' (also 32 bits). Caused by r198772. Before that the code compared 'low' with TYPE_PRECISION (), which is a smaller-than-int unsigned bitfield, so presumably promoted to int. Casting prec to HOST_WIDE_INT here seems to work.
[Bug c/57180] Structures with a flexible arrray member have wrong size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180
--- Comment #3 from Mikael Pettersson mikpe at it dot uu.se ---
According to
http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Zero-Length.html#Zero-Length,
arrays of structures with trailing flex arrays are invalid and rejected. The
page also gives an example of that, but changing it to use a char array with
either a string literal initializer or a { } one shows that only the { } form
is rejected:
cat pr57180-2.c
struct foo { int x; char y[]; };
struct foo a[1] = { { 1, ab } };
struct foo b[1] = { { 1, { 'a', 'b', '\0' } } };
gcc -Wall -S pr57180-2.c
pr57180-2.c:3:8: error: initialization of flexible array member in a nested
context
struct foo b[1] = { { 1, { 'a', 'b', '\0' } } };
^
pr57180-2.c:3:8: error: (near initialization for 'b[0].y')
Accepting the a[] initializer while rejecting the b[] one seems broken.
[Bug c/57180] Structures with a flexible arrray member have wrong size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- This test case also fails on x86_64-linux with every gcc release from 3.2.3 up to today's 4.9 (r198748). Looking at the assembly code for the x[] initializer it's easy to see why: .type x, @object .size x, 64 x: .zero 8 .string abc123 .zero 24 .zero 8 .string xyz .zero 24 The .zero 24 is there to pad the initializer up to the type size, but it isn't adjusted for the flex array initializer, so too much data is emitted for x[0], causing x[1]'s initializer to start at the wrong address. The error check that x[1].s.c[0] != 'x' is compiled as: cmpb$120, x+40(%rip) and it triggers because the 'x' is actually at x+8+7+24+8 i.e. x+47. I can't say I'm a fan of flex arrays in global variables, but they clearly are severely broken when those variables are arrays.
