[Bug c++/58627] [4.9 Regression] crash during compilation of boost testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31407 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31407action=edit gcc49-pr58627.patch Untested fix.
[Bug target/59444] New: [4.6.3 32-bit] Character buffers on stack not aligned on a 4-byte boundary.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59444 Bug ID: 59444 Summary: [4.6.3 32-bit] Character buffers on stack not aligned on a 4-byte boundary. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vasiliy.v.buzoverya at intel dot com Created attachment 31408 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31408action=edit Preprocessed file that triggers the bug. 4.6.3 on Ubuntu 12.04 32-bit. A function has two character buffers on stack(of 5 and 10 bytes in size). The addresses of the buffers won't get aligned on a 4-byte boundary even if the -mpreferred-stack-boundary=2 compilation option is specified. The addresses of the buffers are odd values, e.g. 0xb17f and 0xb175. Here's a snippet of assembler code: 0x080483e4 +0:push %ebp 0x080483e5 +1:mov%esp,%ebp 0x080483e7 +3:sub$0x20,%esp 0x080483ea +6:lea-0x9(%ebp),%eax ... 0x08048403 +31:lea-0x13(%ebp),%eax ... Build log: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-O0' '-mpreferred-stack-boundary=2' '-fno-stack-protector' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-gnu/4.6/cc1 -E -quiet -v -imultilib . -imultiarch i386-linux-gnu example.c -mpreferred-stack-boundary=2 -mtune=generic -march=i686 -Wall -Wextra -fno-stack-protector -O0 -fpch-preprocess -o example.i ignoring nonexistent directory /usr/local/include/i386-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i686-linux-gnu/4.6/../../../../i686-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/i686-linux-gnu/4.6/include /usr/local/include /usr/lib/gcc/i686-linux-gnu/4.6/include-fixed /usr/include/i386-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-O0' '-mpreferred-stack-boundary=2' '-fno-stack-protector' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-gnu/4.6/cc1 -fpreprocessed example.i -quiet -dumpbase example.c -mpreferred-stack-boundary=2 -mtune=generic -march=i686 -auxbase example -O0 -Wall -Wextra -version -fno-stack-protector -o example.s GNU C (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (i686-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=63477 GNU C (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (i686-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=63477 Compiler executable checksum: 09c248eab598b9e2acb117da4cdbd785 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-O0' '-mpreferred-stack-boundary=2' '-fno-stack-protector' '-mtune=generic' '-march=i686' as --32 -o example.o example.s COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-O0' '-mpreferred-stack-boundary=2' '-fno-stack-protector' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-gnu/4.6/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -z relro /usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crt1.o /usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crti.o /usr/lib/gcc/i686-linux-gnu/4.6/crtbegin.o -L/usr/lib/gcc/i686-linux-gnu/4.6
[Bug tree-optimization/59417] [4.9 Regression] ICE in determine_value_range, at tree-ssa-loop-niter.c:176
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
The problem is the uninitialized var t in the testcase, with it apparently
the range info weird and inconsistent, but what sanity can one expect from
uninitialized value, any use of it is invalid.
Before *.copyprop5 we have:
# RANGE [1, 2147483647] NONZERO 0x07fff
# t_4 = PHI t_19(D)(3), t_8(23)
(supposedly because we ignore the uninitialized var in some spots).
Then during copyprop5 we copy the range info of t_4 to t_19(D):
else if (!POINTER_TYPE_P (TREE_TYPE (var))
SSA_NAME_RANGE_INFO (var)
!SSA_NAME_RANGE_INFO (copy_of[i].value))
duplicate_ssa_name_range_info (copy_of[i].value,
SSA_NAME_RANGE_TYPE (var),
SSA_NAME_RANGE_INFO (var));
I'm wondering how that can be a safe thing to do, even when not taking into
account undefined vars. If we have say:
if (parm_5(D) 32)
{
do_something_with (parm_5(D));
goto return;
}
somevar_21 = parm_5(D);
and somevar_21 will have range info of [32, +INF] (from VRP ASSERT_EXPRs),
then
I don't see how it can be safe to modify parm_5(D)'s SSA_NAME_RANGE_INFO
(similarly for pointer alignment info though). For this testcase, surely we
could say avoid doing it if the copy_of[i].value SSA_NAME is default def,
but I think it is a general issue. Perhaps points to info can be copied
over, but not alignment info or range info. Maybe we could consider not
doing copyprop or forwprop replacing one SSA_NAME with another one if the
one to be replaced has better range info (or alignment info) and only
copyprop/forwprop if we would replace SSA_NAME with something other than
SSA_NAME?
Yeah, I wondered about this as well after reviewing the original patches.
If you consider
a_2 = a_1;
if (a_2 5)
a_3 = a_2;
then VRP would say a_3 is [6, +INF]. If then copyprop comes along it
sees that a_3 = a_2 = a_1 and would transfer the value-range to a_1.
Note that the loop doing that may replace SSA annotation multiple times
if copy_of[N].value == X for multiple N.
Basically the code relies on the information being not control sensitive.
That's fine for points-to info (but alignment tracking now uses nonzero_bits?),
but for the rest only if var is post-dominated by copy_of[].value's definition.
I don't think we should limit what copyprop/forwprop does though.
Now, why do we arrive at a value-range where we fail that assertion?
Then in tree-ssa-loop-niter.c I can surely instead of assetion failure just
give up on using the range info altogether (rtype = VR_VARYING; break;) or
just using var's range info and nothing else if there is inconsistency
(rtype = get_range_info (var, minv, maxv); break;).
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #14 from Jan Hubicka hubicka at ucw dot cz --- Actually, I would argue that the middle-end should be smart enough to give a branch that is guaranteed to never return a negligible probability (independent of the builtin_expect). It can only be mis-predicted once. For predicting branches, we have gimple predict_stmt. If we need to annotate values with higher probability, I will implement the extension into bulitin_expect to handle them. (i.e. adding internal only second argument specifying the predictor) Sounds sane?
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #15 from Jan Hubicka hubicka at ucw dot cz --- The threshold is ~6000 (exactly 5941), i.e. more than twice the default value 2700. Thanks for working it out. This may be only testcase I know of where large-function-insns brings significant regression. Did you try to experiment with large-stack-frame limits for fortran? Those hit quite commonly, perhaps we miss useful inlining here. I never did really serious tunning on large-function-insns except for quick check that increasing it doesn't affect SPEC scores. But lets fix the underlying branch prediction problem and see if we find another testcase supporting the change. Honza
[Bug lto/58251] [4.7/4.8 Regression] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #16) (In reply to Richard Biener from comment #15) Confirmed with 4.7.3 and 4.8.2. Seems to work on the trunk, worked with 4.6.4. Now it would be interesting to bisect what fixed this on the trunk ... It was fixed by r200151. Bah this means don't hold your breath for a fix. I wonder whether it makes sense to try backporting 4.9 LTO to 4.8 ... (too much fallout in the end I guess).
[Bug testsuite/59442] movapd tests fail if built with -fstack-protector-strong/all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59442 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Please post the patch with ChangeLog entry to gcc-patches@ mailing list.
[Bug c++/59200] ICE with invalid alias template use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59200 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-10 Ever confirmed|0 |1
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 --- Comment #5 from Dmitry G. Dyachenko dimhen at gmail dot com --- (In reply to Jakub Jelinek from comment #4) Strange, can't reproduce. You are using --with-arch=native --with=native, what exactly it expands to? [dimhen@dim PR59350]$ ~/bin/gcc_205461_yes/bin/g++ -v -fpreprocessed -O1 -g -c x.ii -o x.o Using built-in specs. COLLECT_GCC=/home/dimhen/bin/gcc_205461_yes/bin/g++ Target: x86_64-unknown-linux-gnu Configured with: /home/dimhen/src/gcc_current_205461/configure --prefix=/usr/local/gcc_current --with-multilib-list=m64 --enable-checking=yes --enable-languages=c,c++,lto --enable-plugin --with-tune=native --with-arch=native --enable-version-specific-runtime-libs Thread model: posix gcc version 4.9.0 20131127 (experimental) [trunk revision 205461] (GCC) COLLECT_GCC_OPTIONS='-v' '-fpreprocessed' '-O1' '-g' '-c' '-o' 'x.o' '-shared-libgcc' '-mtune=native' '-march=native' /home/dimhen/bin/gcc_205461_yes/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus -fpreprocessed x.ii -march=corei7 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 -quiet -dumpbase x.ii -auxbase-strip x.o -g -O1 -version -fpreprocessed -o /tmp/ccQJHhK6.s GNU C++ (GCC) version 4.9.0 20131127 (experimental) [trunk revision 205461] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.0 20131127 (experimental) [trunk revision 205461], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.9.0 20131127 (experimental) [trunk revision 205461] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.0 20131127 (experimental) [trunk revision 205461], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: e2018620b941388d06d586f5e1499b7d x.ii: In function 'void fn2(C)': x.ii:31:1: internal compiler error: in vt_expand_var_loc_chain, at var-tracking.c:8212 [...]
[Bug target/59444] [4.6.3 32-bit] Character buffers on stack not aligned on a 4-byte boundary.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59444 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- That's not what the option ensures. If you want the buffers to be aligned say so via a aligned(4) attribute.
[Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-10 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug sanitizer/59437] ICE in for g++ -S -fvtable-verify=std -fsanitize=null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59437 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Dec 10 10:49:39 2013 New Revision: 205854 URL: http://gcc.gnu.org/viewcvs?rev=205854root=gccview=rev Log: PR sanitizer/59437 * vtable-verify.c (var_is_used_for_virtual_call_p): Check the return value of gimple_call_fn. Use is_gimple_call/is_gimple_assign instead of gimple_code. testsuite/ * g++.dg/ubsan/pr59437.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr59437.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/vtable-verify.c
[Bug sanitizer/59437] ICE in for g++ -S -fvtable-verify=std -fsanitize=null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59437 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/59445] New: [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 Bug ID: 59445 Summary: [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: amker at gcc dot gnu.org, iains at gcc dot gnu.org Host: x86_64-apple-darwin13 Target: x86_64-apple-darwin13 Build: x86_64-apple-darwin13 Revision 205848 breaks bootstraps on x86_64-apple-darwin13: /opt/gcc/build_w/./gcc/gcj -B/opt/gcc/build_w/x86_64-apple-darwin13.0.0/i386/libjava/ -B/opt/gcc/build_w/x86_64-apple-darwin13.0.0/i386/libjava/ -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.9w/x86_64-apple-darwin13.0.0/bin/ -B/opt/gcc/gcc4.9w/x86_64-apple-darwin13.0.0/lib/ -isystem /opt/gcc/gcc4.9w/x86_64-apple-darwin13.0.0/include -isystem /opt/gcc/gcc4.9w/x86_64-apple-darwin13.0.0/sys-include -m32 -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../work/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m32 -c -fsource-filename=/opt/gcc/build_w/x86_64-apple-darwin13.0.0/i386/libjava/classpath/lib/classes -MT java/awt/image.lo -MD -MP -MF java/awt/image.deps @java/awt/image.list -fno-common -save-temps /opt/gcc/work/libjava/classpath/java/awt/image/SinglePixelPackedSampleModel.java: In class 'java.awt.image.SinglePixelPackedSampleModel': /opt/gcc/work/libjava/classpath/java/awt/image/SinglePixelPackedSampleModel.java: In method 'java.awt.image.SinglePixelPackedSampleModel.getPixels(int,int,int,int,int[],java.awt.image.DataBuffer)': In file included from built-in:3:0: /opt/gcc/work/libjava/classpath/java/awt/image/SinglePixelPackedSampleModel.java:354:0: internal compiler error: in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541 int offset = scanlineStride*y + x; ^ /opt/gcc/work/libjava/classpath/java/awt/image/SinglePixelPackedSampleModel.java:354:0: internal compiler error: Abort trap: 6 gcj: internal compiler error: Abort trap: 6 (program jc1) Abort
[Bug rtl-optimization/59446] New: loop2_doloop creates constant comparison and dead jump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59446
Bug ID: 59446
Summary: loop2_doloop creates constant comparison and dead jump
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
CC: law at redhat dot com
Target: sh*-*-*
After the commit that fixed PR 58640
http://gcc.gnu.org/viewcvs?rev=203463root=gccview=rev
the SH specific test case gcc.target/sh/pr51244-18.c caught the following
sequence:
.L15:
mov#0,r1 // r1 = 0
tstr1,r1 // T = r1 == 0
bf.s.L7// if (T == 0) goto .L7
add#-4,r9
The branch above never happens and is dead code.
Something causes the loop2_doloop RTL pass to create the following code, which
results in the above final code.
(code_label 108 107 109 4 2 [0 uses])
(note 109 108 110 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
.
.
.
(insn 177 176 185 4 (set (reg:SI 304)
(plus:SI (reg:SI 305)
(const_int 1 [0x1]))) -1
(nil))
(note 185 177 180 16 [bb 16] NOTE_INSN_BASIC_BLOCK)
(insn 180 185 182 16 (set (reg:SI 306)
(plus:SI (reg/v:SI 278 [ k ])
(const_int -8 [0xfff8]))) -1
(nil))
(insn 182 180 183 16 (set (reg:SI 307)
(const_int -8 [0xfff8])) -1
(nil))
(insn 183 182 184 16 (set (reg:SI 147 t)
(ge:SI (reg:SI 306)
(reg:SI 307))) -1
(nil))
(jump_insn 184 183 181 16 (set (pc)
(if_then_else (eq (reg:SI 147 t)
(const_int 0 [0]))
(label_ref 181)
(pc))) -1
(int_list:REG_BR_PROB 0 (nil))
- 181)
(code_label 181 184 178 14 10 [1 uses])
(note 178 181 186 14 [bb 14] NOTE_INSN_BASIC_BLOCK)
(insn 186 178 179 14 (set (reg:SI 304)
(const_int 1 [0x1])) -1
(nil))
(note 179 186 155 15 [bb 15] NOTE_INSN_BASIC_BLOCK)
.
.
.
.
.
.
(code_label 149 146 150 9 5 [1 uses])
(note 150 149 151 9 [bb 9] NOTE_INSN_BASIC_BLOCK)
(insn 151 150 152 9 (set (reg/v:SI 261 [ k ])
(plus:SI (reg/v:SI 261 [ k ])
(const_int -8 [0xfff8]))) pr51244-18.c:48 68
{*addsi3_compact}
(nil))
(insn 152 151 175 9 (set (reg:SI 147 t)
(ge:SI (reg/v:SI 261 [ k ])
(const_int 0 [0]))) pr51244-18.c:49 20 {cmpgesi_t}
(nil))
(jump_insn 175 152 174 9 (parallel [
(set (pc)
(if_then_else (ne:SI (reg:SI 304)
(const_int 1 [0x1]))
(label_ref 174)
(pc)))
(set (reg:SI 304)
(plus (reg:SI 304)
(const_int -1 [0x])))
(clobber (reg:SI 147 t))
]) pr51244-18.c:49 -1
(int_list:REG_BR_PROB 9700 (nil))
- 174)
jump_insn 175 is SH's decrement-and-test pattern that is used for loops.
[Bug tree-optimization/58640] [4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58640 --- Comment #15 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #14) Oleg, please open a new bug for the SH problem rather than piggy-backing on this one as they're clearly distinct issues. Sure. I've created PR 59446 for this.
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Still can't reproduce.
[Bug bootstrap/59447] New: --with-dwarf2 is not propagated correctly, will always create dwarf4 by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447 Bug ID: 59447 Summary: --with-dwarf2 is not propagated correctly, will always create dwarf4 by default Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rose.garcia-eggl2fk at yopmail dot com even if one manages that --with-dwarf2 gets properly redirected to gcc/configure from the toplevel configure script ( i used GCC_DWARF_CONFFLAGS=--with-dwarf2=yes ; export host_configargs=$GCC_DWARF_CONFFLAGS ; export target_configargs=$GCC_DWARF_CONFFLAGS ; export build_configargs=$GCC_DWARF_CONFFLAGS ; plus i passed it to top-level configure), gcc will still default to DWARF4, and all created binaries will have dwarf4 debug info, unless -gdwarf-2 was passed explicitly on the command line. the culprit is this line gcc-4.8.2/gcc/common.opt:Common Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs) introduced in commit http://repo.or.cz/w/official-gcc.git/commitdiff/052166fd4a8051c7dc4c87d408be091c99aafd55 note that even the command below still talks about dwarf2. i see nothing in the build system that would fill in the required 2 here instead of the 4, and indeed the generated options.c has dwarf_version = 4 in it.
[Bug fortran/59440] [4.9 Regression] ICE in force_decl_die, at dwarf2out.c:20111 with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59440 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/59448] New: ARM code generation doesn't respect C11 address-dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
Bug ID: 59448
Summary: ARM code generation doesn't respect C11
address-dependency
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: algrant at acm dot org
int f2(int const *p, int const *q)
{
int flag = *p;
return flag ? *(q + flag - flag) : 0;
}
The evaluation *(q + flag - flag) is ordered after *p by 5.1.2.4#14;
writing it this way is a recognized way of forcing the ordering.
AArch64 GCC 4.8 -O2 --std=c11 generates
f2:
ldr w2, [x0]
mov w0, 0
cbz w2, .L2
ldr w0, [x1]
.L2
which doesn't preserve the ordering in the target memory model.
The compiler needs to introduce an address dependency, e.g.
and w2, w2, #0
ldr w0, [x1, w2]
or insert a memory barrier instruction. According to the target
architecture's own rules, this is sufficient to order the loads.
In general, the C source-level address dependency (defined by the
syntactic rules of 5.1.2.4#14) might not involve arithmetic.
For example:
inline int makedep(int flag, ...) { return flag; } // variadic
int f3(int const *p, int const *q) {
int flag = *p;
return flag ? makedep(*q, flag) : 0;
}
An access might even be formally dependent on multiple expressions.
The compiler just has to keep track.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #78 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Dec 10 12:31:39 2013 New Revision: 205857 URL: http://gcc.gnu.org/viewcvs?rev=205857root=gccview=rev Log: 2013-12-10 Richard Biener rguent...@suse.de PR middle-end/38474 * tree-ssa-structalias.c (solution_set_expand): Expand into a different possibly cached bitmap and return the result. (set_union_with_increment): Pass in a shared expanded bitmap and adjust. (do_sd_constraint): Likewise. (do_ds_constraint): Likewise. (do_complex_constraint): Likewise. (solve_graph): Manage the shared expanded bitmap. * gcc.dg/ipa/ipa-pta-14.c: Un-XFAIL. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-14.c trunk/gcc/tree-ssa-structalias.c
[Bug go/59432] [4.9 regression] sync/atomic FAILs on Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #1 from Ian Lance Taylor ian at airs dot com --- FYI, the point of the test is to get that segmentation violation and ensure that the signal handler generates a runtime panic as it should. The actual problem is presumably happening some time later. Thanks for the hint. Investigating further proved a bit difficult: running with -test.run=TestNilDeref under gdb with SEGV just passed on ran for hours without anything happening. Instead, I've run the test with truss -S ABRT (stop on SIGABRT) and got the following stacktrace from an attached gdb: #0 0xfe52c955 in _lwp_kill () from /lib/libc.so.1 #1 0xfe5277d9 in thr_kill () from /lib/libc.so.1 #2 0xfe4d3893 in raise () from /lib/libc.so.1 #3 0xfe4b2988 in abort () from /lib/libc.so.1 #4 0xfe8c36a0 in __go_check_defer (frame=frame@entry=0xde836faf) at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:152 #5 0xfe976e62 in testing.tRunner (test=optimized out, t.param=optimized out) at /vol/gcc/src/hg/trunk/local/libgo/go/testing/testing.go:392 #6 testing.$thunk13 (__go_thunk_parameter=0xde200688) at /vol/gcc/src/hg/trunk/local/libgo/go/testing/testing.go:471 #7 0xfe8d005b in kickoff () at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:229 #8 0xfe4a5ba2 in makecontext () from /lib/libc.so.1 Backtrace stopped: previous frame inner to this frame (corrupt stack?) This might be another instance of problems unwinding through makecontext. Rainer
[Bug tree-optimization/59417] [4.9 Regression] ICE in determine_value_range, at tree-ssa-loop-niter.c:176
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
Yeah, I wondered about this as well after reviewing the original patches.
If you consider
a_2 = a_1;
if (a_2 5)
a_3 = a_2;
then VRP would say a_3 is [6, +INF]. If then copyprop comes along it
sees that a_3 = a_2 = a_1 and would transfer the value-range to a_1.
Note that the loop doing that may replace SSA annotation multiple times
if copy_of[N].value == X for multiple N.
Basically the code relies on the information being not control sensitive.
That's fine for points-to info (but alignment tracking now uses
nonzero_bits?),
but for the rest only if var is post-dominated by copy_of[].value's
definition.
So, shall we drop that code from fini_copy_prop (I mean, don't
duplicate_ssa_name_range_info at all, and for duplicate_ssa_name_ptr_info
do it but clear align/misalign)?
I don't think we should limit what copyprop/forwprop does though.
Does it buy is really that much optimization-wise? I mean, is it that
important
if we have one or another SSA_NAME in the stmt? Propagating of non-SSA_NAME
values is of course important, and if we don't have any better align/misalign
or range info than on the original, we should keep doing what we are.
But if not propagating some SSA_NAME would mean we don't lose important range
info or alignment info, is it worth it?
Now, why do we arrive at a value-range where we fail that assertion?
So, during VRP1 we have a nested loop like:
# t_2 = PHI t_3(5), t_6(20)
lbl1:
d = 0;
a.2_36 = a;
a.3_37 = a.2_36 + 1;
a = a.3_37;
bb 5:
# t_3 = PHI t_19(D)(3), t_2(4)
b.0_39 = b;
if (b.0_39 != 0)
goto bb 4 (lbl1);
else
goto bb 6;
bb 6:
goto bb 11;
...
bb 11:
d.1_40 = d;
if (d.1_40 = 1)
goto bb 7;
else
goto bb 12;
bb 12:
# t_4 = PHI t_19(D)(3), t_3(11)
e ={v} {CLOBBER};
goto bb 19 (lbl2);
...
# t_5 = PHI t_6(20), t_4(12)
lbl2:
t_34 = t_5 + 1;
bb 20:
# t_6 = PHI t_19(D)(18), t_34(19)
if (t_6 = 0)
goto bb 19 (lbl2);
else
goto bb 4 (lbl1);
and VRP1 from this figures out
# RANGE [1, 2147483647] NONZERO 0x07fff
for t_2, t_3 and t_4. The reasoning for it is t_19(D), being VR_UNDEFINED, is
ignored in the PHIs, and loop to bb4 from bb20 (and thus indirectly to say
bb11)
only if t_6 is = 0, therefore used ASSERT_EXPR of t_6 0. I think this isn't
wrong, we are just assuming undefined-behavior doesn't happen.
Then copyprop6 apparently comes and changes:
# RANGE [1, 2147483647] NONZERO 0x07fff
- # t_4 = PHI t_19(D)(3)
+ t_4 = t_19(D);
and because of the code we're discussing propagates the [1, INT_MAX] range to
t_19(D) as well.
Then VRP2 sees:
# t_5 = PHI t_34(17), t_19(D)(11)
lbl2:
t_34 = t_5 + 1;
if (t_34 = 0)
goto bb 17 (lbl2);
else
goto bb 18 (lbl1);
VRP right now ignores the SSA_NAME_RANGE_INFO stuff (to be handled later?),
ignores as usually VR_UNDEFINED in phis and here the loop loops if t_34 = 0,
thus VRP2 derives range [INT_MIN, 0] out of it. So, what niters then sees
is that t_19(D) has [0, INT_MAX] range and t_5 has [INT_MIN, 0] range and is
upset about it.
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 --- Comment #8 from Dmitry G. Dyachenko dimhen at gmail dot com --- (In reply to Jakub Jelinek from comment #6) Still can't reproduce. PASS /home/dimhen/bin/gcc_205461_yes/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus -fpreprocessed x.ii -march=corei7 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 -quiet -dumpbase x.ii -auxbase-strip x.o -g -O1 -version -fpreprocessed -o /tmp/ccbEj5NK.s FAIL prev.cmd -march=corei7 -mtune=corei7 valgrind --tool=memcheck --track-origins=yes /home/dimhen/bin/gcc_205461_yes/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus -fpreprocessed x.ii -march=corei7 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 -quiet -dumpbase x.ii -auxbase-strip x.o -g -O1 -version -fpreprocessed -o /tmp/ccbEj5NK.s [...] ==575== Conditional jump or move depends on uninitialised value(s) ==575==at 0x1047E6E: register_active_defs(df_ref_d**) (sparseset.h:147) ==575==by 0x1047F02: update_df_init(rtx_def*, rtx_def*) [clone .isra.14] (fwprop.c:892) ==575==by 0x599FD3: try_fwprop_subst(df_ref_d*, rtx_def**, rtx_def*, rtx_def*, bool) (fwprop.c:960) ==575==by 0x10489E3: forward_propagate_into(df_ref_d*) (fwprop.c:1340) ==575==by 0x10490B7: (anonymous namespace)::pass_rtl_fwprop::execute() (fwprop.c:1477) ==575==by 0xAF9149: execute_one_pass(opt_pass*) (passes.c:2215) ==575==by 0xAF93F5: execute_pass_list(opt_pass*) (passes.c:2268) ==575==by 0xAF9407: execute_pass_list(opt_pass*) (passes.c:2269) ==575==by 0x88B058: expand_function(cgraph_node*) (cgraphunit.c:1763) ==575==by 0x88D05F: compile() (cgraphunit.c:1868) ==575==by 0x88D6B4: finalize_compilation_unit() (cgraphunit.c:2280) ==575==by 0x6893A6: cp_write_global_declarations() (decl2.c:4431) ==575== Uninitialised value was created by a heap allocation ==575==at 0x4A06B2D: malloc (vg_replace_malloc.c:291) ==575==by 0x1163187: xmalloc (xmalloc.c:147) ==575==by 0xB8CEA4: sparseset_alloc(unsigned long) (sparseset.c:33) ==575==by 0x1047932: fwprop_init() (fwprop.c:1421) ==575==by 0x104902A: (anonymous namespace)::pass_rtl_fwprop::execute() (fwprop.c:1461) ==575==by 0xAF9149: execute_one_pass(opt_pass*) (passes.c:2215) ==575==by 0xAF93F5: execute_pass_list(opt_pass*) (passes.c:2268) ==575==by 0xAF9407: execute_pass_list(opt_pass*) (passes.c:2269) ==575==by 0x88B058: expand_function(cgraph_node*) (cgraphunit.c:1763) ==575==by 0x88D05F: compile() (cgraphunit.c:1868) ==575==by 0x88D6B4: finalize_compilation_unit() (cgraphunit.c:2280) ==575==by 0x6893A6: cp_write_global_declarations() (decl2.c:4431) [..] ERROR SUMMARY: 130 errors from 38 contexts (suppressed: 0 from 0)
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 --- Comment #7 from Dmitry G. Dyachenko dimhen at gmail dot com --- Created attachment 31409 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31409action=edit valgrind' log
[Bug web/59449] New: Missing online documentation web pages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59449 Bug ID: 59449 Summary: Missing online documentation web pages Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: otmar.struwe at web dot de The below pages are not available http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/IA-64-Options.html#IA-64-Options http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Windows-Options.html#i386-and-x86-64-Windows-Options
[Bug go/59433] [4.9 regression] Many 64-bit Go tests SEGV on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59433 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- I've found what's going on: when I look at the failing bufio test, gdb prints gdb) p rfds Cannot access memory at address 0xfd7ffe0f9f00 With pmap, I see the following mappings: FD7FFDE0 2048K rw---[ anon ] FD7FFE101000 4K rw--R[ stack tid=2 ] FD7FFE11 64K rw---[ anon ] I.e. the thread stack starts off with just 4 kB, but rfds is 0x7100 bytes from the top of the stack, way beyond the initial allocation and thus unmapped. Each fd_set is 8 kB for 64-bit, so the stack consumption in netpoll_select.c (runtime_netpoll) is way out of bounds. As a quick hack, I've increased the initial stack size to StackMin: diff --git a/libgo/runtime/proc.c b/libgo/runtime/proc.c --- a/libgo/runtime/proc.c +++ b/libgo/runtime/proc.c @@ -185,7 +185,7 @@ runtime_newosproc(M *mp) if(pthread_attr_setdetachstate(attr, PTHREAD_CREATE_DETACHED) != 0) runtime_throw(pthread_attr_setdetachstate); -stacksize = PTHREAD_STACK_MIN; +stacksize = StackMin /* PTHREAD_STACK_MIN */; // With glibc before version 2.16 the static TLS size is taken // out of the stack size, and we get an error or a crash if which lets all but os/user PASS on i386-pc-solaris2.10 and sparc-sun-solaris2.11. Rainer
[Bug c/59448] Code generation doesn't respect C11 address-dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target||arm Component|target |c Summary|ARM code generation doesn't |Code generation doesn't |respect C11 |respect C11 |address-dependency |address-dependency --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org --- I suspect this will affect any target with relaxed HW ordering of loads.
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 --- Comment #9 from Ryan Mansfield rmansfield at qnx dot com --- Created attachment 31410 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31410action=edit arm-eabi testcase I haven't been able to reproduce with the inline testcase either. But I can still consistently repoduce ICE with the attached testcase (not fully reduced) gcc version 4.9.0 20131207 (experimental) [trunk revision 205782] (GCC) ~/gnu/gcc/trunk/arm-eabi/gcc$ ./xgcc -B. -Os ~/ice.i -c -g /home/ryan/ice.i: In function 'uDNS_ReceiveMsg': /home/ryan/ice.i:80:1: internal compiler error: in vt_expand_var_loc_chain, at var-tracking.c:8212 } ^ 0xbb0353 vt_expand_var_loc_chain ../../gcc/var-tracking.c:8212 0xbb0353 vt_expand_loc_callback ../../gcc/var-tracking.c:8408 0x64cef7 cselib_expand_value_rtx_1 ../../gcc/cselib.c:1684 0x64e31e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def* (*)(rtx_def*, bitmap_head_def*, int, void*), void*) ../../gcc/cselib.c:1531 0xbaf77a vt_expand_loc_callback ../../gcc/var-tracking.c:8344 0x64ce31 cselib_expand_value_rtx_1 ../../gcc/cselib.c:1649 0x64e31e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def* (*)(rtx_def*, bitmap_head_def*, int, void*), void*) ../../gcc/cselib.c:1531 0xbafc28 vt_expand_var_loc_chain ../../gcc/var-tracking.c:8246 0xbafc28 vt_expand_loc_callback ../../gcc/var-tracking.c:8408 0x64cef7 cselib_expand_value_rtx_1 ../../gcc/cselib.c:1684 0x64e31e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def* (*)(rtx_def*, bitmap_head_def*, int, void*), void*) ../../gcc/cselib.c:1531 0xba941c vt_expand_loc ../../gcc/var-tracking.c:8498 0xbbc0c3 emit_notes_in_bb ../../gcc/var-tracking.c:9094 0xbbc0c3 vt_emit_notes ../../gcc/var-tracking.c:9431 0xbbcb91 variable_tracking_main_1 ../../gcc/var-tracking.c:10292 0xbbcb91 variable_tracking_main ../../gcc/var-tracking.c:10306 0xbbcb91 execute ../../gcc/var-tracking.c:10347 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.
[Bug tree-optimization/59417] [4.9 Regression] ICE in determine_value_range, at tree-ssa-loop-niter.c:176
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417
--- Comment #5 from rguenther at suse dot de rguenther at suse dot de ---
On Tue, 10 Dec 2013, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
Yeah, I wondered about this as well after reviewing the original patches.
If you consider
a_2 = a_1;
if (a_2 5)
a_3 = a_2;
then VRP would say a_3 is [6, +INF]. If then copyprop comes along it
sees that a_3 = a_2 = a_1 and would transfer the value-range to a_1.
Note that the loop doing that may replace SSA annotation multiple times
if copy_of[N].value == X for multiple N.
Basically the code relies on the information being not control sensitive.
That's fine for points-to info (but alignment tracking now uses
nonzero_bits?),
but for the rest only if var is post-dominated by copy_of[].value's
definition.
So, shall we drop that code from fini_copy_prop (I mean, don't
duplicate_ssa_name_range_info at all, and for duplicate_ssa_name_ptr_info
do it but clear align/misalign)?
Yes, I think we have to :/
I don't think we should limit what copyprop/forwprop does though.
Does it buy is really that much optimization-wise? I mean, is it that
important
if we have one or another SSA_NAME in the stmt? Propagating of non-SSA_NAME
values is of course important, and if we don't have any better align/misalign
or range info than on the original, we should keep doing what we are.
But if not propagating some SSA_NAME would mean we don't lose important range
info or alignment info, is it worth it?
Well, passes still assume copy-proped IL when doing pattern matching
so yes, it matters (but only because of that). If they cannot rely
on this then this also is a compile-time issue (basically re-doing
copy-prop at pattern matching time).
But we can also be more careful which range/alignment info we substitute
and not remove it all.
Now, why do we arrive at a value-range where we fail that assertion?
So, during VRP1 we have a nested loop like:
# t_2 = PHI t_3(5), t_6(20)
lbl1:
d = 0;
a.2_36 = a;
a.3_37 = a.2_36 + 1;
a = a.3_37;
bb 5:
# t_3 = PHI t_19(D)(3), t_2(4)
b.0_39 = b;
if (b.0_39 != 0)
goto bb 4 (lbl1);
else
goto bb 6;
bb 6:
goto bb 11;
...
bb 11:
d.1_40 = d;
if (d.1_40 = 1)
goto bb 7;
else
goto bb 12;
bb 12:
# t_4 = PHI t_19(D)(3), t_3(11)
e ={v} {CLOBBER};
goto bb 19 (lbl2);
...
# t_5 = PHI t_6(20), t_4(12)
lbl2:
t_34 = t_5 + 1;
bb 20:
# t_6 = PHI t_19(D)(18), t_34(19)
if (t_6 = 0)
goto bb 19 (lbl2);
else
goto bb 4 (lbl1);
and VRP1 from this figures out
# RANGE [1, 2147483647] NONZERO 0x07fff
for t_2, t_3 and t_4. The reasoning for it is t_19(D), being VR_UNDEFINED, is
ignored in the PHIs, and loop to bb4 from bb20 (and thus indirectly to say
bb11)
only if t_6 is = 0, therefore used ASSERT_EXPR of t_6 0. I think this
isn't
wrong, we are just assuming undefined-behavior doesn't happen.
Then copyprop6 apparently comes and changes:
# RANGE [1, 2147483647] NONZERO 0x07fff
- # t_4 = PHI t_19(D)(3)
+ t_4 = t_19(D);
and because of the code we're discussing propagates the [1, INT_MAX] range to
t_19(D) as well.
Then VRP2 sees:
# t_5 = PHI t_34(17), t_19(D)(11)
lbl2:
t_34 = t_5 + 1;
if (t_34 = 0)
goto bb 17 (lbl2);
else
goto bb 18 (lbl1);
VRP right now ignores the SSA_NAME_RANGE_INFO stuff (to be handled later?),
ignores as usually VR_UNDEFINED in phis and here the loop loops if t_34 = 0,
thus VRP2 derives range [INT_MIN, 0] out of it. So, what niters then sees
is that t_19(D) has [0, INT_MAX] range and t_5 has [INT_MIN, 0] range and is
upset about it.
Ah, ok - I thought we'd have an SSA name with bogus range info but we
just have two SSA names with range info that don't agree in a way
that niter likes. That should be fixed in niter.
Richard.
[Bug fortran/59450] New: ICE for Array Valued Function combined with Deferred Specification Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 Bug ID: 59450 Summary: ICE for Array Valued Function combined with Deferred Specification Function Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: b...@miller-mohr.de Hi, when I try to compile the code below I receive an internal compiler error. The idea of the test case is to have a base class with a type-bound procedure returning an array. The size of the array is determined by using a specification function with deferred binding, i.e. it will be implemented in a child class / extended derived type. When I use a component of the base class instead of the specification function the code compiles without problems. module classes implicit none type, abstract :: base_class integer :: varnum contains procedure(pvf_get_num), nopass, deferred :: get_num procedure :: get_array end type base_class abstract interface pure function pvf_get_num() result(num) integer :: num end function pvf_get_num end interface contains function get_array( this ) result(array) class(base_class), intent(in) :: this ! compiles ! integer, dimension( this%varnum ) :: array ! crashes integer, dimension( this%get_num() ) :: array array = 0 array(1) = 1 end function get_array end module classes In detail I obtain the following Driving: gfortran -v --save-temps gcc-test2.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/lrz/mnt/sys.x86_64/compilers/gcc/4.8.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.2/configure --prefix=/lrz/sys/compilers/gcc/4.8.2 --enable-languages=ada,c,c++,fortran,java,go,objc,obj-c++ --with-mpfr=/lrz/sys/libraries/mpfr/3.0.0 --with-gmp=/lrz/sys/libraries/gmp/5.0.1 --with-mpc=/lrz/sys/libraries/mpc/0.9 Thread model: posix gcc version 4.8.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /lrz/mnt/sys.x86_64/compilers/gcc/4.8.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/f951 gcc-test2.f90 -quiet -dumpbase gcc-test2.f90 -mtune=generic -march=x86-64 -auxbase gcc-test2 -version -fintrinsic-modules-path /lrz/mnt/sys.x86_64/compilers/gcc/4.8.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/finclude -o gcc-test2.s GNU Fortran (GCC) version 4.8.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.8.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 f951: internal compiler error: Segmentation fault 0x87f55f crash_signal ../../gcc-4.8.2/gcc/toplev.c:332 0x55971e mio_expr ../../gcc-4.8.2/gcc/fortran/module.c:3300 0x559d68 mio_array_spec ../../gcc-4.8.2/gcc/fortran/module.c:2406 0x559e8f mio_component ../../gcc-4.8.2/gcc/fortran/module.c:2596 0x55a11a mio_component_list ../../gcc-4.8.2/gcc/fortran/module.c:2624 0x55a11a mio_symbol ../../gcc-4.8.2/gcc/fortran/module.c:3816 0x55a442 write_symbol ../../gcc-4.8.2/gcc/fortran/module.c:5090 0x55a58d write_symbol0 ../../gcc-4.8.2/gcc/fortran/module.c:5130 0x55a535 write_symbol0 ../../gcc-4.8.2/gcc/fortran/module.c:5109 0x55a535 write_symbol0 ../../gcc-4.8.2/gcc/fortran/module.c:5109 0x55a535 write_symbol0 ../../gcc-4.8.2/gcc/fortran/module.c:5109 0x55caa7 write_module ../../gcc-4.8.2/gcc/fortran/module.c:5396 0x55caa7 gfc_dump_module(char const*, int) ../../gcc-4.8.2/gcc/fortran/module.c:5534 0x56844a gfc_parse_file() ../../gcc-4.8.2/gcc/fortran/parse.c:4623 0x5a3c05 gfc_be_parse_file ../../gcc-4.8.2/gcc/fortran/f95-lang.c:189 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. Compiling the same source with 4.7.1 (on another system) I do not receive an ICE, but instead get error reports that the specification functions wouldn't be pure Using built-in specs. COLLECT_GCC=gfortran-4.7.1 Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix /home/SOFTWARE/GCC/gcc-4.7.1 --program-suffix=-4.7.1 --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran Thread model: posix gcc version 4.7.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-save-temps' '-mtune=generic' '-march=x86-64' /home/SOFTWARE/GCC/gcc-4.7.1/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/f951
[Bug c/59451] New: The compiler does not accept two structures, when the first one of them have the same name as the structure, as function parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59451
Bug ID: 59451
Summary: The compiler does not accept two structures, when the
first one of them have the same name as the structure,
as function parameters
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drausiorossi at hotmail dot com
typedef struct
{
int Time_Execution;
int Period;
int Deadline;
} Task_Data;
1 - doesn´t work:
1 - void Copy_Tasks_Sort(Task_Data Task_Data[], Task_Data Task_Data_Sort[])
2 - work
2 - void Copy_Tasks_Sort(Task_Data Task_Data_Original[], Task_Data
Task_Data_Sort[])
[Bug go/59452] New: net FAILs on Solaris 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59452 Bug ID: 59452 Summary: net FAILs on Solaris 9 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org Host: *-*-solaris2.9 Target: *-*-solaris2.9 Build: *-*-solaris2.9 The libgo net test FAILs on Solaris 9: --- FAIL: TestDialDualStackLocalhost (0.00 seconds) dial_test.go:518: LookupIP failed: lookup localhost: invalid ai_flags FAIL FAIL: net Checking the Solaris 9 sources, I found that getaddrinfo sets EAI_BADFLAGS if ai_flags contains anything but AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST| AI_ADDRCONFIG, thus AI_V4MAPPED | AI_ALL break the test. This changed in Solaris 10/11, so it's unclear how best to solve it, or just ignore the failure given that Solaris 9 support will be removed after GCC 4.9. Rainer
[Bug go/59452] net FAILs on Solaris 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59452 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug go/59453] New: log/syslog FAILs on Solaris 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59453 Bug ID: 59453 Summary: log/syslog FAILs on Solaris 9 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org Host: *-*-solaris2.9 Target: *-*-solaris2.9 Build: *-*-solaris2.9 The libgo log/syslog test FAILs on Solaris 9: --- FAIL: TestConcurrentReconnect (0.24 seconds) syslog_test.go:336: syslog.Dial() failed: dial unix /tmp/syslogtest27399 3343: connection refused syslog_test.go:336: syslog.Dial() failed: dial unix /tmp/syslogtest27399 3343: connection refused FAIL FAIL: log/syslog Running just that test individually in a loop just works. Running the test under truss with all tests shows: /5: AF_UNIX name = /tmp/syslogtest295446496 /5: unlink(/tmp/syslogtest295446496) = 0 /5: AF_UNIX name = /tmp/syslogtest295446496 /4: unlink(/tmp/syslogtest295446496) Err#2 ENOENT /4: rmdir(/tmp/syslogtest295446496) Err#2 ENOENT so the socket is indeed removed before the connect *in the same thread*. No idea why this doesn't trigger on Solaris 10+. Rainer
[Bug go/59453] log/syslog FAILs on Solaris 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59453 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug sanitizer/59454] New: blacklisting sanitized functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 Bug ID: 59454 Summary: blacklisting sanitized functions Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Currently there is no option to 'blacklist' functions from sanitization(?) in Fortran. Would be useful to have. For discussion: see thread at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00640.html
[Bug fortran/59450] [OOP] ICE for Array Valued Function combined with Deferred Specification Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-10 CC||janus at gcc dot gnu.org Summary|ICE for Array Valued|[OOP] ICE for Array Valued |Function combined with |Function combined with |Deferred Specification |Deferred Specification |Function|Function Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. Thanks for the bug report. Here is a variant with a non-abstract class which shows the same ICE (with every version I tried - from 4.6 to trunk): module classes implicit none type :: base_class contains procedure, nopass :: get_num end type contains pure integer function get_num() end function function get_array( this ) result(array) class(base_class), intent(in) :: this integer, dimension( this%get_num() ) :: array end function end module
[Bug java/59455] New: gcj ICEs at r205857 during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59455 Bug ID: 59455 Summary: gcj ICEs at r205857 during bootstrap Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu Current gcc trunk at r205857 fails to bootstrap on x86_64-apple-darwin12 using... ../gcc-4.9-20131210/configure --prefix=/sw --prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.9/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9 The failures occurs when the gcj built is used at... Making all in classpath Making all in lib true top_builddir=.. top_srcdir=../../../../../../gcc-4.9-20131210/libjava/classpath /bin/sh ./gen-classlist.sh standard Adding java source files from srcdir '/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131210/libjava/classpath'. Adding java source files from VM directory /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131210/libjava Adding java source files from VM directory /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava Adding generated files in builddir '..'. make[6]: Nothing to be done for `all'. Making all in doc Making all in api make[7]: Nothing to be done for `all'. make[7]: Nothing to be done for `all-am'. Making all in external Making all in sax make[7]: Nothing to be done for `all'. Making all in w3c_dom make[7]: Nothing to be done for `all'. Making all in relaxngDatatype make[7]: Nothing to be done for `all'. Making all in jsr166 make[7]: Nothing to be done for `all'. make[7]: Nothing to be done for `all-am'. Making all in include make all-am make[7]: Nothing to be done for `all-am'. Making all in native Making all in fdlibm make[7]: Nothing to be done for `all'. Making all in jni Making all in classpath make[8]: Nothing to be done for `all'. /bin/sh ../../scripts/check_jni_methods.sh make[7]: Nothing to be done for `all-am'. Making all in resource make[6]: Nothing to be done for `all'. Making all in scripts make[6]: Nothing to be done for `all'. Making all in tools Makefile:840: warning: overriding commands for target `gjdoc' Makefile:758: warning: ignoring old commands for target `gjdoc' make all-am Makefile:840: warning: overriding commands for target `gjdoc' Makefile:758: warning: ignoring old commands for target `gjdoc' make[7]: Nothing to be done for `all-am'. true DO=all multi-do # make Making all in testsuite make[5]: Nothing to be done for `all'. /bin/sh ./libtool --tag=GCJ --mode=compile /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/gcj -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/ -B/sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/bin/ -B/sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/lib/ -isystem /sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/include -isystem /sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/sys-include -m32 -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../gcc-4.9-20131210/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m32 -c -o java/awt/image.lo -fsource-filename=/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/classpath/lib/classes -MT java/awt/image.lo -MD -MP -MF java/awt/image.deps @java/awt/image.list libtool: compile: /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/gcj -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/ -B/sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/bin/ -B/sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/lib/ -isystem /sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/include -isystem /sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/sys-include -m32 -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../gcc-4.9-20131210/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m32 -c -fsource-filename=/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/classpath/lib/classes -MT java/awt/image.lo -MD -MP -MF java/awt/image.deps @java/awt/image.list -fno-common -o java/awt/.libs/image.o /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131210/libjava/classpath/java/awt/image/SinglePixelPackedSampleModel.java: In class 'java.awt.image.SinglePixelPackedSampleModel': /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 59455 has been marked as a duplicate of this bug. ***
[Bug java/59455] gcj ICEs at r205857 during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59455 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Duplicate of pr59445. Still present at revision 205857. *** This bug has been marked as a duplicate of bug 59445 ***
[Bug fortran/59450] [OOP] ICE for Array Valued Function combined with Deferred Specification Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450
--- Comment #2 from janus at gcc dot gnu.org ---
Draft patch which fixes the error (not regtested):
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 205857)
+++ gcc/fortran/module.c(working copy)
@@ -3358,12 +3358,24 @@ mio_expr (gfc_expr **ep)
{
e-value.function.name
= mio_allocated_string (e-value.function.name);
- flag = e-value.function.esym != NULL;
+ if (e-value.function.esym)
+flag = 1;
+ else if (e-ref)
+flag = 2;
+ else
+flag = 0;
mio_integer (flag);
- if (flag)
-mio_symbol_ref (e-value.function.esym);
- else
-write_atom (ATOM_STRING, e-value.function.isym-name);
+ switch (flag)
+{
+case 1:
+ mio_symbol_ref (e-value.function.esym);
+ break;
+case 2:
+ mio_ref_list (e-ref);
+ break;
+default:
+ write_atom (ATOM_STRING, e-value.function.isym-name);
+}
}
else
{
@@ -3372,10 +3384,15 @@ mio_expr (gfc_expr **ep)
free (atom_string);
mio_integer (flag);
- if (flag)
-mio_symbol_ref (e-value.function.esym);
- else
+ switch (flag)
{
+case 1:
+ mio_symbol_ref (e-value.function.esym);
+ break;
+case 2:
+ mio_ref_list (e-ref);
+ break;
+default:
require_atom (ATOM_STRING);
e-value.function.isym = gfc_find_function (atom_string);
free (atom_string);
[Bug fortran/59450] [OOP] ICE for Array Valued Function combined with Deferred Specification Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 --- Comment #3 from janus at gcc dot gnu.org --- Additional problem (unrelated to the ICE): Removing 'pure' in comment 1 yields the error: integer, dimension( this%get_num() ) :: array 1 Error: Function 'this' at (1) must be PURE An error about missing pureness is correct in principle, but there are two problems with this: 1) The function name in the error message is wrong: There is no function named 'this'. 2) The error appears twice.
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-10 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Please add -v to gcj to show what options are passed to jc1
[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807 --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Tue Dec 10 16:36:53 2013 New Revision: 205860 URL: http://gcc.gnu.org/viewcvs?rev=205860root=gccview=rev Log: PR target/56807 * config/i386/i386.c (ix86_expand_prologue): Address saved registers stack-relative, not via frame-pointer. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807 --- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Tue Dec 10 16:40:36 2013 New Revision: 205861 URL: http://gcc.gnu.org/viewcvs?rev=205861root=gccview=rev Log: PR target/56807 * config/i386/i386.c (ix86_expand_prologue): Address saved registers stack-relative, not via frame-pointer. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu --- /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/jc1 /var/tmp//ccSlyCZfjx -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase ccSlyCZfjx -mmacosx-version-min=10.8.5 -m32 -mtune=generic -auxbase-strip java/awt/.libs/image.o -g -O2 -Wno-deprecated -version -ffilelist-file -ffloat-store -fomit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/classpath/lib/classes -fno-common -fbootclasspath=./:../../../../gcc-4.9-20131210/libjava/classpath/lib/ -faux-classpath ccSlyCZfjx.zip -MD_ -MT java/awt/image.lo -MF java/awt/image.deps -o ccSlyCZfjx.s
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Jack Howarth from comment #3) /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/jc1 /var/tmp//ccSlyCZfjx -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase ccSlyCZfjx -mmacosx-version-min=10.8.5 -m32 -mtune=generic -auxbase-strip java/awt/.libs/image.o -g -O2 -Wno-deprecated -version -ffilelist-file -ffloat-store -fomit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64- apple-darwin12.5.0/i386/libjava/classpath/lib/classes -fno-common -fbootclasspath=./:../../../../gcc-4.9-20131210/libjava/classpath/lib/ -faux-classpath ccSlyCZfjx.zip -MD_ -MT java/awt/image.lo -MF java/awt/image.deps -o ccSlyCZfjx.s opps, that actually was -mtune=core2 but -mtune=generic also segfaults jc1.
[Bug c/59448] Code generation doesn't respect C11 address-dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #2 from algrant at acm dot org ---
Just realised that that last example is bogus, it should read:
inline int const *makedep(int const *a, ...) { return a; } // variadic
int f3(int const *p, int const *q) {
int flag = *p;
return flag ? *makedep(q, flag) : 0;
}
In C++, makedep could be a template - the counterpart of kill_dependency.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #28 from John David Anglin danglin at gcc dot gnu.org --- Bootstrap is also broken on fairly old arm box: libtool: compile: /home/dave/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/home/d ave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/armv5tejl-unkno wn-linux-gnueabi/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/armv5tejl-unknown- linux-gnueabi/libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir/armv5tejl-unkno wn-linux-gnueabi/libstdc++-v3/libsupc++/.libs -B/home/dave/opt/gnu/gcc/gcc-4.9/a rmv5tejl-unknown-linux-gnueabi/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.9/armv5tejl-u nknown-linux-gnueabi/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.9/armv5tejl-unkn own-linux-gnueabi/include -isystem /home/dave/opt/gnu/gcc/gcc-4.9/armv5tejl-unkn own-linux-gnueabi/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc/libsanitizer/sa nitizer_common -I ../../../../gcc/libsanitizer/include -Wall -W -Wno-unused-para meter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exception s -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variad ic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/armv5tejl-unknown-linux-gnueabi -I../../../../gcc/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -MT sanitizer_platform_limits_linux.lo -MD -MP -MF .deps/sanitizer_platform_limits_linux.Tpo -c ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc -fPIC -DPIC -o .libs/sanitizer_platform_limits_linux.o ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:58:30: fatal error: linux/perf_event.h: No such file or directory #include linux/perf_event.h
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #29 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to John David Anglin from comment #28) Bootstrap is also broken on fairly old arm box: libtool: compile: /home/dave/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/home/d ave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/armv5tejl-unkno wn-linux-gnueabi/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/armv5tejl-unknown- linux-gnueabi/libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir/armv5tejl-unkno wn-linux-gnueabi/libstdc++-v3/libsupc++/.libs -B/home/dave/opt/gnu/gcc/gcc-4.9/a rmv5tejl-unknown-linux-gnueabi/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.9/armv5tejl-u nknown-linux-gnueabi/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.9/armv5tejl-unkn own-linux-gnueabi/include -isystem /home/dave/opt/gnu/gcc/gcc-4.9/armv5tejl-unkn own-linux-gnueabi/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc/libsanitizer/sa nitizer_common -I ../../../../gcc/libsanitizer/include -Wall -W -Wno-unused-para meter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exception s -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variad ic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/armv5tejl-unknown-linux-gnueabi -I../../../../gcc/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -MT sanitizer_platform_limits_linux.lo -MD -MP -MF .deps/sanitizer_platform_limits_linux.Tpo -c ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_platform_limits_linux.cc -fPIC -DPIC -o .libs/sanitizer_platform_limits_linux.o ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_platform_limits_linux.cc:58:30: fatal error: linux/perf_event.h: No such file or directory #include linux/perf_event.h For that a patch has been posted, just not reviewed: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00963.html As for hppa, the change to enable it isn't in upstream GCC, so you as a maintainer need to make it working first and if changes are needed for compiler-rt maintained code, make sure it is accepted there first too.
[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807 --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Tue Dec 10 16:52:23 2013 New Revision: 205864 URL: http://gcc.gnu.org/viewcvs?rev=205864root=gccview=rev Log: PR target/56807 * config/i386/i386.c (ix86_expand_prologue): Address saved registers stack-relative, not via frame-pointer. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/i386.c
[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org --- Fixed on all active branches
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jack Howarth from comment #4) (In reply to Jack Howarth from comment #3) /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/jc1 /var/tmp//ccSlyCZfjx -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase ccSlyCZfjx -mmacosx-version-min=10.8.5 -m32 -mtune=generic -auxbase-strip java/awt/.libs/image.o -g -O2 -Wno-deprecated -version -ffilelist-file -ffloat-store -fomit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64- apple-darwin12.5.0/i386/libjava/classpath/lib/classes -fno-common -fbootclasspath=./:../../../../gcc-4.9-20131210/libjava/classpath/lib/ -faux-classpath ccSlyCZfjx.zip -MD_ -MT java/awt/image.lo -MF java/awt/image.deps -o ccSlyCZfjx.s opps, that actually was -mtune=core2 but -mtune=generic also segfaults jc1. What is the equivalent of -march=?
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350
--- Comment #10 from Dmitry G. Dyachenko dimhen at gmail dot com ---
(In reply to Dmitry G. Dyachenko from comment #8)
valgrind' messages looks unrelated to ICE.
I rebuild r205461 with memset(set, {0,0x42}, n_bytes) instead of
VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (set, n_bytes))
in sparseset.c::sparseset_alloc() without luck.
But I see one strangeness: according to /proc/cpuinfo I have Intel(R) Core
i5/760. Gcc is build with arch/tune=native, but while running selects
tune/arch=i7.
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- What is the equivalent of -march=? I configure with --with-arch=corei7 --with-cpu=corei7.
[Bug tree-optimization/59386] [4.9 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59386 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31411 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31411action=edit gcc49-pr59386.patch Untested fix.
[Bug tree-optimization/59417] [4.9 Regression] ICE in determine_value_range, at tree-ssa-loop-niter.c:176
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-10 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31412 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31412action=edit gcc49-pr59417.patch Untested fix.
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 --- Comment #11 from Dmitry G. Dyachenko dimhen at gmail dot com --- (In reply to Ryan Mansfield from comment #9) Created attachment 31410 [details] arm-eabi testcase I haven't been able to reproduce with the inline testcase either. But I can still consistently repoduce ICE with the attached testcase (not fully reduced) PASS for me (x86_64) as '-Os -g' and '-O3 -g' for some versions in [202775..205759]
[Bug bootstrap/59447] --with-dwarf2 is not propagated correctly, will always create dwarf4 by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- This is a documentation bug - the installation manual should make clear that DWARF 2 in the description of this option means DWARF 2 or later, as appropriate for the target, as opposed to (for example) STABS.
[Bug sanitizer/59456] New: libsanitizer can't bootstrap on darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59456 Bug ID: 59456 Summary: libsanitizer can't bootstrap on darwin10 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org The bootstrap of current gcc trunk on x86_64-apple-darwin10 fails with... /bin/sh ../libtool --tag=CXX --mode=compile /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -B/sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/bin/ -B/sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/lib/ -isystem /sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/include -isystem /sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/sys-include-D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc-4.9-20131210/libsanitizer/sanitizer_common -I ../../../../gcc-4.9-20131210/libsanitizer/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I../../../../gcc-4.9-20131210/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -MT sanitizer_platform_limits_posix.lo -MD -MP -MF .deps/sanitizer_platform_limits_posix.Tpo -c -o sanitizer_platform_limits_posix.lo ../../../../gcc-4.9-20131210/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc libtool: compile: /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -B/sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/bin/ -B/sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/lib/ -isystem /sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/include -isystem /sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc-4.9-20131210/libsanitizer/sanitizer_common -I ../../../../gcc-4.9-20131210/libsanitizer/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I../../../../gcc-4.9-20131210/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -MT sanitizer_platform_limits_posix.lo -MD -MP -MF .deps/sanitizer_platform_limits_posix.Tpo -c ../../../../gcc-4.9-20131210/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc -fno-common -DPIC -o .libs/sanitizer_platform_limits_posix.o ../../../../gcc-4.9-20131210/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:763:39: error: ‘EOWNERDEAD’ was not declared in this scope extern const int errno_EOWNERDEAD = EOWNERDEAD; ^ make[4]: *** [sanitizer_platform_limits_posix.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-stage1-target-libsanitizer] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 using Xcode 4.2 and... ../gcc-4.9-20131210/configure --prefix=/sw --prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.9/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #30 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 59456 has been marked as a duplicate of this bug. ***
[Bug sanitizer/59456] libsanitizer can't bootstrap on darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59456 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- See pr59009 comment 23. *** This bug has been marked as a duplicate of bug 59009 ***
[Bug c/59448] Code generation doesn't respect C11 address-dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- The code generated appears fully in accordance with the semantics of C11. You refer to 5.1.2.4#14, the definition of carries a dependency. The term carries a dependency is used outside its own definition only in the definition of dependency-ordered before. This testcase contains no instances of dependency-ordered before, because any such instance must directly or indirectly involve a case of A performs a release operation on an atomic object M, and, in another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A, and the test involves no atomic objects. dependency-ordered before, in turn, is only used in the definition of inter-thread happens before, which is only used in the definition of happens before. Please provide a complete testcase, using _Atomic or stdatomic.h (and so using GCC 4.9, of course) that demonstrates any bug: that is, that does not contain a data race according to the C11 definition, but where GCC has reordered code in a way that introduces one (and so one can be demonstrated by enough iterations of the threads in the testcase) - or where the code generated fails some other semantics associated with happens before, such as those for visible side effect and visible sequence of side effects. I expect any such bug, and fix, would probably not be a front-end issue but an issue with the atomic built-in functions failing to ensure appropriate ordering in the presence of dependencies involving atomic operations (dependencies not involving such operations having no effects on C11 semantics).
[Bug lto/50432] lto1.exe: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1173 when build Qt4.7.4 rcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50432 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-10 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- So bug can be closed AFAIU?
[Bug sanitizer/59454] blacklisting sanitized functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 --- Comment #2 from Yuri Gribov tetra2005 at gmail dot com --- Proper link to Fortran attr bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209
[Bug sanitizer/59454] blacklisting sanitized functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 Yuri Gribov tetra2005 at gmail dot com changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #1 from Yuri Gribov tetra2005 at gmail dot com --- I guess what you really need is equivalent of __attribute__((no_address_safety_analysis)) in Fortran land. People have been talking about supporting attributes in GNU Fortran for ages (see #41209) but it never got anywhere.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #31 from dave.anglin at bell dot net --- On 12/10/2013 11:49 AM, jakub at gcc dot gnu.org wrote: For that a patch has been posted, just not reviewed: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00963.html Excellent. As for hppa, the change to enable it isn't in upstream GCC, so you as a maintainer need to make it working first and if changes are needed for compiler-rt maintained code, make sure it is accepted there first too. I'm fully aware that the change to enable isn't upstream. I'm still debating in my mind whether this should be done or not. At the moment, there are no additional changes to the compiler-rt code as far as I know. However, things seem fragile and possibly this library is unsuitable for an architecture that is only supported by Gentoo and Debian unstable Linux ports. I'm not sure what the issue is with the hppa kernel typedef for time_t. It seems defined by the generic linux type definitions. If this needs to be changed for libsanitizer, I would like to understand why. As far as I can tell, hppa isn't unique in using time_t in uapi/asm/stat.h although the majority of ports only use base types.
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- (In reply to H.J. Lu from comment #7) classpath/java/awt/image/SinglePixelPackedSampleModel.java is used on Linux. Is there a way to compile it by hand ^ I meant isn't used. on Linux?
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- classpath/java/awt/image/SinglePixelPackedSampleModel.java is used on Linux. Is there a way to compile it by hand on Linux?
[Bug fortran/59450] [OOP] ICE for Array Valued Function combined with Deferred Specification Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) Draft patch which fixes the error (not regtested): Does regtest cleanly.
[Bug fortran/59450] [OOP] ICE for Array Valued Function combined with Deferred Specification Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC||ktietz at gcc dot gnu.org
--- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org ---
So assert trigger here is:
'gcc_assert (preferred_alignment = stack_alignment_needed);'
Caused because because
(gdb) print preferred_alignment
$1 = 16
(gdb) print stack_alignment_needed
$2 = 4
So hacky variant to fix that would be to enforce that preferred and
stack-alignment_needed are set identical
Index: i386.c
===
--- i386.c (Revision 205860)
+++ i386.c (Arbeitskopie)
@@ -9362,6 +9362,14 @@ ix86_compute_frame_layout (struct ix86_frame *fram
crtl-stack_alignment_needed = 128;
}
+ /* If preferred_alignment is bigger then stack_alignment_needed
+ make both sizes equal. */
+ if (preferred_alignment stack_alignment_needed)
+{
+ stack_alignment_needed = preferred_alignment;
+ crtl-stack_alignment_needed = crtl-preferred_stack_boundary;
+}
+
gcc_assert (!size || stack_alignment_needed);
gcc_assert (preferred_alignment = STACK_BOUNDARY / BITS_PER_UNIT);
gcc_assert (preferred_alignment = stack_alignment_needed);
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- My understanding is stack realignment doesn't work on Windows. There was a attempt to do it at a time. But we didn't know enough about Windows to do it.
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 --- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org --- Well, for x64 we can't realign stack due issue about prologue layout enforced by SEH stuff. For x86 I see actually no good reason why this shouldn't work. I checked generated assembly and it looks fine AFAICS. Do you recall what the issue for x86 windows was?
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
Markus Trippelsdorf octoploid at yandex dot com changed:
What|Removed |Added
CC||octoploid at yandex dot com
--- Comment #9 from Markus Trippelsdorf octoploid at yandex dot com ---
This issue also happens when building LLVM.
Reduced:
markus@x4 llvm_build % cat test.ii
template typename _Iterator struct A;
template typename _Tp struct A_Tp * {
typedef _Tp value_type;
typedef int difference_type;
};
template typename _Compare struct B {};
template typename _Compare struct C {
_Compare _M_comp;
template typename _Value, typename _Iterator
int operator()(_Value p1, _Iterator p2) {
return _M_comp(p1, *p2);
}
};
template typename _Compare C_Compare __val_comp_iter(B_Compare);
template typename _RandomAccessIterator, typename _Compare
void __unguarded_linear_insert(_RandomAccessIterator p1, _Compare p2) {
typename A_RandomAccessIterator::value_type a;
_RandomAccessIterator b = p1;
--b;
while (p2(a, b)) {
*p1 = 0;
p1 = b;
--b;
}
}
template typename _RandomAccessIterator, typename _Compare
void __insertion_sort(_RandomAccessIterator, _Compare p2) {
for (_RandomAccessIterator c;; ++c)
__unguarded_linear_insert(c, __val_comp_iter(p2));
}
template typename _RandomAccessIterator, typename _Distance, typename
_Compare
void __chunk_insertion_sort(_RandomAccessIterator, _Distance, _Compare p3) {
_RandomAccessIterator d;
__insertion_sort(d, p3);
}
template typename _RandomAccessIterator, typename _Pointer, typename _Compare
void __merge_sort_with_buffer(_RandomAccessIterator p1, _Pointer, _Compare p3)
{
__chunk_insertion_sort(p1, 0, p3);
}
template typename _RandomAccessIterator, typename _Pointer, typename
_Distance,
typename _Compare
void __stable_sort_adaptive(_RandomAccessIterator, _Pointer, _Distance,
_Compare p4) {
_RandomAccessIterator e;
__merge_sort_with_buffer(e, 0, p4);
}
template typename _RandomAccessIterator, typename _Compare
void __stable_sort(_RandomAccessIterator p1, _Compare p2) {
__stable_sort_adaptive(
p1, 0, typename A_RandomAccessIterator::difference_type(), p2);
}
template typename _RandomAccessIterator, typename _Compare
void stable_sort(_RandomAccessIterator, _RandomAccessIterator p2, _Compare) {
B_Compare f;
__stable_sort(p2, f);
}
class D {
public:
void m_fn1();
};
class F {
struct G {
D MFI;
int operator()(int p1, int p2) {
if (p1)
return 0;
if (p2)
return 1;
MFI.m_fn1();
}
};
void m_fn1(int p1) const;
};
void F::m_fn1(int p1) const {
int *g, *h;
stable_sort(h, g, G());
}
markus@x4 llvm_build % g++ -O2 -c test.ii
test.ii: In member function ‘void F::m_fn1(int) const’:
test.ii:74:6: internal compiler error: in add_old_iv_candidates, at
tree-ssa-loop-ivopts.c:2541
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 Markus Trippelsdorf octoploid at yandex dot com changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #10 from Markus Trippelsdorf octoploid at yandex dot com --- Started with r205848.
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target|x86_64-apple-darwin13 | Status|WAITING |NEW Host|x86_64-apple-darwin13 | Build|x86_64-apple-darwin13 |
[Bug c++/59457] New: name mangling in presence of variadic templates seems wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59457
Bug ID: 59457
Summary: name mangling in presence of variadic templates seems
wrong
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plasmahh at gmx dot net
With the program below, the output is
1hI1AI2hhIiEEE
hAhhint
hA, hhint
where the hA, hhint part is from my hand-mangled idea how it should
look like. It seems to be only present when variadic templates are there, e.g.
when you replace class... with class, it goes away. Clang btw. seems to mangle
it correctly, that is with J in place of I.
#include iostream
#include typeinfo
#include cxxabi.h
struct A{};
templateclass,class... struct h{};
templateclass struct hh{};
int main() {
typedef hA,hhint hx;
const char* name = typeid(hx).name();
std::cout name \n;
char db[4096];
size_t size = 4096;
int st;
abi::__cxa_demangle(name,db,size,st);
std::cout db \n;
// now what I think the symbol should look like (exchange
abi::__cxa_demangle(1hI1AJ2hhIiEEE,db,size,st);
std::cout db \n;
return 0;
}
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- Started with r205848. Well, the assert at line 2541 has been introduced in the revision: +gcc_assert (gimple_bb (phi) == data-current_loop-header); and it was in the original patch et http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00630.html, but without explanation for it.
[Bug c++/59457] name mangling in presence of variadic templates seems wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59457 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com --- The result is the same with 4.9 and 4.7.2, so this bug has been there for quite some time.
[Bug target/59458] New: alternative 13 in *movsf_internal is mishandled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59458
Bug ID: 59458
Summary: alternative 13 in *movsf_internal is mishandled
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
We have
(define_insn *movsf_internal
[(set (match_operand:SF 0 nonimmediate_operand
=Yf*f,m ,Yf*f,?r ,?m,v,v,v,m,?r,?Yi,!*y,!*y,!m,!r ,!*Ym)
(match_operand:SF 1 general_operand
Yf*fm,Yf*f,G ,rmF,rF,C,v,m,v,Yj,r ,*y ,m ,*y,*Yn,r))]
alternative 13 is MMXMOV instruction to store *y to !m. But
alternative 13 gets the default mode, SF. But MMXMOV is
case TYPE_MMXMOV:
switch (get_attr_mode (insn))
{
case MODE_DI:
return movq\t{%1, %0|%0, %1};
case MODE_SI:
return movd\t{%1, %0|%0, %1};
default:
gcc_unreachable ();
}
MODE_SF gets gcc_unreachable. This patch:
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 7138868..aa2664f 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3126,7 +3140,7 @@
(const_string 1)
(const_string *)))
(set (attr mode)
-(cond [(eq_attr alternative 3,4,9,10,14,15)
+(cond [(eq_attr alternative 3,4,9,10,13,14,15)
(const_string SI)
(eq_attr alternative 11)
(const_string DI)
sets mode to SI for alternative 13.
[Bug target/59459] New: MIPS target tests failing (gcc.target/mips/fpr-moves-7.c, fpr-moves-8.c, int-moves-1.c, etc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59459
Bug ID: 59459
Summary: MIPS target tests failing
(gcc.target/mips/fpr-moves-7.c, fpr-moves-8.c,
int-moves-1.c, etc)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sje at gcc dot gnu.org
CC: richard.sandiford at linaro dot org
Target: mips*-*-*
Starting around December 2nd, 2013 I noticed some new MIPS test failures.
These include
gcc.target/mips/fpr-moves-7.c
gcc.target/mips/fpr-moves-8.c
gcc.target/mips/int-moves-1.c
and possibly some others. Here is a cutdown test case based on fpr-moves-7.c
extern unsigned char gstuff[0x1];
__attribute__((mips16)) long double
bar ()
{
return *(long double *) (gstuff + 0x7fff);
}
And here is the failure, it requires the -mabi=64 -mips64r2 -EL -msoft-float
-fno-pic -msym32 flags.
I am not sure if this combination makes sense or not but GCC does not reject
them. If I take out -msoft-float or -fno-pic or -msym32 then the compiler does
reject the option combination. I think -msym32
forces the o64 ABI which technically supports mips16.
install-mips-mti-linux-gnu/bin/mips-mti-linux-gnu-gcc fpr-moves-7a.c -O0 '-mab
i=64' -mips64r2 -EL -msoft-float -fno-pic -msym32 -S -o fpr-moves-7.s
fpr-moves-7a.c: In function 'bar':
fpr-moves-7a.c:6:1: error: unrecognizable insn:
}
^
(insn 8 7 9 2 (set (reg:DI 198)
(unspec:DI [
(mem/c:BLK (reg/f:DI 197) [0 MEM[(long double *)gstuff +
32767B
]+0 S8 A8])
(mem/c:QI (plus:DI (reg/f:DI 197)
(const_int 7 [0x7])) [0 MEM[(long double *)gstuff +
327
67B]+7 S1 A8])
] UNSPEC_LOAD_LEFT)) fpr-moves-7a.c:5 -1
(nil))
fpr-moves-7a.c:6:1: internal compiler error: in extract_insn, at recog.c:2164
0x8f230a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/local/home/sellcey/nightly/src/gcc/gcc/rtl-error.c:109
0x8f2339 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/local/home/sellcey/nightly/src/gcc/gcc/rtl-error.c:117
0x8bf663 extract_insn(rtx_def*)
/local/home/sellcey/nightly/src/gcc/gcc/recog.c:2164
0x74b9f3 instantiate_virtual_regs_in_insn
/local/home/sellcey/nightly/src/gcc/gcc/function.c:1555
0x74b9f3 instantiate_virtual_regs
/local/home/sellcey/nightly/src/gcc/gcc/function.c:1921
0x74b9f3 execute
/local/home/sellcey/nightly/src/gcc/gcc/function.c:1971
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.
[Bug fortran/35831] [F95] Shape mismatch check missing for dummy procedure argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831 --- Comment #18 from janus at gcc dot gnu.org --- Author: janus Date: Tue Dec 10 21:41:43 2013 New Revision: 205873 URL: http://gcc.gnu.org/viewcvs?rev=205873root=gccview=rev Log: 2013-12-10 Janus Weil ja...@gcc.gnu.org PR fortran/35831 * interface.c (check_dummy_characteristics): Add checks for several attributes. 2013-12-10 Janus Weil ja...@gcc.gnu.org PR fortran/35831 * gfortran.dg/c_by_val_5.f90: Modified. * gfortran.dg/dummy_procedure_10.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/dummy_procedure_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_by_val_5.f90
[Bug fortran/35831] [F95] Shape mismatch check missing for dummy procedure argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from janus at gcc dot gnu.org --- (In reply to janus from comment #17) Related TODOs: * improve gfc_dep_compare_expr to catch more cases (and/or enable the warnings in check_result_characteristics and check_dummy_characteristics, marked by FIXMEs) This point is still open, but can be tracked e.g. in PR 37222. * check more attributes in check_dummy_characteristics (another FIXME) This has been implemented in r205873. * Tobias' remarks at http://gcc.gnu.org/ml/fortran/2012-08/msg00034.html, e.g. PR54189 and PR54190 I think all of these remarks have been fixed by now (or at least sorted into PRs). All in all, I think this PR is ripe to get closed after more than five years with (almost) everything fixed.
[Bug fortran/37222] [OOP] Checks when overriding type-bound procedures are incomplete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37222 --- Comment #3 from janus at gcc dot gnu.org --- Basically all the checks in this area have been fixed by now. One of the last todo items is a carry-over from PR 35831: * improve gfc_dep_compare_expr to catch more cases (and/or enable the warnings in check_result_characteristics and check_dummy_characteristics, marked by FIXMEs)
[Bug rtl-optimization/59446] loop2_doloop creates constant comparison and dead jump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59446 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-10 Assignee|unassigned at gcc dot gnu.org |law at redhat dot com Ever confirmed|0 |1 --- Comment #1 from Jeffrey A. Law law at redhat dot com --- Thanks Oleg. I see what's happening and will pull together a fix.
[Bug target/59460] New: [4.9 Regression] ICE with -mips16 and __attribute__((nomips16))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59460
Bug ID: 59460
Summary: [4.9 Regression] ICE with -mips16 and
__attribute__((nomips16))
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: robert.suchanek at imgtec dot com
Target: mips16
A number of failures started to appear on the trunk for mips-elf target
(possibly other targets too) and all of the new failures are related
to the fix for PR58115. The following is a narrowed testcase that triggers
an ICE.
It crashes when attributes for a function try to override -mips16 argument
given on the commandline. I found another problem with the testcase when the
function takes an argument of type v2sf: the compiler segfaults due to
recursive calls, but this also points to the fix.
$ cat mips-ps-2.c
typedef float v2sf __attribute__ ((vector_size(8)));
__attribute__((nomips16)) v2sf foo () {}
$ mips-elf-gcc -mips32r2 -mfp64 -mips16 -mpaired-single -c mips-ps-2.c
mips-ps-2.c: In function ‘foo’:
mips-ps-2.c:3:1: internal compiler error: in emit_move_multi_word, at
expr.c:3518
__attribute__((nomips16)) v2sf foo () {}
^
0x736d43 emit_move_multi_word
../../gcc-trunk/gcc/expr.c:3518
0x736061 emit_move_insn(rtx_def*, rtx_def*)
../../gcc-trunk/gcc/expr.c:3650
0x7b5d0a expand_function_end()
../../gcc-trunk/gcc/function.c:5120
0x65fef0 construct_exit_block
../../gcc-trunk/gcc/cfgexpand.c:5282
0x65fef0 gimple_expand_cfg
../../gcc-trunk/gcc/cfgexpand.c:5737
0x65fef0 execute
../../gcc-trunk/gcc/cfgexpand.c:5932
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.
[Bug fortran/34004] Accepts invalid: Ambigiuous interface with subroutine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34004 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #12 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #9) How about counting this as a bug in the F03 standard and closing the PR as invalid (as suggested by Mikael)? If nobody want to do the changes for a diagnostic under -std=f95/f2003, I think it should be closed as WONTFIX to better reflect the situation. Doing so.
[Bug rtl-optimization/59446] loop2_doloop creates constant comparison and dead jump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59446 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org --- Thanks. Please let me know if I can help.
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #16 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #14) For predicting branches, we have gimple predict_stmt. Request for assistance/comment patch for gfortran: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01034.html
[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Tue Dec 10 22:58:37 2013 New Revision: 205874 URL: http://gcc.gnu.org/viewcvs?rev=205874root=gccview=rev Log: PR rtl-optimization/58295 * simplify-rtx.c (simplify_truncation): Restrict the distribution for WORD_REGISTER_OPERATIONS targets. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c
[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295 --- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Tue Dec 10 22:59:27 2013 New Revision: 205875 URL: http://gcc.gnu.org/viewcvs?rev=205875root=gccview=rev Log: PR rtl-optimization/58295 * simplify-rtx.c (simplify_truncation): Restrict the distribution for WORD_REGISTER_OPERATIONS targets. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/simplify-rtx.c
[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org --- This should be fixed.
[Bug rtl-optimization/59461] New: missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59461 Bug ID: 59461 Summary: missed zero-extension elimination in the combiner Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ebotcazou at gcc dot gnu.org This is a spin-off of PR rtl-optimization/58295. The zero-extension is not (and has never been) eliminated on the SPARC at -O2: ee_isdigit2: sethi %hi(zeb_test_array), %g1 or %g1, %lo(zeb_test_array), %g1 ldub[%g1+%o0], %g1 mov 0, %o0 add %g1, -48, %g1 and %g1, 0xff, %g1 cmp %g1, 9 jmp %o7+8 movleu %icc, 1, %o0 .size ee_isdigit2, .-ee_isdigit2 The instruction and %g1, 0xff, %g1 is redundant like on the ARM and the combiner should eliminate it. The difference between the ARM and the SPARC is that the former explicitly zero-extends the load from memory while the latter does it only implicitly via LOAD_EXTEND_OP. This shouldn't matter in the end, but does here because of some weakness of the nonzero_bits machinery.
[Bug rtl-optimization/59461] missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59461 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-10 Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I'll look into this at some point.
[Bug target/59462] New: c-c++-common/cilk-plus/AN/builtin_func_double2.c fails on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59462
Bug ID: 59462
Summary: c-c++-common/cilk-plus/AN/builtin_func_double2.c fails
on MIPS
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sje at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Target: mips*-*-*
The test c-c++-common/cilk-plus/AN/builtin_func_double2.c is failing on both of
my mips targets (mips-mti-elf and mips-mti-linux-gnu). Here is a cutdown
test case:
int foo(void)
{
int y, i;
double array[100];
for (i = 0; i 100; i++)
{
array[i] = (double) i;
}
y = __sec_reduce_any_nonzero (array[:]);
return y;
}
And here is the failure when compiled with g++ -O2 -ftree-vectorize -fcilkplus.
For some reason the same code compiled with C instead of C++ works.
install-mips-mti-elf/bin/mips-mti-elf-g++ -c -O2 -ftree-vectorize -fcilkplus
q.c
/tmp/cc3IU2hd.s: Assembler messages:
/tmp/cc3IU2hd.s:45: Error: invalid operands `movz $2,$4,$fcc0'
[Bug target/59458] alternative 13 in *movsf_internal is mishandled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59458 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Tue Dec 10 23:21:06 2013 New Revision: 205876 URL: http://gcc.gnu.org/viewcvs?rev=205876root=gccview=rev Log: Properly handle alternative 13 in *movsf_internal PR target/59458 * config/i386/i386.md (*movsf_internal): Set mode to SI for alternative 13. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug target/59458] alternative 13 in *movsf_internal is mishandled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59458 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
