[Bug c/61901] New: cc1 sanitizer runtime error in i386.c classify_argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61901 Bug ID: 61901 Summary: cc1 sanitizer runtime error in i386.c classify_argument Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com After building gcc with -fsanitize=undefined, analyzing the gcc testsuite with the sanitized cc1 I got runtime error messages ../../gcc-4.9.1/gcc/config/i386/i386.c:6556:60: runtime error: load of value 32767, which is not a valid value for type 'x86_64_reg_class' The instruction at i386.c:6556 is classes[i] = merge_classes (subclasses[i], classes[i]); This is in classify_argument. The reproducers are pr20020-1.c/pr20020-2.c/pr42025-2.c
[Bug target/61901] cc1 sanitizer runtime error in i386.c classify_argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61901 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of bug 61656. *** This bug has been marked as a duplicate of bug 61656 ***
[Bug target/61656] Undefined behavior in classify_argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61656 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 61901 has been marked as a duplicate of this bug. ***
[Bug target/61901] cc1 sanitizer runtime error in i386.c classify_argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61901 --- Comment #2 from Vittorio Zecca zeccav at gmail dot com --- I am sorry about opening a duplicate.
[Bug c/61902] New: signed integer overflow in real.c in real_from_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61902 Bug ID: 61902 Summary: signed integer overflow in real.c in real_from_integer Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Running sanitized cc1 on testsuite files fp-int-convert-float80-timode.c and fp-int-convert-timode.c and fp-int-convert-float128-timode.c I get the following ../../gcc-4.9.1/gcc/real.c:2136:15: runtime error: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long int' The instruction at real.c:2136 is high += 1; It seems high==LONG_MIN on x86-64.
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Jul 25 07:44:57 2014 New Revision: 213045 URL: https://gcc.gnu.org/viewcvs?rev=213045root=gccview=rev Log: 2014-07-25 Richard Biener rguent...@suse.de PR middle-end/61762 PR middle-end/61894 * fold-const.c (native_encode_int): Add and handle offset parameter to do partial encodings of expr. (native_encode_fixed): Likewise. (native_encode_real): Likewise. (native_encode_complex): Likewise. (native_encode_vector): Likewise. (native_encode_string): Likewise. (native_encode_expr): Likewise. * fold-const.c (native_encode_expr): Add offset parameter defaulting to -1. * gimple-fold.c (fold_string_cst_ctor_reference): Remove. (fold_ctor_reference): Handle all reads from tcc_constant ctors. * gcc.dg/pr61762.c: New testcase. * gcc.dg/fold-cstring.c: Likewise. * gcc.dg/fold-cvect.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/fold-cstring.c trunk/gcc/testsuite/gcc.dg/fold-cvect.c trunk/gcc/testsuite/gcc.dg/pr61762.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/fold-const.h trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/61894] Fail to fold read from constant vector initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61894 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Jul 25 07:44:57 2014 New Revision: 213045 URL: https://gcc.gnu.org/viewcvs?rev=213045root=gccview=rev Log: 2014-07-25 Richard Biener rguent...@suse.de PR middle-end/61762 PR middle-end/61894 * fold-const.c (native_encode_int): Add and handle offset parameter to do partial encodings of expr. (native_encode_fixed): Likewise. (native_encode_real): Likewise. (native_encode_complex): Likewise. (native_encode_vector): Likewise. (native_encode_string): Likewise. (native_encode_expr): Likewise. * fold-const.c (native_encode_expr): Add offset parameter defaulting to -1. * gimple-fold.c (fold_string_cst_ctor_reference): Remove. (fold_ctor_reference): Handle all reads from tcc_constant ctors. * gcc.dg/pr61762.c: New testcase. * gcc.dg/fold-cstring.c: Likewise. * gcc.dg/fold-cvect.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/fold-cstring.c trunk/gcc/testsuite/gcc.dg/fold-cvect.c trunk/gcc/testsuite/gcc.dg/pr61762.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/fold-const.h trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk.
[Bug middle-end/61894] Fail to fold read from constant vector initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61894 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk.
[Bug target/61656] Undefined behavior in classify_argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61656 --- Comment #11 from uros at gcc dot gnu.org --- Author: uros Date: Fri Jul 25 07:47:36 2014 New Revision: 213046 URL: https://gcc.gnu.org/viewcvs?rev=213046root=gccview=rev Log: Backport from mainline 2014-07-14 Jakub Jelinek ja...@redhat.com PR target/61656 * config/i386/i386.c (classify_argument): Don't merge classes above number of words. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c
[Bug target/61656] Undefined behavior in classify_argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61656 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.9.3 --- Comment #12 from Uroš Bizjak ubizjak at gmail dot com --- Also fixed for 4.9 branch.
[Bug target/61656] Undefined behavior in classify_argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61656 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|4.9.3 |4.9.2
[Bug middle-end/61902] signed integer overflow in real.c in real_from_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61902 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This code has changed a lot in 4.10/5.0. The pair is no longer there and instead we use wide_int and: /* We have to ensure we can negate the largest negative number. */ wide_int val = wide_int::from (val_in, maxbitlen, sgn); if (r-sign) val = -val; So closing as fixed in GCC 4.10/5.0.
[Bug c/61903] New: signed integer overflow in expmed.c store_fixed_bit_filed_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61903 Bug ID: 61903 Summary: signed integer overflow in expmed.c store_fixed_bit_filed_1 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Compiling testsuite code pr28045.c the sanitizer claims that a signed integer overflow occurs at expmed.c:1071 ../../gcc-4.9.1/gcc/expmed.c:1071:41: runtime error: signed integer overflow: -9223372036854775808 + -1 cannot be represented in type 'long int' The offending instruction is v = ((HOST_WIDE_INT) 1 bitsize) - 1; This is in store_fixed_bit_field_1 on x86-64.
[Bug c/61903] signed integer overflow in expmed.c store_fixed_bit_filed_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61903 --- Comment #1 from Vittorio Zecca zeccav at gmail dot com --- Same runtime error at line 1076 of expmed.c v == ((HOST_WIDE_INT) 1 bitsize) - 1) compiling pr28045.c
[Bug c/61904] New: Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 Bug ID: 61904 Summary: Incorrect stack red-zoning on x86-64 code generation Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: torva...@linux-foundation.org gcc-4.9.0 in Debian seems to miscompile the linux kernel for x86-64 in certain configurations, creating accesses to below the stack pointer even though the kernel uses -mno-red-zone. The kernel cannot use the x86-64 stack red-zoning, because the hardware only switches stacks on privilege transfers, so interrupts that happen in kernel mode will not honor the normal 128-byte stack red-zone. Attached is the pre-processed C code of the current kernel file kernel/sched/fair.c which apparently on gcc-4.9.0 will miscompile the function load_balance(), creating code like this: load_balance: .LFB2408: .loc 2 6487 0 .cfi_startproc .LVL1355: pushq %rbp# .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp #, .cfi_def_cfa_register 6 pushq %r15# pushq %r14# pushq %r13# pushq %r12# .cfi_offset 15, -24 .cfi_offset 14, -32 .cfi_offset 13, -40 .cfi_offset 12, -48 movq%rdx, %r12 # sd, sd pushq %rbx# .LBB2877: .loc 2 6493 0 movq$load_balance_mask, -136(%rbp) #, %sfp .LBE2877: .loc 2 6487 0 subq$184, %rsp #, .cfi_offset 3, -56 .loc 2 6489 0 Note the subq$184, %rsp *after* the compiler has already spilled to the stack (the spill is insane, btw, since it's spilling a constant value!) The second attachement is the reported mis-compiled result. I don't personally have the affected gcc version, but you can see the options passed into the compiler in the resulting fair.s file. The -Os in particular seems to be important, with the bug not happening with -O2.
[Bug middle-end/61903] signed integer overflow in expmed.c store_fixed_bit_filed_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61903 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-25 Component|c |middle-end Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- if (bitsize HOST_BITS_PER_WIDE_INT) v = ((HOST_WIDE_INT) 1 bitsize) - 1; Should be an easy fix to change HOST_WIDE_INT to unsigned HOST_WIDE_INT.
[Bug c/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 --- Comment #1 from Linus Torvalds torva...@linux-foundation.org --- Created attachment 33183 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33183action=edit Buggy result of compilation This was sent by the reporter of the kernel problem, Michel Dänzer mic...@daenzer.net, at my request. It's gzipped to fit the file size limit.
[Bug target/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |target Severity|critical|normal
[Bug c/61905] New: zero variable length array bound in cp-demangle.c cplus_demangle_print_callback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61905 Bug ID: 61905 Summary: zero variable length array bound in cp-demangle.c cplus_demangle_print_callback Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com The sanitizer claims that compiling the testsuite files pr21255-2-mb.c and pr21255-4.c and pr21255-3.c and pr21255-2-ml.c a zero variable length array bound occurs ../../gcc-4.9.1/libiberty/cp-demangle.c:4039:40: runtime error: variable length array bound evaluates to non-positive value 0 Same at line 4040 __extension__ struct d_saved_scope scopes[dpi.num_saved_scopes]; __extension__ struct d_print_template temps[dpi.num_copy_templates];
[Bug target/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-07-25 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- The testcase is missing. Please attach fair.i.
[Bug target/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 --- Comment #3 from Linus Torvalds torva...@linux-foundation.org --- Created attachment 33184 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33184action=edit gzipped pre-processed fair.i file Apparently attaching a file during the initial bug entry creation failed, probably because it failed the size check. So here's the fair.i file.
[Bug target/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 --- Comment #4 from Linus Torvalds torva...@linux-foundation.org --- As I already mentioned to Jakub Jelinek separately in the original email thread about the kernel problem: Note that I don't personally have a reproducer (my machine has gcc-4.8.3, and I don't see the same behavior), but I included the incorrect fair.s file that Michel sent me (which has all the command line options in it), and a pre-processed fair.i source file that I generated and that *should* match the configuration that was the source for that result. So there might be some version/configuration skew there between the two files, but I think they match. Holler if you cannot reproduce the problem based on that. so if the attached *.i and resulting buggy *.s files don't match up perfectly, that's the explanation.
[Bug bootstrap/61899] gcc/Makefile.in: compile failure occasionally while parallel make enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61899 --- Comment #2 from hongxu jia hongxu.jia at windriver dot com --- The previous fix is incorrect, it caused other build failure. Here is the new solution: The gcc-ar.o, gcc-nm.o, gcc-ranlib.o and errors.o included config.h which was a generated file. But no explicity rule to clarify the dependency. There was potential building failure while parallel make. For gcc-ar.o, gcc-nm.o and gcc-ranlib.o, they were compiled from one C source file gcc-ar.c, we add them to ALL_HOST_BACKEND_OBJS, so the '$(ALL_HOST_OBJS) : | $(generated_files)' rule could work for these objects. For errors.o, it is part of gengtype, and the gengtype generator program is special: Two versions are built. One is for the build machine, and one is for the host. We refered what gengtype-parse.o did (which also is part of gengtype). Signed-off-by: Hongxu Jia hongxu@windriver.com --- gcc/Makefile.in | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index a726109..cdaa406 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1491,13 +1491,16 @@ OBJS-libcommon-target = $(common_out_object_file) prefix.o params.o \ opts.o opts-common.o options.o vec.o hooks.o common/common-targhooks.o \ hash-table.o file-find.o +# Objects compiled from one C source file gcc-ar.c +OBJS-gcc-ar = gcc-ar.o gcc-nm.o gcc-ranlib.o + # This lists all host objects for the front ends. ALL_HOST_FRONTEND_OBJS = $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OBJS) $(OBJS-libcommon) \ $(OBJS-libcommon-target) @TREEBROWSER@ main.o c-family/cppspec.o \ $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS) \ - $(GCOV_TOOL_OBJS) lto-wrapper.o collect-utils.o + $(GCOV_TOOL_OBJS) lto-wrapper.o collect-utils.o $(OBJS-gcc-ar) # This lists all host object files, whether they are included in this # compilation or not. @@ -2447,6 +2450,8 @@ gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H) CFLAGS-gengtype-lex.o += -DGENERATOR_FILE build/gengtype-lex.o: $(BCONFIG_H) +errors.o : $(CONFIG_H) + gengtype-parse.o build/gengtype-parse.o : gengtype-parse.c gengtype.h \ $(SYSTEM_H) gengtype-parse.o: $(CONFIG_H)
[Bug c++/61892] RVO not occurs with constructor with universal reference arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61892 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to tower120 from comment #2) Well ok, but what about this? http://coliru.stacked-crooked.com/a/e3ce8882c68dbef2 Why it copy with wrong number of argument? It doesn't. C(1, 1, 1) calls the constructor template with three arguments, obviously. Initializing the return value calls the constructor template with one argument. (In reply to tower120 from comment #3) But wait, we talk about move constructor. But this is a template class. Template class can not have move constructor at all. That's not true. There is no bug here.
[Bug middle-end/61876] Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876 --- Comment #7 from ktkachov at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #6) On Tue, 22 Jul 2014, ktkachov at gcc dot gnu.org wrote: From what I understand lround can potentially set errno on a domain error whereas round is valid everywhere and the cast to long int could be undefined behaviour if the double is not valid, but undefined behaviour is not the same as setting errno... Under Annex F the cast isn't undefined behavior but raising the invalid exception and returning an unspecified value (which must be a valid value of type long, i.e. the program must behave as if each execution of the cast in the abstract machine has some particular value of type long it returns). In my copy at 6.3.1.4 on Real floating and integer conversions it says: If the value of the integral part cannot be represented by the integer type, the behavior is undefined. In any case, it seems to me the transformation of cast+round - lround is only valid when: - the result is within the range of the long int - the argument is not NaN or infinity. In convert.c this transformation is already guarded by the type precision so we got the first point covered, but I think we also have to guard it by -ffinite-math-only. Is that reasonable?
[Bug middle-end/61876] Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to ktkachov from comment #7) (In reply to jos...@codesourcery.com from comment #6) Under Annex F the cast isn't undefined behavior but raising the invalid exception and returning an unspecified value (which must be a valid value of type long, i.e. the program must behave as if each execution of the cast in the abstract machine has some particular value of type long it returns). In my copy at 6.3.1.4 on Real floating and integer conversions it says: If the value of the integral part cannot be represented by the integer type, the behavior is undefined. Making Annex F explicitly take precedence over the generic text is DR#442.
[Bug c/61906] New: failed to build gcc 4.9.1 on debian wheezy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61906 Bug ID: 61906 Summary: failed to build gcc 4.9.1 on debian wheezy Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dmitigr at gmail dot com the compiler: gcc (Debian 4.7.2-5) 4.7.2 the system type: Linux y470 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux the options given when GCC was configured/built: ../configure -v --enable-languages=c,c++ --prefix=/usr/local/gcc --enable-shared --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu the compiler output (error messages, warnings, etc.): In file included from ./config.h:8:0, from ../../gcc/tree-ssa-forwprop.c:20: ../../gcc/../include/ansidecl.h:150:55: internal compiler error: Segmentation fault # define ATTRIBUTE_UNUSED __attribute__ ((__unused__)) ^ ../../gcc/../include/ansidecl.h:159:32: note: in expansion of macro ‘ATTRIBUTE_UNUSED’ # define ARG_UNUSED(NAME) NAME ATTRIBUTE_UNUSED ^ ./insn-flags.h:4765:52: note: in expansion of macro ‘ARG_UNUSED’ gen_fma_fmadd_v8sf_maskz_1(rtx ARG_UNUSED (a), rtx ARG_UNUSED (b), rtx ARG_UNUSED (c), rtx ARG_UNUSED (d), rtx ARG_UNUSED (e), rtx ARG_UNUSED (f)) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [tree-ssa-forwprop.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcc.pod make[3]: Leaving directory `/unencrypted/build/gcc-4.9.1/build/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/unencrypted/build/gcc-4.9.1/build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/unencrypted/build/gcc-4.9.1/build' make: *** [all] Error 2
[Bug fortran/61907] New: load of invalid value for 'bool' in trans-array.c trans_array_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61907 Bug ID: 61907 Summary: load of invalid value for 'bool' in trans-array.c trans_array_constructor Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Compiling many testsuite files with a sanitized gfortran, as in typebound_assignment_6.f03, elemental_subroutine_2.f90, move_alloc_13.f90, where_operator_assign_2.f90, pr43808.f90, and more, I get the following ../../gcc-4.9.1/gcc/fortran/trans-array.c:2207:9: runtime error: load of value xxx, which is not a valid value for type 'bool' The offending instructions are 2206: typespec_chararray_ctor = (expr-ts.u.cl 2207: expr-ts.u.cl-length_from_typespec); in trans_array_constructor.
[Bug target/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- With both the FSF 4.9.0 and 4.9.1 releases and gcc -S t.i -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mtune=generic -mno-red-zone -mcmodel=kernel -maccumulate-outgoing-args -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -march=x86-64 -g -Os -fno-strict-aliasing -fno-common -fno-asynchronous-unwind-tables -fno-omit-frame-pointer (too many options only to guess from the .s file - can you please specify explicitely passed options?) load_balance: .LFB2409: .loc 2 6487 0 .LVL1260: pushq %rbp .LCFI442: movq%rsp, %rbp .LCFI443: pushq %r15 pushq %r14 pushq %r13 pushq %r12 .LCFI444: movq%rdx, %r12 pushq %rbx .LBB2812: .loc 2 6493 0 movq$load_balance_mask, -376(%rbp) .LBE2812: .loc 2 6487 0 subq$416, %rsp .LCFI445: .loc 2 6489 0 movq(%rdx), %rax .loc 2 6487 0 movl%edi, -392(%rbp) movl%ecx, -388(%rbp) movq%r8, -456(%rbp) .loc 2 6489 0 movq%rax, -424(%rbp) .LVL1261: .LBB2813: .loc 2 6493 0 movq-376(%rbp), %rax .LVL1262: #APP # 6493 kernel/sched/fair.c 1 add %gs:this_cpu_off, %rax # 0 2 #NO_APP which I guess is equally bad (even if not matching the output from Michel). It seems to be triggered by -g or -fvar-tracking and is fixed on the 4.9 branch - so it might be a duplicate of PR61801.
[Bug fortran/61908] New: load of invalid value for 'expr_t' in interface.c compare_actual_formal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61908 Bug ID: 61908 Summary: load of invalid value for 'expr_t' in interface.c compare_actual_formal Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Compiling the testsuite file unlimited_polymorphic_16 with sanitized gfortran I get the following ../../gcc-4.9.1/gcc/fortran/interface.c:2667:43: runtime error: load of value 1818451807, which is not a valid value for type 'expr_t' The offending line in interface.c:2667 is f-sym-ts.u.cl-length-expr_type == EXPR_CONSTANT in compare_actual_format.
[Bug target/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Reduced set of options to reproduce with 4.9.1 are -mno-red-zone -mcmodel=kernel -maccumulate-outgoing-args -mno-sse -g -Os -fno-omit-frame-pointer if you use -fno-var-tracking the bug goes away, similar if you update to the 4.9 branch head. If you use -fno-schedule-insns2 you see a similar pattern to the mentioned PR: subq$424, %rsp .LCFI427: movl%edi, -400(%rbp) movq%rdx, %rbx movl%ecx, -396(%rbp) movq%r8, -464(%rbp) .LVL1306: .loc 2 6489 0 movq(%rdx), %rax movq%rax, -440(%rbp) .LVL1307: .LBB2616: .loc 2 6493 0 movq$load_balance_mask, -384(%rbp) movq-384(%rbp), %rax .LVL1308: #APP # 6493 kernel/sched/fair.c 1 add %gs:this_cpu_off, %rax so that spill is right before the asm and we immediately re-load it into a register required by an asm constraint (stupid register allocator). *** This bug has been marked as a duplicate of bug 61801 ***
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||torvalds@linux-foundation.o ||rg --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 61904 has been marked as a duplicate of this bug. ***
[Bug c/61779] gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Vittorio Zecca from comment #10) I just installed gcc-4.9.1 and it still has this bug. It does not even compile itself (divtf3.c) with -Og. As said it will be fixed in 4.9.2. I've double-checked that -Og bootstrap works on the 4.9 branch head - how did you configure/make?
[Bug target/59837] [ARM] ICE when building linux-linaro-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59837 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-07-25 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- There's been some work on shrink wrapping since January. Zhenqiang, is this bug still valid?
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #60 from Richard Biener rguenth at gcc dot gnu.org --- Ok, I suppose lduh[%g3], %g4 ! MEM[base: ptr_110, offset: 0B], min_line is not an instruction that works with unaligned %g3. ;; min_line_106 = (int) _215; (insn 921 920 922 (set (reg:HI 482) (mem:HI (reg/v/f:SI 185 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2 A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1 (nil)) a (mem:HI ...) with A8. I wonder if we should ICE somewhere if such kind of MEM is in the RTL instruction stream on a STRICT_ALIGNMENT platform? The TARGET_MEM_REF is created via #0 create_mem_ref_raw (type=type@entry=0x75401000, alias_ptr_type=alias_ptr_type@entry=pointer_type 0x761e3c78, addr=addr@entry=0x7fffd560, verify=verify@entry=true) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-address.c:401 #1 0x00c3b464 in create_mem_ref (gsi=gsi@entry=0x7fffd600, type=integer_type 0x75401000 short unsigned int, addr=addr@entry=0x7fffd640, alias_ptr_type=pointer_type 0x761e3c78, iv_cand=iv_cand@entry=ssa_name 0x766cc948, base_hint=base_hint@entry=ssa_name 0x766cc948, speed=speed@entry=true) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-address.c:721 #2 0x00c96f9a in rewrite_use_address (use=use@entry=0x18b8a10, cand=cand@entry=0x1a26f50, data=optimized out, data=optimized out) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6471 #3 0x00c97513 in rewrite_use (cand=0x1a26f50, use=0x18b8a10, data=0x7fffd9c0) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6539 #4 rewrite_uses (data=data@entry=0x7fffd9c0) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6568 #5 0x00c9cb35 in tree_ssa_iv_optimize_loop (loop=optimized out, data=0x7fffd9c0) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6894 #6 tree_ssa_iv_optimize () at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6926 Ah, so the issue is that may_be_unaligned does 1706 unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); 1707 1708 unsigned HOST_WIDE_INT bitpos; 1709 unsigned int ref_align; 1710 get_object_alignment_1 (ref, ref_align, bitpos); 1711 if (ref_align align 1712 || (bitpos % align) != 0 1713 || (bitpos % BITS_PER_UNIT) != 0) 1714return true; thus it queries TYPE_ALIGN (TREE_TYPE (ref)) which is 8 - and _not_ mode alignment which is what matters on STRICT_ALIGNMENT targets. Fix: Index: gcc/tree-ssa-loop-ivopts.c === --- gcc/tree-ssa-loop-ivopts.c (revision 213050) +++ gcc/tree-ssa-loop-ivopts.c (working copy) @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step) return false; unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); + if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) align) +align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))); unsigned HOST_WIDE_INT bitpos; unsigned int ref_align; can you test and apply that patch? Thx. With that patch I get ldub[%g3+1], %g2! MEM[(unsigned char *)ptr_110], MEM[(unsigned char *)ptr_110] ldub[%g3], %g1 ! MEM[(unsigned char *)ptr_110], MEM[(unsigned char *)ptr_110] sll %g1, 8, %g1 ! MEM[(unsigned char *)ptr_110],, tmp462 or %g2, %g1, %g1 ! MEM[(unsigned char *)ptr_110], tmp462, min_line
[Bug target/56091] gcc.target/arm/pr43137.c fails for THUMB-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56091 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #3 from ktkachov at gcc dot gnu.org --- I can't reproduce it with current 4.8.3, 4.9.2 or trunk on arm-none-eabi/-march=armv5t/-mthumb I'm closing this. If you can reproduce this with any maintained version of gcc please reopen with the relevant details. RTX costs for arm have been rewritten quite extensively for 4.9 btw
[Bug middle-end/61893] Constant folding inhibits trapping with -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61893
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Fixed by sth like
Index: fold-const.c
===
--- fold-const.c(revision 212388)
+++ fold-const.c(working copy)
@@ -1121,7 +1121,12 @@
STRIP_NOPS (arg2);
if (TREE_CODE (arg1) == INTEGER_CST)
-return int_const_binop (code, arg1, arg2);
+{
+ tree res = int_const_binop (code, arg1, arg2);
+ if (res TYPE_OVERFLOW_TRAPS (TREE_TYPE (arg1)) TREE_OVERFLOW
(res))
+return NULL_TREE;
+ return res;
+}
if (TREE_CODE (arg1) == REAL_CST)
{
[Bug target/61551] [NEON] alter costs to allow use of post-indexed addressing modes for VLD{2..4}/VST{2..4}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61551 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-25 CC||ramana at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1
[Bug libstdc++/61909] New: Small function optimization not applied to small objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909
Bug ID: 61909
Summary: Small function optimization not applied to small
objects
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lukeocamden at gmail dot com
Seems like std::function only manages to avoid malloc for function pointers,
but not for small objects.
$ g++ --version
g++ (GCC) 4.10.0 20140720 (experimental)
Here's a test I ran on my Linux machine:
#include functional
extern C void* malloc(size_t) { abort(); }
struct X
{
void operator()() { }
};
void foo() { }
int main()
{
std::functionvoid() f1((static_castvoid (*)()([]{}))); // OK
std::functionvoid() f2(foo); // OK
std::functionvoid() f3((X())); // abort
std::functionvoid() f4([]{}); // abort
}
[Bug fortran/61910] New: undefined computation in trans-expr.c gfc_conv_cst_int_power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61910 Bug ID: 61910 Summary: undefined computation in trans-expr.c gfc_conv_cst_int_power Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Analyzing with sanitized gfortran the following line j=i**(-huge(0_8)-1) I get the following message: ../../gcc-4.9.1/gcc/fortran/trans-expr.c:2107:48: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself The offending line in trans-expr.c is n = (unsigned HOST_WIDE_INT) (m 0 ? -m : m);
[Bug middle-end/61893] Constant folding inhibits trapping with -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61893
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Fixing bit-ccp with
Index: tree-ssa-ccp.c
===
--- tree-ssa-ccp.c (revision 213040)
+++ tree-ssa-ccp.c (working copy)
@@ -1456,8 +1456,19 @@ bit_value_unop (enum tree_code code, tre
widest_int value, mask;
prop_value_t val;
- if (rval.lattice_val == UNDEFINED)
-return rval;
+ if (rval.lattice_val == UNDEFINED
+ /* If the value is fully known constants assume that
+earlier simplification failed for a reason, for example
+due to -ftrapv. */
+ || (rval.lattice_val == CONSTANT
+ TREE_CODE (rval.value) == INTEGER_CST
+ rval.mask == -1))
+{
+ val.lattice_val = VARYING;
+ val.value = NULL_TREE;
+ val.mask = -1;
+ return val;
+}
gcc_assert ((rval.lattice_val == CONSTANT
TREE_CODE (rval.value) == INTEGER_CST)
@@ -1492,7 +1503,16 @@ bit_value_binop (enum tree_code code, tr
prop_value_t val;
if (r1val.lattice_val == UNDEFINED
- || r2val.lattice_val == UNDEFINED)
+ || r2val.lattice_val == UNDEFINED
+ /* If both values are fully known constants assume that
+earlier simplification failed for a reason, for example
+due to -ftrapv. */
+ || (r1val.lattice_val == CONSTANT
+ TREE_CODE (r1val.value) == INTEGER_CST
+ r1val.mask == 0
+ r2val.lattice_val == CONSTANT
+ TREE_CODE (r2val.value) == INTEGER_CST
+ r2val.mask == 0))
{
val.lattice_val = VARYING;
val.value = NULL_TREE;
reveals that expansion produces
(insn 5 4 6 (set (reg:SI 4 si)
(const_int 1 [0x1])) t.c:7 -1
(nil))
(insn 6 5 7 (set (reg:SI 5 di)
(const_int 2147483647 [0x7fff])) t.c:7 -1
(nil))
(call_insn/u 7 6 8 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI (__addvsi3) [flags 0x41]) [0 S1 A8])
(const_int 0 [0]))) t.c:7 -1
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(expr_list (use (reg:SI 4 si))
(expr_list (use (reg:SI 5 di))
(nil
(insn 8 7 9 (set (reg:SI 86 [ D.1753 ])
(reg:SI 0 ax)) t.c:7 -1
(expr_list:REG_EQUAL (plus:SI (const_int 2147483647 [0x7fff])
(const_int 1 [0x1]))
(nil)))
note the REG_EQUAL note which CSE happily simplifies and substitutes...
Index: optabs.c
===
--- optabs.c(revision 213040)
+++ optabs.c(working copy)
@@ -3985,7 +3985,8 @@ emit_libcall_block_1 (rtx insns, rtx tar
}
last = emit_move_insn (target, result);
- set_dst_reg_note (last, REG_EQUAL, copy_rtx (equiv), target);
+ if (!equiv_may_trap)
+set_dst_reg_note (last, REG_EQUAL, copy_rtx (equiv), target);
if (final_dest != target)
emit_move_insn (final_dest, target);
with that we finally trap with -O2...
[Bug c/61779] gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779 --- Comment #12 from Vittorio Zecca zeccav at gmail dot com --- Yes, you did say it will be fixed in 4.9.2. Sorry. I did: export CFLAGS=-ggdb -Og export CXXFLAGS=$CFLAGS ../gcc-4.9.1/configure --prefix=/home/vitti/local/gcc-4.9.1 --disable-lto --with-tune=k8 --enable-languages=c,c++,fortran I compiled manually divtf3.c without -Og.
[Bug ada/61911] New: CONSTRAINT_ERROR in gnatmake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61911 Bug ID: 61911 Summary: CONSTRAINT_ERROR in gnatmake Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: porton at narod dot ru Created attachment 33185 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33185action=edit librdf.gpr gnatmake -d -P/home/porton/Projects/redland-bindings/ada/test.gpr -XRUNTIME=full -XMODE=Install -s --subdirs=check -cargs -g -O0 -gnato -fstack-check -gnatVa librdf.gpr:6:25: warning: undefined external reference librdf.gpr:7:28: warning: undefined external reference Exception name: CONSTRAINT_ERROR Message: ali.adb:139 access check failed gnatmake: INTERNAL ERROR. Please report. gnat 4.9.0-2 gcc 4.9.0-7 in Debian testing
[Bug ada/61911] CONSTRAINT_ERROR in gnatmake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61911 Victor Porton porton at narod dot ru changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Victor Porton porton at narod dot ru --- It works after cleaning and re-building my project. So I close the bug.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #61 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Ok, I suppose lduh[%g3], %g4 ! MEM[base: ptr_110, offset: 0B], min_line is not an instruction that works with unaligned %g3. Right, every load must be aligned. ;; min_line_106 = (int) _215; (insn 921 920 922 (set (reg:HI 482) (mem:HI (reg/v/f:SI 185 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2 A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1 (nil)) a (mem:HI ...) with A8. I wonder if we should ICE somewhere if such kind of MEM is in the RTL instruction stream on a STRICT_ALIGNMENT platform? No, it's undefined behavior at run time only. Ah, so the issue is that may_be_unaligned does 1706 unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); 1707 1708 unsigned HOST_WIDE_INT bitpos; 1709 unsigned int ref_align; 1710 get_object_alignment_1 (ref, ref_align, bitpos); 1711 if (ref_align align 1712 || (bitpos % align) != 0 1713 || (bitpos % BITS_PER_UNIT) != 0) 1714return true; thus it queries TYPE_ALIGN (TREE_TYPE (ref)) which is 8 - and _not_ mode alignment which is what matters on STRICT_ALIGNMENT targets. Yes, and that's what the original implementation actually did, see: https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00717.html Fix: Index: gcc/tree-ssa-loop-ivopts.c === --- gcc/tree-ssa-loop-ivopts.c (revision 213050) +++ gcc/tree-ssa-loop-ivopts.c (working copy) @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step) return false; unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); + if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) align) +align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))); unsigned HOST_WIDE_INT bitpos; unsigned int ref_align; can you test and apply that patch? I think that it needs to be applied on both mainline and 4.9 branch then.
[Bug middle-end/61912] New: Missed (partial) dead store elimination for structures on GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61912
Bug ID: 61912
Summary: Missed (partial) dead store elimination for structures
on GIMPLE
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
For simple case like below,
typedef unsigned int wchar_t;
struct printf_info
{
int prec;
int width;
wchar_t spec;
unsigned int is_long_double:1;
unsigned int is_short:1;
unsigned int is_long:1;
unsigned int alt:1;
unsigned int space:1;
unsigned int left:1;
unsigned int showsign:1;
unsigned int group:1;
unsigned int extra:1;
unsigned int is_char:1;
unsigned int wide:1;
unsigned int i18n:1;
unsigned int __pad:4;
unsigned short int user;
wchar_t pad;
} info;
void bar (struct printf_info *);
void foo(int prec,
int width,
wchar_t spec,
unsigned int is_long_double,
unsigned int is_short,
unsigned int is_long,
unsigned int alt,
unsigned int space,
unsigned int left,
unsigned int showsign,
unsigned int group,
wchar_t pad)
{
struct printf_info info = {
.prec = prec,
.width = width,
.spec = spec,
.is_long_double = is_long_double,
.is_short = is_short,
.is_long = is_long,
.alt = alt,
.space = space,
.left = left,
.showsign = showsign,
.group = group,
.pad = pad,
.extra = 0,
.wide = sizeof (char) != 1 };
bar (info);
}
The dump before both gimple level DSE pass is like below,
bb 2:
info = {};
info.prec = prec_3(D);
info.width = width_5(D);
info.spec = spec_7(D);
_10 = (unsigned char) is_long_double_9(D);
_11 = (unnamed-unsigned:1) _10;
info.is_long_double = _11;
_14 = (unsigned char) is_short_13(D);
_15 = (unnamed-unsigned:1) _14;
info.is_short = _15;
_18 = (unsigned char) is_long_17(D);
_19 = (unnamed-unsigned:1) _18;
info.is_long = _19;
_22 = (unsigned char) alt_21(D);
_23 = (unnamed-unsigned:1) _22;
info.alt = _23;
_26 = (unsigned char) space_25(D);
_27 = (unnamed-unsigned:1) _26;
info.space = _27;
_30 = (unsigned char) left_29(D);
_31 = (unnamed-unsigned:1) _30;
info.left = _31;
_34 = (unsigned char) showsign_33(D);
_35 = (unnamed-unsigned:1) _34;
info.showsign = _35;
_38 = (unsigned char) group_37(D);
_39 = (unnamed-unsigned:1) _38;
info.group = _39;
info.pad = pad_41(D);
bar (info);
info ={v} {CLOBBER};
return;
Most cleanups of structure `info' are dead because fields are going to be set
again. For now GCC just generates call to memset for the structure cleanup and
let rtl decide whether the memset call should be inlined. If it is inlined,
RTL dse can eliminate some of the dead store. The problem with RTL DSE is it
lacks high level information and don't see the nature of structure, especially
if the memset is inlined with vectorized instruction.
So, I wonder if it's possible to have GIMPLE DSE to eliminate the redundant
store operation. Apparently, we may need heuristic information to decide if
the cleanup of structure should be scalarized and eliminated. I think it
depends on how many fields are left, also how difficult to set them to ZERO
(considering the bit-fields).
Thanks.
[Bug middle-end/61876] Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Fri, 25 Jul 2014, ktkachov at gcc dot gnu.org wrote: In any case, it seems to me the transformation of cast+round - lround is only valid when: - the result is within the range of the long int - the argument is not NaN or infinity. In convert.c this transformation is already guarded by the type precision so we got the first point covered, but I think we also have to guard it by -ffinite-math-only. Is that reasonable? The precision test in convert.c is about conversions to types narrower than long; it's purely about precisions of integer types and has nothing to do with the first point (which would be about exponent range). The transformation should be conditional on -fno-math-errno. If in future DTS 18661-3 support is implemented, exponent range checks would be relevant to being able to determine that a conversion from cast + roundf16 to lroundf16 is safe with -ffinite-math-only (because of the limited exponent range of _Float16), but there are many other things that would be needed for proper implementation of DTS 18661-3 (making all the relevant builtins generic across a wider range of floating-point types).
[Bug middle-end/61913] New: ICE in common_handle_option with -Wodr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61913 Bug ID: 61913 Summary: ICE in common_handle_option with -Wodr Product: gcc Version: 4.10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: hubicka at gcc dot gnu.org The following gives an ICE: $ touch foo.cc $ g++ -Wodr foo.cc cc1plus: internal compiler error: in common_handle_option, at opts.c:1926 0x119e5f3 common_handle_option(gcc_options*, gcc_options*, cl_decoded_option const*, unsigned int, int, unsigned int, cl_option_handlers const*, diagnostic_context*) ../../gcc/opts.c:1926 0x11a0e07 handle_option ../../gcc/opts-common.c:925 0x11a10b3 read_cmdline_option(gcc_options*, gcc_options*, cl_decoded_option*, unsigned int, unsigned int, cl_option_handlers const*, diagnostic_context*) ../../gcc/opts-common.c:1101 0xb2f357 read_cmdline_options ../../gcc/opts-global.c:235 0xb2f357 decode_options(gcc_options*, gcc_options*, cl_decoded_option*, unsigned int, unsigned int, diagnostic_context*) ../../gcc/opts-global.c:309
[Bug target/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 --- Comment #7 from Linus Torvalds torva...@linux-foundation.org --- Just for completeness for the original bug report, here's the actual compiler command line that the kernel uses to generate the *.s file. gcc -Wp,-MD,kernel/sched/.fair.s.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.3/include -I./arch/x86/include -Iarch/x86/include/generated -Iinclude -I./arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -m64 -mno-mmx -mno-sse -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(fair) -DKBUILD_MODNAME=KBUILD_STR(fair) -fverbose-asm -S -o kernel/sched/fair.s kernel/sched/fair.c although looking at the generated .s file in the attachment, I really think it's all there too in the comments at the top of the file.
[Bug target/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 --- Comment #8 from Linus Torvalds torva...@linux-foundation.org --- Oh, and this is marked as a duplicate of 61801, but that one is marked to be in gcc-4.8.3 The particular problem we see in kernel code generation seems to *not* happen in 4.8.3 (current fedora 20), and happens with Debian 4.9.0. So now I worry about (a) whether the duplicate bug is really true (b) or perhaps 4.8.3 really does have the same problem and we might get bitten there too, and it just happens to trigger on 4.9.0 for some otherwise unrelated reason. I'd like to have some way to tell known-bad compilers, so that we know to avoid them..
[Bug target/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Linus Torvalds from comment #8) Oh, and this is marked as a duplicate of 61801, but that one is marked to be in gcc-4.8.3 The particular problem we see in kernel code generation seems to *not* happen in 4.8.3 (current fedora 20), and happens with Debian 4.9.0. Different optimization happen before the scheduler between 4.8.3 and 4.9.0 which causes the difference. So now I worry about (a) whether the duplicate bug is really true It is as the true issue was fixed there. (b) or perhaps 4.8.3 really does have the same problem and we might get bitten there too, and it just happens to trigger on 4.9.0 for some otherwise unrelated reason. Correct. I'd like to have some way to tell known-bad compilers, so that we know to avoid them.. The bad compiler versions are 4.5.0 (when debug_insn came in) to 4.8.3 and 4.9.0 and 4.9.1.
[Bug target/61904] Incorrect stack red-zoning on x86-64 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 --- Comment #10 from Linus Torvalds torva...@linux-foundation.org --- (In reply to Andrew Pinski from comment #9) The bad compiler versions are 4.5.0 (when debug_insn came in) to 4.8.3 and 4.9.0 and 4.9.1. Ok, so we have no reasonable way of avoiding the problem compiler version. I had hoped that we could just do a warning if people use 4.9.0/1, since they aren't very common yet. Ugh. We had one suggestion of having some post-compile checking pass, but that one was (so far) just handwaving (objdump + perl-script). It doesn't sound very pleasant. The problem is that these things are a bitch to debug - they turn into these completely impossible kernel oopses or corruption, and we were just very lucky that this one case happened to be repeatable and pinpoint for two people. Are there others? We have no way of knowing.. Anyway, thanks for the quick resolution, even if I'm now rather nervous about existing compilers..
[Bug preprocessor/60858] 64-bit multi-character constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60858 Ed Smith-Rowland 3dw4rd at verizon dot net changed: What|Removed |Added CC||3dw4rd at verizon dot net --- Comment #3 from Ed Smith-Rowland 3dw4rd at verizon dot net --- You send a message containing a patch (which should include a test case) an explanation for the change (explanation of method if needed, motivation/rationale for addition) and a ChangeLog entry to gcc-patc...@gcc.gnu.org. You'll need Copyright paperwork too. Basically, see https://gcc.gnu.org/contribute.html. Having said that, at least C++ has standard language specifying 'int' for multi-character char constants. So I think you'll need to enable this with a flag, -flong-long-multicharacter-const, maybe.
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #25 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Left to do: For format strings greater than 80 characters, shift the view of where the error occurs in the format string so that it will display reasonably well. (If the error occurs after 80 characters in the string.)
[Bug bootstrap/61914] New: [4.10 Regression] wide-int change breaks x32 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61914 Bug ID: 61914 Summary: [4.10 Regression] wide-int change breaks x32 bootstrap Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com r210113 breaks x32 bootstrap when GCC is compiled as x32 binary with # CC=gcc -mx32 CXX=g++ -mx32 .../gcc/configure I got [hjl@gnu-mic-2 build-x86_64-linux]$ grep xfff gcc/gtype.state (!pair A\xfff1 (!type undefined 1484 nil gc_unused A\xfff1 (!pair A\xfff1 (!pair A\xfff1 [hjl@gnu-mic-2 build-x86_64-linux]$
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Severity|normal |enhancement --- Comment #17 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I have a patch in the works. The idea is to query the locale at the time the Unit is connected and save the LC_NUMERIC character in the unit structure. Then, if the decimal character matches the DECIMAL_STATUS (decimal=point or decimal=comma) active at the time of reading, change the decimal character internally to the current locale character previously saved. This way, only one call to locale is needed per unit connection, preserving efficiency. The real string will then be converted correctly, regardless of locale.
[Bug target/61915] New: [AArch64] Default use of the LRA results in extra code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 Bug ID: 61915 Summary: [AArch64] Default use of the LRA results in extra code size Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: e.menezes at samsung dot com The issue that I observed in code size due to the default use of the LRA results in the spilling of the FP register used to spill variables into, which increases code-size. For example, in Dhrystone, out of dhry_1.c I see sequences like this: ldrd9, [sp, 144] ... fmovx0, d9 blprintf ... fmovx0, d9 ... blprintf By disabling the LRA, the code is a tad leaner (2%): ldrx0, [sp, 144] ... blprintf ... ldrx0, [sp, 144] ... blprintf Moreover, is transferring registers between the GP and the FP register files always cheap? In some x86 processors this used to be accomplished internally through the load-store unit anyway (e.g., Opteron). How is this accomplished internally in A53 and A57? Is using the LRA by default clearly beneficial in other cases? At the Cauldron I mentioned some variables that could be rematerialized when needed instead of being spilled, but I could not reproduce that. I'll try some more to spot this behavior.
[Bug target/61915] [AArch64] Default use of the LRA results in extra code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- How is this accomplished internally in A53 and A57? I don't know about A53 and A57 but I can say that for Cavium's Thunder, it does not go through the load/store unit and there is a direct path between the gprs and fps (and the latency for them is low).
[Bug target/61915] [AArch64] Default use of the LRA results in extra code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc/2014-05/msg00160.html
[Bug target/61915] [AArch64] Default use of the LRA results in extra code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #3 from Evandro Menezes e.menezes at samsung dot com --- In Opteron, there was a path from FP to the GP registers, but not the other way around. That path was eventually made symmetric in Barcelona only.
[Bug c++/60850] pedantic warning behavior when casting void* to ptr-to-func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850 Tony Kelman tony at kelman dot net changed: What|Removed |Added CC||tony at kelman dot net --- Comment #7 from Tony Kelman tony at kelman dot net --- Applying this change has made GCC 4.8.3 unusable for a large body of legacy code. Not good for a patch release. Anything that uses old versions of autoconf where the AC_CHECK_DECL probe used exactly this kind of cast, and has -pedantic-errors in its CFLAGS, now gets completely different results from configure, in many cases failing to build. I realize the right solution is to update to a newer version of autoconf in these cases, but there are many thousands of lines of custom autoconf macros out there that make that much easier said than done. Or remove -pedantic-errors, but that could lead to a different set of problems. As GCC 4.8.3 makes it into more distributions this is going to become a maintenance burden, forcing a great deal of patching around the problem or recommending users install different compiler versions than their default.
[Bug c/61916] New: Internal compiler error in symtab_nonoverwritable_alias with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61916 Bug ID: 61916 Summary: Internal compiler error in symtab_nonoverwritable_alias with -O2 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: timothygu99 at gmail dot com Created attachment 33186 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33186action=edit Preprocessed source that allows to reproduce the bug Hi, I am on x86_64-unknown-linux-gnu cross-compiling to i686-pc-mingw32 with mingwrt 3.20-2 and w32api 3.17. The complete configure flags used to compile GCC is: --target='i686-pc-mingw32' \ --build='x86_64-mingw32-unknown' \ --prefix='my-dir' \ --libdir='my-dir/lib' \ --enable-languages='c,c++,objc,fortran' \ --enable-version-specific-runtime-libs \ --with-gcc \ --with-gnu-ld \ --with-gnu-as \ --disable-nls \ --disable-multilib \ --without-x \ --disable-win32-registry \ --enable-threads=win32 \ --disable-libgomp \ --disable-libmudflap \ --with-cloog='my-dir' \ --with-gmp='my-dir' \ --with-isl='my-dir' \ --with-mpc='my-dir' \ --with-mpfr='my-dir' \ --with-as='my-dir/bin/i686-pc-mingw32-as' \ --with-ld='my-dir/bin/i686-pc-mingw32-ld' \ --with-nm='my-dir/bin/i686-pc-mingw32-nm' I am trying to compile imlib2 1.4.6; however when compiling src/lib/api.c gcc errors out: $ i686-pc-mingw32-gcc -DHAVE_CONFIG_H -DPACKAGE_LIB_DIR=\my-dir/lib\ [a bunch of -I's] -save-temps -O2 -c api.c -o .libs/api.o api.c:5411:1: internal compiler error: in symtab_nonoverwritable_alias, at symtab.c:1234 } ^ 0x659ed4 symtab_nonoverwritable_alias(symtab_node*) /home/timothy_gu/mxe/tmp-gcc-i686-pc-mingw32.shared/gcc-4.9.0/gcc/symtab.c:1234 0x79e161 function_and_variable_visibility /home/timothy_gu/mxe/tmp-gcc-i686-pc-mingw32.shared/gcc-4.9.0/gcc/ipa.c:1085 0x79e906 whole_program_function_and_variable_visibility /home/timothy_gu/mxe/tmp-gcc-i686-pc-mingw32.shared/gcc-4.9.0/gcc/ipa.c:1290 0x79e906 execute /home/timothy_gu/mxe/tmp-gcc-i686-pc-mingw32.shared/gcc-4.9.0/gcc/ipa.c:1334 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. (The exact compilation command provided by the project also contains lots of -W's and some -f's. I have confirmed that removing them still allows to reproduce this bug.) This issue is only reproducible with -O2 or higher. -O1 works fine. The preprocessed source is attached.
[Bug c/61916] Internal compiler error in symtab_nonoverwritable_alias with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61916 --- Comment #1 from Timothy Gu timothygu99 at gmail dot com --- With `-v`, gcc outputs this: i686-pc-mingw32.shared-gcc -DHAVE_CONFIG_H -I. -I../.. -DPACKAGE_LIB_DIR=\/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib\ -I../.. -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/harfbuzz -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/cairo -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/pixman-1 -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/freetype2 -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/libpng16 -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/glib-2.0 -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib/glib-2.0/include -v -save-temps -O2 -c api.c -o .libs/api.o Using built-in specs. COLLECT_GCC=i686-pc-mingw32.shared-gcc Target: i686-pc-mingw32.shared Configured with: /home/timothy_gu/mxe/tmp-gcc-i686-pc-mingw32.shared/gcc-4.9.0/configure --target=i686-pc-mingw32.shared --build=x86_64-unknown-linux-gnu --prefix=/home/timothy_gu/mxe/usr --libdir=/home/timothy_gu/mxe/usr/lib --enable-languages=c,c++,objc,fortran --enable-version-specific-runtime-libs --with-gcc --with-gnu-ld --with-gnu-as --disable-nls --disable-multilib --without-x --disable-win32-registry --enable-threads=win32 --disable-libgomp --disable-libmudflap --with-cloog=/home/timothy_gu/mxe/usr --with-gmp=/home/timothy_gu/mxe/usr --with-isl=/home/timothy_gu/mxe/usr --with-mpc=/home/timothy_gu/mxe/usr --with-mpfr=/home/timothy_gu/mxe/usr --with-as=/home/timothy_gu/mxe/usr/bin/i686-pc-mingw32.shared-as --with-ld=/home/timothy_gu/mxe/usr/bin/i686-pc-mingw32.shared-ld --with-nm=/home/timothy_gu/mxe/usr/bin/i686-pc-mingw32.shared-nm --disable-sjlj-exceptions Thread model: win32 gcc version 4.9.0 (GCC) COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '../..' '-D' 'PACKAGE_LIB_DIR=/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib' '-I' '../..' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/harfbuzz' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/cairo' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/pixman-1' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/freetype2' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/libpng16' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/glib-2.0' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib/glib-2.0/include' '-v' '-save-temps' '-O2' '-c' '-o' '.libs/api.o' '-mtune=generic' '-march=pentiumpro' /home/timothy_gu/mxe/usr/libexec/gcc/i686-pc-mingw32.shared/4.9.0/cc1 -E -quiet -v -I . -I ../.. -I ../.. -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/harfbuzz -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/cairo -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/pixman-1 -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/freetype2 -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/libpng16 -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/glib-2.0 -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib/glib-2.0/include -D HAVE_CONFIG_H -D PACKAGE_LIB_DIR=/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib api.c -mtune=generic -march=pentiumpro -O2 -fpch-preprocess -o api.i ignoring nonexistent directory /home/timothy_gu/mxe/usr/lib/gcc/i686-pc-mingw32.shared/4.9.0/../../../../i686-pc-mingw32.shared/sys-include ignoring duplicate directory ../.. #include ... search starts here: #include ... search starts here: . ../.. /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/harfbuzz /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/cairo /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/pixman-1 /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/freetype2 /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/libpng16 /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/glib-2.0 /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib/glib-2.0/include /home/timothy_gu/mxe/usr/lib/gcc/i686-pc-mingw32.shared/4.9.0/include /home/timothy_gu/mxe/usr/lib/gcc/i686-pc-mingw32.shared/4.9.0/include-fixed /home/timothy_gu/mxe/usr/lib/gcc/i686-pc-mingw32.shared/4.9.0/../../../../i686-pc-mingw32.shared/include End of search list. COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '../..' '-D' 'PACKAGE_LIB_DIR=/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib' '-I' '../..' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/harfbuzz' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/cairo' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/pixman-1' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/freetype2' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/libpng16' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/glib-2.0' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib/glib-2.0/include' '-v' '-save-temps' '-O2' '-c' '-o' '.libs/api.o'
[Bug c/61916] Internal compiler error in symtab_nonoverwritable_alias with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61916 Timothy Gu timothygu99 at gmail dot com changed: What|Removed |Added Target||i686-pc-mingw32 Host||i686-pc-mingw32 Build||x86_64-unknown-linux-gnu --- Comment #2 from Timothy Gu timothygu99 at gmail dot com --- By the way, I am running Ubuntu 14.10 LTS Trusty with: $ gcc -v --version Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -quiet -v -imultiarch x86_64-linux-gnu help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase help-dummy -version --version -fstack-protector -Wformat -Wformat-security -o /tmp/cc5aNNFg.s GNU C (Ubuntu 4.8.2-19ubuntu1) version 4.8.2 (x86_64-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64' as -v --64 --version -o /tmp/ccoQRpil.o /tmp/cc5aNNFg.s GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.24 GNU assembler (GNU Binutils for Ubuntu) 2.24 Copyright 2013 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'. COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.8/collect2 --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro --version /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. /tmp/ccoQRpil.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o collect2 version 4.8.2 /usr/bin/ld --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro --version /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o
[Bug c/61916] Internal compiler error in symtab_nonoverwritable_alias with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61916 Timothy Gu timothygu99 at gmail dot com changed: What|Removed |Added Version|4.9.0 |4.9.1 --- Comment #3 from Timothy Gu timothygu99 at gmail dot com --- I can confirm that this is also reproducible with gcc 4.9.1: $ i686-pc-mingw32.shared-gcc -DHAVE_CONFIG_H -I. -I../.. -DPACKAGE_LIB_DIR=\/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib\ -I../.. -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/harfbuzz -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/cairo -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/pixman-1 -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/freetype2 -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/libpng16 -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/glib-2.0 -I/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib/glib-2.0/include -v -save-temps -O2 -c api.c -o .libs/api.o Using built-in specs. COLLECT_GCC=i686-pc-mingw32.shared-gcc Target: i686-pc-mingw32.shared Configured with: /home/timothy_gu/mxe/tmp-gcc-i686-pc-mingw32.shared/gcc-4.9.1/configure --target=i686-pc-mingw32.shared --build=x86_64-unknown-linux-gnu --prefix=/home/timothy_gu/mxe/usr --libdir=/home/timothy_gu/mxe/usr/lib --enable-languages=c,c++,objc,fortran --enable-version-specific-runtime-libs --with-gcc --with-gnu-ld --with-gnu-as --disable-nls --disable-multilib --without-x --disable-win32-registry --enable-threads=win32 --disable-libgomp --disable-libmudflap --with-cloog=/home/timothy_gu/mxe/usr --with-gmp=/home/timothy_gu/mxe/usr --with-isl=/home/timothy_gu/mxe/usr --with-mpc=/home/timothy_gu/mxe/usr --with-mpfr=/home/timothy_gu/mxe/usr --with-as=/home/timothy_gu/mxe/usr/bin/i686-pc-mingw32.shared-as --with-ld=/home/timothy_gu/mxe/usr/bin/i686-pc-mingw32.shared-ld --with-nm=/home/timothy_gu/mxe/usr/bin/i686-pc-mingw32.shared-nm --disable-sjlj-exceptions Thread model: win32 gcc version 4.9.1 (GCC) COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '../..' '-D' 'PACKAGE_LIB_DIR=/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib' '-I' '../..' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/harfbuzz' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/cairo' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/pixman-1' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/freetype2' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/libpng16' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/glib-2.0' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib/glib-2.0/include' '-v' '-save-temps' '-O2' '-c' '-o' '.libs/api.o' '-mtune=generic' '-march=pentiumpro' /home/timothy_gu/mxe/usr/libexec/gcc/i686-pc-mingw32.shared/4.9.1/cc1 -E -quiet -v -I . -I ../.. -I ../.. -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/harfbuzz -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/cairo -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/pixman-1 -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/freetype2 -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/libpng16 -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/glib-2.0 -I /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib/glib-2.0/include -D HAVE_CONFIG_H -D PACKAGE_LIB_DIR=/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib api.c -mtune=generic -march=pentiumpro -O2 -fpch-preprocess -o api.i ignoring nonexistent directory /home/timothy_gu/mxe/usr/lib/gcc/i686-pc-mingw32.shared/4.9.1/../../../../i686-pc-mingw32.shared/sys-include ignoring duplicate directory ../.. #include ... search starts here: #include ... search starts here: . ../.. /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/harfbuzz /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/cairo /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/pixman-1 /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/freetype2 /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/libpng16 /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/glib-2.0 /home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib/glib-2.0/include /home/timothy_gu/mxe/usr/lib/gcc/i686-pc-mingw32.shared/4.9.1/include /home/timothy_gu/mxe/usr/lib/gcc/i686-pc-mingw32.shared/4.9.1/include-fixed /home/timothy_gu/mxe/usr/lib/gcc/i686-pc-mingw32.shared/4.9.1/../../../../i686-pc-mingw32.shared/include End of search list. COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '../..' '-D' 'PACKAGE_LIB_DIR=/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/lib' '-I' '../..' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/harfbuzz' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/cairo' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/pixman-1' '-I' '/home/timothy_gu/mxe/usr/i686-pc-mingw32.shared/include/freetype2' '-I'
[Bug tree-optimization/61917] New: ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917
Bug ID: 61917
Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
vectorizable_reduction, at tree-vect-loop.c:4913
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk and
gcc 4.9 at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes).
It is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140725 (experimental) [trunk revision 213036] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-4.8 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.c:4913
fn1 ()
^
0xb8eb3c vectorizable_reduction(gimple_statement_base*, gimple_stmt_iterator*,
gimple_statement_base**, _slp_tree*)
../../gcc-trunk/gcc/tree-vect-loop.c:4913
0xb8144f vect_analyze_stmt(gimple_statement_base*, bool*, _slp_tree*)
../../gcc-trunk/gcc/tree-vect-stmts.c:7103
0xb8ccee vect_analyze_loop_operations
../../gcc-trunk/gcc/tree-vect-loop.c:1505
0xb8ccee vect_analyze_loop_2
../../gcc-trunk/gcc/tree-vect-loop.c:1766
0xb8ccee vect_analyze_loop(loop*)
../../gcc-trunk/gcc/tree-vect-loop.c:1864
0xba50cf vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:432
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.
$
$ gcc-4.9 -O3 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.c:4907
fn1 ()
^
0x9b6f35 vectorizable_reduction(gimple_statement_base*, gimple_stmt_iterator*,
gimple_statement_base**, _slp_tree*)
../../gcc-4.9.0/gcc/tree-vect-loop.c:4907
0x9a94e8 vect_analyze_stmt(gimple_statement_base*, bool*, _slp_tree*)
../../gcc-4.9.0/gcc/tree-vect-stmts.c:7103
0x9b54e6 vect_analyze_loop_operations
../../gcc-4.9.0/gcc/tree-vect-loop.c:1505
0x9b54e6 vect_analyze_loop_2
../../gcc-4.9.0/gcc/tree-vect-loop.c:1765
0x9b54e6 vect_analyze_loop(loop*)
../../gcc-4.9.0/gcc/tree-vect-loop.c:1863
0x9c9f3b vectorize_loops()
../../gcc-4.9.0/gcc/tree-vectorizer.c:430
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.
$
int a, b, c, d;
int
fn1 ()
{
for (; c; c++)
for (b = 0; b 2; b++)
d = a - d;
return d;
}
[Bug preprocessor/61918] New: With -isystem, symlinks are sometimes processed incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61918 Bug ID: 61918 Summary: With -isystem, symlinks are sometimes processed incorrectly Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: mitya57 at gmail dot com Originally reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755767. Here is the minimal test case: $ ls -l correct lrwxrwxrwx 1 dmitry dmitry 16 Jul 26 09:07 first.h - ../wrong/first.h -rw-r--r-- 1 dmitry dmitry 0 Jul 26 09:27 second.h $ ls -l wrong -rw-r--r-- 1 dmitry dmitry 20 Jul 26 09:07 first.h -rw-r--r-- 1 dmitry dmitry 38 Jul 26 09:27 second.h $ cat wrong/first.h #include second.h $ cat wrong/second.h #warning Should not include this file $ cat correct/second.h $ cat test.c #include first.h $ cpp -I $(pwd)/correct test.c /dev/null $ cpp -isystem $(pwd)/correct test.c /dev/null In file included from /tmp/wrong/first.h:1:0, from test.c:1: /tmp/wrong/second.h:1:2: warning: #warning Should not include this file [-Wcpp] #warning Should not include this file ^ $ cpp -isystem ./correct test.c /dev/null $ As you can see, correct/first.h is a symlink to wrong/first.h, which in turn includes second.h. However, I see no reason why cpp follows that symlinks and opens second.h in wrong directory. When I use -I instead of -isystem, or use relative file path instead of absolute, the behavior is correct. Also, clang always handles this correctly.
