[Bug c++/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484 --- Comment #3 from Marc Glisse --- (In reply to Vladimir Sedach from comment #2) > It is not just about "long long". It isn't about long long at all, it is about whether your code is valid. In your latest example, you are casting an int* to a float*, that's pretty much the definition of an aliasing violation. The types __m128 etc are documented as allowing aliasing, but I don't think that extends to other operands of the intrinsics.
[Bug middle-end/56956] [4.9 Regression] ftrapv traps on valid abs-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956 Richard Biener changed: What|Removed |Added Known to work||5.3.0 Summary|[4.9/5 Regression] ftrapv |[4.9 Regression] ftrapv |traps on valid abs-like |traps on valid abs-like |code|code Known to fail||5.2.0 --- Comment #12 from Richard Biener --- Author: rguenth Date: Mon Nov 23 08:32:28 2015 New Revision: 230736 URL: https://gcc.gnu.org/viewcvs?rev=230736&root=gcc&view=rev Log: 2015-11-23 Richard Biener Backport from mainline 2015-10-29 Richard Biener PR middle-end/56956 * fold-const.c (fold_cond_expr_with_comparison): Do not fold unsigned conditonal negation to ABS_EXPR. * c-c++-common/ubsan/pr56956.c: New testcase. Added: branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/pr56956.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/fold-const.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug middle-end/56956] [4.9 Regression] ftrapv traps on valid abs-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956 Richard Biener changed: What|Removed |Added Known to work||5.3.0 Summary|[4.9/5 Regression] ftrapv |[4.9 Regression] ftrapv |traps on valid abs-like |traps on valid abs-like |code|code Known to fail||5.2.0 --- Comment #12 from Richard Biener --- Author: rguenth Date: Mon Nov 23 08:32:28 2015 New Revision: 230736 URL: https://gcc.gnu.org/viewcvs?rev=230736&root=gcc&view=rev Log: 2015-11-23 Richard Biener Backport from mainline 2015-10-29 Richard Biener PR middle-end/56956 * fold-const.c (fold_cond_expr_with_comparison): Do not fold unsigned conditonal negation to ABS_EXPR. * c-c++-common/ubsan/pr56956.c: New testcase. Added: branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/pr56956.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/fold-const.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/68493] [6 Regression] [graphite] ICE in copy_loop_phi_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68493 Richard Biener changed: What|Removed |Added CC||spop at gcc dot gnu.org Target Milestone|--- |6.0
[Bug tree-optimization/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68492 Richard Biener changed: What|Removed |Added Target||i?86-*-* Status|NEW |ASSIGNED Component|middle-end |tree-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/68445] [6 Regression] ICE: internal compiler error: in operator[], at vec.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68445 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Nov 23 08:36:59 2015 New Revision: 230737 URL: https://gcc.gnu.org/viewcvs?rev=230737&root=gcc&view=rev Log: 2015-11-23 Richard Biener PR tree-optimization/68445 * tree-vect-slp.c (vect_create_mask_and_perm): Properly use two different strides. * gcc.dg/vect/pr68445.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr68445.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/68445] [6 Regression] ICE: internal compiler error: in operator[], at vec.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68445 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68486 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |WAITING
Last reconfirmed||2015-11-23
CC||hjl.tools at gmail dot com
Component|c++ |target
Ever confirmed|0 |1
--- Comment #4 from Richard Biener ---
As the summary mentions 'volatile' I'll also point to the implementation of the
intrinsics which have
/* Store four SPFP values. The address must be 16-byte aligned. */
extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_store_ps (float *__P, __m128 __A)
{
*(__v4sf *)__P = (__v4sf)__A;
}
so they are not using a volatile qualified type to access *__P which means
the stores are not considered volatile by GCC.
The arguments about strict-aliasing requirements still hold, only __m128 is
declared as __may_alias__:
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
/* Internal data types for implementing the intrinsics. */
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
so the v4sf store has regular TBAA rules applied (and the __may_alias__ on
the by value passed __A has no effect).
-> target "bug", but I'd say an INVALID one.
HJ, I remember the "master" copy of the intrinsics documentation is somewhere
at Intel - what does that say to the two above issues?
Thus all of this boils down to the question whether the intrinsics are
implemented correctly (as documented). The volatile part of it would
mean to either pessimize all users or that we can't implement the
intrinsics as C functions.
[Bug c++/68495] Error when expanding nontype variadic argument in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68495
--- Comment #1 from Samuel Neves ---
Minimal example can be further reduced to
template struct int_seq {};
constexpr struct {
constexpr int operator()(int x) const { return x + 1; }
} f1 {};
template
auto f2(F f, int_seq) -> int_seq {
return {};
}
int main() {
f2(f1, int_seq<0>{});
}
This suggests that the issue is with GCC not recognizing that `f::operator()`
is constexpr; this information is seemingly lost somewhere along the way.
[Bug target/68483] [5/6 Regression] gcc 5.2: suboptimal code compared to 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68483 Richard Biener changed: What|Removed |Added Target||i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-23 Component|other |target Blocks||53947 Target Milestone|--- |5.3 Summary|gcc 5.2: suboptimal code|[5/6 Regression] gcc 5.2: |compared to 4.9 |suboptimal code compared to ||4.9 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Hum, on x86_64 I don't see either GCC 4.9 or GCC 5.2 vectorize the function at all because they fail to analyze the evolution of the dataref for input[j] as the initial j of the inner loop is not propagated as zero. With i?86 I can confirm your observation but I don't see it fixed on trunk. Note that this boils down to vector shift detection of permutes where (IIRC) some patterns were not properly guarded on SSE3 support previously and a wrong-code bug was fixed conservatively on the GCC 5 branch while missing support was only implemented on trunk. The failure to vectorize on x86_64 isn't a regression. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug go/68496] New: [libgo] reflect test fails on Linux x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68496 Bug ID: 68496 Summary: [libgo] reflect test fails on Linux x86-64 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ismail at i10z dot com CC: cmang at google dot com Target Milestone: --- Getting: Aborted reflect.call.N13_reflect.Value /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/value.go:450 reflect.Call.N13_reflect.Value /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/value.go:300 reflect_test.TestCallWithStruct /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/all_test.go:1492 testing.tRunner ../../../libgo/go/testing/testing.go:455 goroutine 16 [chan receive]: testing.RunTests ../../../libgo/go/testing/testing.go:561 testing.Run.pN9_testing.M ../../../libgo/go/testing/testing.go:493 main.main /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/_testmain.go:146 created by main ../../../libgo/runtime/go-main.c:48 goroutine 18 [finalizer wait]: created by runtime_createfing ../../../libgo/runtime/mgc0.c:2577 goroutine 53 [sleep]: reflect_test.selectWatcher /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/all_test.go:1383 created by reflect_test.$nested2 /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/all_test.go:1113 FAIL: reflect λ ./gcc/gccgo -v Using built-in specs. COLLECT_GCC=./gcc/gccgo Target: x86_64-pc-linux-gnu Configured with: ../configure --prefix=/opt/gcc-trunk --enable-languages=c,c++,fortran,go --enable-checking=release --enable-ssp --disable-libssp --disable-libvtv --disable-libmpx --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --enable-linker-build-id --disable-plugin --enable-linux-futex --program-suffix=-6 --without-system-libunwind --with-tune=corei7-avx --with-build-config=bootstrap-lto --disable-multilib --disable-werror --disable-nls --with-fpmath=sse --enable-clocale=gnu Thread model: posix gcc version 6.0.0 20151123 (experimental) (GCC)
[Bug target/68482] No vectorization for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68482 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Richard Biener --- Fixed.
[Bug target/68482] No vectorization for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68482 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Nov 23 09:11:00 2015 New Revision: 230740 URL: https://gcc.gnu.org/viewcvs?rev=230740&root=gcc&view=rev Log: 2015-11-23 Richard Biener PR tree-optimization/68482 * gcc.dg/vect/pr68482.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr68482.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/68479] Dynamic loading multiple shared libraries with identical static libstdc++ breaks streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68479 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-23 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. I don't think this is intended to work when you re-export the libstdc++ symbols. Not sure if there is an easy way to make them hidden with --begin-group/--end-group and a linker flag. So you'd need to provide a version script to the link of x.so and y.so.
[Bug c++/68476] microblaze: compilation of btSoftBody.cpp doesn't terminate with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68476 Richard Biener changed: What|Removed |Added Target||microblaze Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-23 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Waiting for at least a preprocessed source file and the compile output with -v appended.
[Bug libfortran/51119] MATMUL slow for large matrices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #21 from Thomas Koenig --- > Hidden behind a -fexternal-blas-n switch might be an option. Including GPUs > seems even a tad more tricky. We have a paper on GPU (small) matrix > multiplication, http://dbcsr.cp2k.org/_media/gpu_book_chapter_submitted.pdf Quite interesting what can be done with GPUs... > . BTW, another interesting project is the libxsmm library more aimed at > small (<128) matrices see : https://github.com/hfp/libxsmm . Not sure if > this info is useful in this context, but it might provide inspiration. I assume that for small matrices bordering on the silly (say, a matrix multiplication with dimensions of (1,2) and (2,1)) the inline code will be faster if the code is compiled with the right options, due to function call overhead. I also assume that libxsmm will become faster quite soon for bigger sizes. Do you have an idea where the crossover is?
[Bug tree-optimization/68474] [6 Regression] ICE: in get_no_error_domain, at tree-call-cdce.c:699 with -funsafe-math-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68474 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target Milestone|--- |6.0
[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473 Richard Biener changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org Target Milestone|--- |6.0
[Bug go/68477] error: type variant differs by TYPE_STRING_FLAG.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68477 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-23 Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Sorry, the second file isn't necessary at all: % gccgo -flto foo1.go go1: error: type variant differs by TYPE_STRING_FLAG.
[Bug ipa/68470] [4.9/5/6 Regression] Internal Compiler Error observed by g++-4.9.2 and a few other versions (reported to Debian)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68470 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||mliska at suse dot cz Target Milestone|--- |4.9.4
[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463 Richard Biener changed: What|Removed |Added Keywords||lto Component|other |driver --- Comment #1 from Richard Biener --- > Or maybe just print an error during linking that offloading doesn't support > mixing LTO and non-LTO objects (even if some of them doesn't have offload)? That's the worst solution - having non-LTO objects is the whole point of linker-plugin support. I presume the same issue exists for GCC 5.
[Bug c/68462] -fno-strict-aliasing not respected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68462 --- Comment #4 from Richard Biener --- With N_domains non-static GCC has to assume it has its address taken and thus it thinks that the stores to ->next, .lol and .size can alias it. So the issue that -fno-strict-aliasing is not "respected" is that type-based aliasing only matters for memory accesses via pointers and GCC can independelty prove that N_domains is not pointed-to if it is static.
[Bug libfortran/51119] MATMUL slow for large matrices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #22 from Joost VandeVondele --- (In reply to Thomas Koenig from comment #21) > I assume that for small matrices bordering on the silly > (say, a matrix multiplication with dimensions of (1,2) and (2,1)) > the inline code will be faster if the code is compiled with the > right options, due to function call overhead. I also assume that > libxsmm will become faster quite soon for bigger sizes. > > Do you have an idea where the crossover is? I agree that inline should be faster, if the compiler is reasonably smart, if the matrix dimensions are known at compile time (i.e. should be able to generate the same kernel). I haven't checked yet.
[Bug tree-optimization/68460] ICE in init_stmt_vec_info_vec with -ftree-vectorize and -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68460 --- Comment #2 from vries at gcc dot gnu.org --- Author: vries Date: Mon Nov 23 09:45:38 2015 New Revision: 230742 URL: https://gcc.gnu.org/viewcvs?rev=230742&root=gcc&view=rev Log: Always call free_stmt_vec_info_vec in gather_scalar_reductions 2015-11-23 Tom de Vries PR tree-optimization/68460 * tree-parloops.c (gather_scalar_reductions): Also call free_stmt_vec_info_vec if simple_loop_info == NULL. * gcc.dg/autopar/pr68460.c: New test. Added: trunk/gcc/testsuite/gcc.dg/autopar/pr68460.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-parloops.c
[Bug debug/66432] [4.9 Regression] libgomp.c/appendix-a/a.29.1.c -O2 -g: type mismatch between an SSA_NAME and its symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66432 Jakub Jelinek changed: What|Removed |Added Keywords|openmp | Summary|[4.9/5/6 Regression]|[4.9 Regression] |libgomp.c/appendix-a/a.29.1 |libgomp.c/appendix-a/a.29.1 |.c -O2 -g: type mismatch|.c -O2 -g: type mismatch |between an SSA_NAME and its |between an SSA_NAME and its |symbol |symbol --- Comment #11 from Jakub Jelinek --- Fixed for 5.3+ so far.
[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68327 --- Comment #4 from Ilya Enkovich --- Author: ienkovich Date: Mon Nov 23 10:01:51 2015 New Revision: 230743 URL: https://gcc.gnu.org/viewcvs?rev=230743&root=gcc&view=rev Log: gcc/ PR tree-optimization/68327 * tree-vect-loop.c (vect_determine_vectorization_factor): Don't compute vectype for non-relevant mask producers. * gcc/tree-vect-stmts.c (vectorizable_comparison): Check stmt relevance earlier. gcc/testsuite/ PR tree-optimization/68327 * gcc.dg/pr68327.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr68327.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68327 Ilya Enkovich changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Ilya Enkovich --- Fixed
[Bug rtl-optimization/68173] gcc takes a long time and a lot of memory with -O0 on source file with very large expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68173 --- Comment #14 from rguenther at suse dot de --- On Fri, 20 Nov 2015, vmakarov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68173 > > --- Comment #13 from Vladimir Makarov --- > (In reply to Richard Biener from comment #12) > > callgrind points at bitmap_set_bit called via process_bb_lives -> > > mark_regno_dead. > > Maybe some code in that (the DCE code?) can be keyed on if (optimize). > > > > in mark_regno_dead callgrind points to > > > > bitmap_set_bit (bb_killed_pseudos, regno); > > > > being the expensive one. > > I've tried to implement bb_killed_pseudos and bb_gen_pseudos as > sparsesets but it gave nothing in term of compiler speed. I think the > major problem is in processing too many pseudos in -O0 mode which are > about 1000 times more than in -O2 mode. Yeah, but without optimization we can't do sth about that (well, do more coalescing maybe, but as said coalescing is O(n^2) because of liveness - so we'd run into the very same issue there).
[Bug target/68483] [5/6 Regression] gcc 5.2: suboptimal code compared to 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68483 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- On i?86 this regressed with r217509, aka part of VEC_RSHIFT_EXPR removal. Guess we'll need to have a look at the i?86 vec perm handling.
[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68432 --- Comment #8 from rsandifo at gcc dot gnu.org --- I have a patch series that fixes the bug but I need to make sure that it works on other targets that use the "enabled" attribute, and run it through an all-target test. I'm hoping to post the patches tomorrow.
[Bug tree-optimization/68455] [6 Regression] ICE: tree check: expected integer_cst, have plus_expr in decompose, at tree.h:5123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68455 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- I'll have a look then.
[Bug target/68483] [5/6 Regression] gcc 5.2: suboptimal code compared to 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68483
--- Comment #4 from Jakub Jelinek ---
Ah, no, the problem is not on the backend side, but during veclower2 pass.
Before that pass we after the replacement of v>> 64 or v>>32 shifts we have:
vect_sum_15.12_58 = VEC_PERM_EXPR ;
vect_sum_15.12_59 = vect_sum_15.12_58 + vect_sum_15.10_57;
vect_sum_15.12_60 = VEC_PERM_EXPR ;
vect_sum_15.12_61 = vect_sum_15.12_60 + vect_sum_15.12_59;
but veclower2 for some reason decides to lower the latter VEC_PERM_EXPR into:
_32 = BIT_FIELD_REF ;
_17 = BIT_FIELD_REF ;
_23 = BIT_FIELD_REF ;
vect_sum_15.12_60 = {_32, _17, _23, 0};
The first VEC_PERM_EXPR is kept and generates efficient code. If I manually
disable in the debugger the lowering, the code regression is gone.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #14 from Florian Weimer --- (In reply to Szabolcs Nagy from comment #13) > if gcc treats p-q as (ssize_t)p-(ssize_t)q and makes > optimization decisions based on signed int range then > that's broken and leads to wrong code gen. Thanks for the test case. I think the remedy proposed so far (glibc should block allocations sized half of the address space and larger) is insufficient.
[Bug c/67999] Wrong optimization of pointer comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 Florian Weimer changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=63303 --- Comment #26 from Florian Weimer --- (In reply to Florian Weimer from comment #12) > (In reply to Daniel Micay from comment #10) > > (In reply to Florian Weimer from comment #7) > > > If this is not a GCC bug and it is the responsibility of allocators not to > > > produce huge objects, do we also have to make sure that no object crosses > > > the boundary between 0x7fff_ and 0x8000_? If pointers are treated > > > as de-facto signed, this is where signed overflow would occur. > > > > No, that's fine. > > Is this based on your reading of the standard, the GCC sources, or both? > (It is unusual to see people making such definite statements about > middle-end/back-end behavior, that's why I have to ask.) As I suspect, the claim that this is fine seems to be incorrect, see bug 63303 comment 13.
[Bug target/68494] [ARM] Use vector multiply by lane
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68494 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-23 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan --- NTAPS is undefined. What's the current output and what output do you expect ?
[Bug rtl-optimization/68128] A huge regression in Parboil v2.5 OpenMP CUTCP test (2.5 times lower performance)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68128
--- Comment #6 from Richard Biener ---
.omp_data_i = &PARM_NOALIAS.0+64
PARM_NOALIAS.0+64 = &NONLOCAL
PARM_NOALIAS.64+192 = &NONLOCAL
...
_35 = *.omp_data_i
pg_36 = _35 + UNKNOWN
pg_63 = pg_36
.omp_data_i_12(D), points-to vars: { D.1985 } (nonlocal)
pg_63 = { NONLOCAL }
and we end up with
:
# iftmp.0_7 = PHI
_47 = iftmp.0_7 + _46;
*pg_63 = _47;
i_49 = i_62 + 1;
# PT = nonlocal
pg_50 = pg_63 + 4;
_51 = MEM[(struct .omp_data_s.1 &).omp_data_i_12(D) clique 1 base
1].gridspacing;
dx_52 = _51 + dx_64;
if (ib_28 >= i_49)
goto ;
else
goto ;
where we consider the load of gridspacing to alias *pg_63. That is because
of the not implemented ??? in
/* Mark "other" loads and stores as belonging to CLIQUE and with
base zero. */
static bool
visit_loadstore (gimple *, tree base, tree ref, void *clique_)
{
unsigned short clique = (uintptr_t)clique_;
if (TREE_CODE (base) == MEM_REF
|| TREE_CODE (base) == TARGET_MEM_REF)
{
tree ptr = TREE_OPERAND (base, 0);
if (TREE_CODE (ptr) == SSA_NAME
&& ! SSA_NAME_IS_DEFAULT_DEF (ptr))
{
/* ??? We need to make sure 'ptr' doesn't include any of
the restrict tags we added bases for in its points-to set. */
return false;
}
which would need to look at ptr's points-to solution and intersect that
with a bitmap we'd need to form out of the restrict tags used for the
respective clique (we only use a single one at the moment, thus a
single bit test is enough if you consider properly pt_anything for ptr).
It's not a complicated fix I think so if you have time to play with it...
[Bug target/68497] New: ICE: in output_387_binary_op, at config/i386/i386.c:17689 with -fno-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68497
Bug ID: 68497
Summary: ICE: in output_387_binary_op, at
config/i386/i386.c:17689 with -fno-checking
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Created attachment 36806
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36806&action=edit
reduced testcase
Compiler output:
$ gcc -fno-checking testcase.c
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in output_387_binary_op, at
config/i386/i386.c:17689
}
^
0xecd4d6 output_387_binary_op(rtx_def*, rtx_def**)
/repo/gcc-trunk/gcc/config/i386/i386.c:17689
0x85693b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-trunk/gcc/final.c:2947
0x8584c2 final(rtx_insn*, _IO_FILE*, int)
/repo/gcc-trunk/gcc/final.c:2044
0x858e69 rest_of_handle_final
/repo/gcc-trunk/gcc/final.c:4435
0x858e69 execute
/repo/gcc-trunk/gcc/final.c:4510
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-230738-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-230738-checking-yes-rtl-df-nographite
Thread model: posix
gcc version 6.0.0 20151123 (experimental) (GCC)
The failing assertion is:
17686: && (STACK_TOP_P (operands[1]) || STACK_TOP_P (operands[2])))
17687:; /* ok */
17688: else
17689:gcc_checking_assert (is_sse);
17690:
17691: switch (GET_CODE (operands[3]))
17692:{
The above if(flag_checking ... ) is false for -fno-checking, but
gcc_checking_assert() doesn't care about -fno-checking.
Tested revisions:
r230738 - ICE
[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550
--- Comment #4 from Jason Wyatt ---
It appears that while parsing the initialiser for the array,
maybe_constant_init switches the var for a constructor. This constructor only
sets the m2 member variable. You can see the result in the gimple it produces:
testValue = 1;
var = {};
var.m2 = 2;
var.m1 = testValue;
array = {};
array[0].m2 = 2;
[Bug tree-optimization/68465] pass_lim doesn't detect identical loop entry conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68465 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Richard Biener --- I don't think that's LIMs job then. Iterating LIM won't help here w/o intermediate optimization.
[Bug plugins/54959] current_pass == NULL during invocation of pass->gate within execute_ipa_summary_passes()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54959 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Yeah, 'this' should be used instead of current_pass.
[Bug tree-optimization/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68492 Ilya Enkovich changed: What|Removed |Added CC||ienkovich at gcc dot gnu.org --- Comment #3 from Ilya Enkovich --- Looks like a duplicate of PR68327. r230743 fixed 465.tonto build for me.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-11-23
Ever confirmed|0 |1
--- Comment #15 from Richard Biener ---
Note that in practice it needs exposal of the address constant to trigger the
bogus optimization.
Note that the IL from the frontend is indeed the one to blame here:
char * p = (char *) mmap (2147479552B, 8192, 3, 50, -1, 0);
char * q = 2147483647B;
if ((int) (p + 4096) - (int) q > 0)
{
for correctness WRT undefined overflow we need to do the subtraction
in unsigned arithmetic and then interpret the result as signed
(for an eventual division by element size).
Same issue in the C++ frontend btw.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 Leon Winter changed: What|Removed |Added Version|5.0 |5.2.1 --- Comment #4 from Leon Winter --- Bug still persists.
[Bug other/68498] New: Replace LOOPS_MAY_HAVE_MULTIPLE_LATCHES with LOOPS_HAVE_SINGLE_LATCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68498
Bug ID: 68498
Summary: Replace LOOPS_MAY_HAVE_MULTIPLE_LATCHES with
LOOPS_HAVE_SINGLE_LATCH
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider apply_loop_flags:
...
static void
apply_loop_flags (unsigned flags)
{
if (flags & LOOPS_MAY_HAVE_MULTIPLE_LATCHES)
{
/* If the loops may have multiple latches, we cannot canonicalize
them further (and most of the loop manipulation functions will
not work). However, we avoid modifying cfg, which some
passes may want. */
gcc_assert ((flags & ~(LOOPS_MAY_HAVE_MULTIPLE_LATCHES
| LOOPS_HAVE_RECORDED_EXITS)) == 0);
loops_state_set (LOOPS_MAY_HAVE_MULTIPLE_LATCHES);
}
else
disambiguate_loops_with_multiple_latches ();
/* Create pre-headers. */
if (flags & LOOPS_HAVE_PREHEADERS)
{
int cp_flags = CP_SIMPLE_PREHEADERS;
if (flags & LOOPS_HAVE_FALLTHRU_PREHEADERS)
cp_flags |= CP_FALLTHRU_PREHEADERS;
create_preheaders (cp_flags);
}
/* Force all latches to have only single successor. */
if (flags & LOOPS_HAVE_SIMPLE_LATCHES)
force_single_succ_latches ();
/* Mark irreducible loops. */
if (flags & LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS)
mark_irreducible_loops ();
if (flags & LOOPS_HAVE_RECORDED_EXITS)
record_loop_exits ();
}
...
Most properties in there have a handling bit: if property, do something.
The odd one out is LOOPS_MAY_HAVE_MULTIPLE_LATCHES, where we have if !property,
do something.
LOOPS_MAY_HAVE_MULTIPLE_LATCHES is not really a property, it's the absence of
LOOPS_MAY_HAVE_MULTIPLE_LATCHES that's a property, which we might call
LOOPS_HAVE_SINGLE_LATCH).
It would properly be better to replace uses of LOOPS_MAY_HAVE_MULTIPLE_LATCHES
with uses of LOOPS_HAVE_SINGLE_LATCH. We would get in apply_loop_flags:
...
if (flags & LOOPS_HAVE_SINGLE_LATCH)
disambiguate_loops_with_multiple_latches ();
else
{
/* If the loops may have multiple latches, we cannot canonicalize
them further (and most of the loop manipulation functions will
not work). However, we avoid modifying cfg, which some
passes may want. */
gcc_assert ((flags & ~(LOOPS_HAVE_RECORDED_EXITS)) == 0);
}
...
[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68317 --- Comment #11 from Jiong Wang --- Author: jiwang Date: Mon Nov 23 12:14:05 2015 New Revision: 230754 URL: https://gcc.gnu.org/viewcvs?rev=230754&root=gcc&view=rev Log: [Patch] Drop constant overflow flag in adjust_range_with_scev when possible 2015-11-23 Richard Biener Jiong Wang gcc/ PR tree-optimization/68317 PR tree-optimization/68326 * tree-vrp.c (adjust_range_with_scev): Call drop_tree_overflow if the final min and max are not infinity. gcc/testsuite/ * gcc.dg/pr68317.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr68317.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug target/68497] ICE: in output_387_binary_op, at config/i386/i386.c:17689 with -fno-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68497 Mikhail Maltsev changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-23 CC||miyuki at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |miyuki at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Mikhail Maltsev --- Confirmed. I have a patch and I'll post it shortly (after regtest).
[Bug tree-optimization/68326] ICE at -O3 on x86_64-linux-gnu in set_value_range, at tree-vrp.c:380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68326 --- Comment #2 from Jiong Wang --- Author: jiwang Date: Mon Nov 23 12:14:05 2015 New Revision: 230754 URL: https://gcc.gnu.org/viewcvs?rev=230754&root=gcc&view=rev Log: [Patch] Drop constant overflow flag in adjust_range_with_scev when possible 2015-11-23 Richard Biener Jiong Wang gcc/ PR tree-optimization/68317 PR tree-optimization/68326 * tree-vrp.c (adjust_range_with_scev): Call drop_tree_overflow if the final min and max are not infinity. gcc/testsuite/ * gcc.dg/pr68317.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr68317.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68317 Jiong Wang changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Jiong Wang --- Mark as fixed.
[Bug c/68499] New: Unclear STDC FP_CONTRACT behavior in non-standard modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68499 Bug ID: 68499 Summary: Unclear STDC FP_CONTRACT behavior in non-standard modes Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vincent-gcc at vinc17 dot net Target Milestone: --- Created attachment 36807 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36807&action=edit example of C program based on the STDC FP_CONTRACT pragma The following applies to: gcc (Debian 20151030-1) 6.0.0 20151031 (experimental) [trunk revision 229615] When I compile a C program like the attached one with #pragma STDC FP_CONTRACT OFF in a standard mode, the pragma is now taken into account as expected (see PR37845 / r204460). However, in a non-standard mode such as the default gnu99 (?), it is not taken into account (a FMA is generated for an operation like x*y+z), but one gets no warnings either. One should have one of the following behaviors in non-standard modes: 1. The pragma is taken into account. 2. The pragma is not taken into account, but one gets a warning (making it unknown in non-standard modes is OK). If possible, (1) is probably the best choice, at least in gnu99 and gnu11 modes, as the user may want to disable contraction for some floating-point algorithms while still being able to use specific GNU extensions.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #16 from Alexander Cherepanov ---
On 2015-11-23 14:58, rguenth at gcc dot gnu.org wrote:
> Note that in practice it needs exposal of the address constant to trigger the
> bogus optimization.
No. The program:
#include
#include
#include
#include
int main()
{
// make sure our allocation will cross 0x8000 boundary
// but still will not violate limits of gcc
size_t len = 0x7fff;
char *p1 = malloc(len);
char *volatile v = p1 + len;
char *p2 = v;
long l1 = (long)(uintptr_t)p1;
long l2 = (long)(uintptr_t)p2;
if (l2 < l1) {
long z = p2 - p1;
if (z < 0)
printf("%ld\n", z);
}
}
prints a positive number for me even though it guards against it. gcc
5.2 with -m32 -O2.
[Bug c/68499] Unclear STDC FP_CONTRACT behavior in non-standard modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68499 --- Comment #1 from Vincent Lefèvre --- Well, actually the pragma is ignored in all cases. The fix was to set the default to OFF in the standard modes. So, currently, one should get a warning in non-standard modes.
[Bug other/68500] New: Remove in_loop_pipeline usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68500
Bug ID: 68500
Summary: Remove in_loop_pipeline usage
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider pass_slp_vectorize::execute
...
pass_slp_vectorize::execute (function *fun)
{
basic_block bb;
bool in_loop_pipeline = scev_initialized_p ();
if (!in_loop_pipeline)
{
loop_optimizer_init (LOOPS_NORMAL);
scev_initialize ();
}
...
if (!in_loop_pipeline)
{
scev_finalize ();
loop_optimizer_finalize ();
}
...
It uses an in_loop_pipeline variable, initialized using scev_initialized_p to
detect whether the pass is run in the loop pipeline, to allow different
behaviour inside and outside the loop pipeline.
We want a cleaner way to allow passes to run correctly inside and outside the
loop pipeline.
[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484
--- Comment #5 from H.J. Lu ---
(In reply to Richard Biener from comment #4)
> As the summary mentions 'volatile' I'll also point to the implementation of
> the intrinsics which have
>
> /* Store four SPFP values. The address must be 16-byte aligned. */
> extern __inline void __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> _mm_store_ps (float *__P, __m128 __A)
> {
> *(__v4sf *)__P = (__v4sf)__A;
> }
>
> so they are not using a volatile qualified type to access *__P which means
> the stores are not considered volatile by GCC.
>
> The arguments about strict-aliasing requirements still hold, only __m128 is
> declared as __may_alias__:
>
> /* The Intel API is flexible enough that we must allow aliasing with other
>vector types, and their scalar components. */
> typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
>
> /* Internal data types for implementing the intrinsics. */
> typedef float __v4sf __attribute__ ((__vector_size__ (16)));
>
> so the v4sf store has regular TBAA rules applied (and the __may_alias__ on
> the by value passed __A has no effect).
>
> -> target "bug", but I'd say an INVALID one.
>
> HJ, I remember the "master" copy of the intrinsics documentation is
> somewhere at Intel - what does that say to the two above issues?
>
> Thus all of this boils down to the question whether the intrinsics are
> implemented correctly (as documented). The volatile part of it would
> mean to either pessimize all users or that we can't implement the
> intrinsics as C functions.
_mm_store_ps is documented in Intel SDM for movaps. It doesn't say
anything about aliasing.
[Bug other/68500] Remove in_loop_pipeline usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68500 --- Comment #1 from vries at gcc dot gnu.org --- Created attachment 36808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36808&action=edit Tentative patch: "Don't reapply loops flags if unnecessary in loop_optimizer_init"
[Bug other/68500] Remove in_loop_pipeline usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68500 --- Comment #2 from vries at gcc dot gnu.org --- Created attachment 36809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36809&action=edit Tentative patch: Add PROP_scev
[Bug other/68500] Remove in_loop_pipeline usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68500 --- Comment #3 from vries at gcc dot gnu.org --- Created attachment 36810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36810&action=edit Tentative patch: Add PROP_loops_normal_re_lcssa
[Bug c/20785] Pragma STDC * (C99 FP) unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #7 from Vincent Lefèvre --- For the STDC FENV_ACCESS pragma specifically, there is PR34678. For the STDC FP_CONTRACT pragma, there is PR37845, which was fixed by r204460, though things could be improved in the future as the pragma is actually ignored: it's just that the default is now OFF in standard modes to be C99/C11 conforming. In the non-standard modes, one now misses the warning: PR68499.
[Bug other/68500] Remove in_loop_pipeline usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68500 --- Comment #4 from vries at gcc dot gnu.org --- First patch posted here: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02634.html Last two patches fyi-posted here: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02688.html
[Bug c++/68001] [cilkplus] ICE in cp_gimplify_expr, at cp/cp-gimplify.c:760
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68001 --- Comment #1 from Kirill Yukhin --- Author: kyukhin Date: Mon Nov 23 12:58:12 2015 New Revision: 230755 URL: https://gcc.gnu.org/viewcvs?rev=230755&root=gcc&view=rev Log: PR c++/68001 gcc/c-family PR c++/68001 * c-gimplify.c (c_gimplify_expr): Stop the process if see an error. * cilk.c (recognize_spawn): Determine location in a more precise way. gcc/cp * cp-gimplify.c (cp_gimplify_expr): Stop the process if see an error. gcc/testsuite * g++.dg/cilk-plus/CK/pr68001.cc: New test. Added: trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr68001.cc Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-gimplify.c trunk/gcc/c-family/cilk.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484
--- Comment #6 from Marc Glisse ---
clang has:
static __inline__ void __DEFAULT_FN_ATTRS
_mm_storel_epi64(__m128i *__p, __m128i __a)
{
struct __mm_storel_epi64_struct {
long long __u;
} __attribute__((__packed__, __may_alias__));
((struct __mm_storel_epi64_struct*)__p)->__u = __a[0];
}
It doesn't prove anything, this is just a point of comparison.
(I haven't checked, but I suspect that they have an implicit may_alias on all
vector types)
[Bug c/68499] Unclear STDC FP_CONTRACT behavior in non-standard modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68499 --- Comment #2 from joseph at codesourcery dot com --- Unknown pragmas are diagnosed with -Wunknown-pragmas (part of -Wall).
[Bug middle-end/68221] libgomp reduction-11/12 failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68221
--- Comment #5 from Richard Biener ---
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 230671)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -750,8 +750,11 @@ copy_reference_ops_from_ref (tree ref, v
case MEM_REF:
/* The base address gets its own vn_reference_op_s structure. */
temp.op0 = TREE_OPERAND (ref, 1);
- if (tree_fits_shwi_p (TREE_OPERAND (ref, 1)))
- temp.off = tree_to_shwi (TREE_OPERAND (ref, 1));
+ {
+ offset_int off = mem_ref_offset (ref);
+ if (wi::fits_shwi_p (off))
+ temp.off = off.to_shwi ();
+ }
temp.clique = MR_DEPENDENCE_CLIQUE (ref);
temp.base = MR_DEPENDENCE_BASE (ref);
temp.reverse = REF_REVERSE_STORAGE_ORDER (ref);
[Bug middle-end/68221] libgomp reduction-11/12 failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68221 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-23 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1
[Bug go/66574] Time is provided in millisecond precision instead of nanoseconds as described in go documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66574 --- Comment #6 from boger at us dot ibm.com --- (In reply to Ian Lance Taylor from comment #5) > Fixed on mainline. Can this be backported to the gcc 5 branch?
[Bug ipa/68470] [4.9/5/6 Regression] Internal Compiler Error observed by g++-4.9.2 and a few other versions (reported to Debian)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68470
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #4 from Martin Liška ---
(In reply to Mikhail Maltsev from comment #3)
> A bit simplified testcase:
>
> void deallocate(void *);
> void *a;
>
> struct C {
> virtual void m_fn1();
> };
>
> struct D {
> C *m_fn2() {
> if (a)
> __builtin_abort();
> }
> };
> D getd();
>
> struct vec_int {
> int _M_start;
> ~vec_int() {
> if (_M_start)
> deallocate(&_M_start);
> }
> };
> vec_int *b;
>
> struct I {
> virtual void m_fn3();
> };
>
> void I::m_fn3() {
> if (a)
> getd().m_fn2()->m_fn1();
> b->~vec_int();
> }
>
> $ cc1plus -O2 test.cc - ICE after fnsplit
> $ cc1plus -O2 test.cc -fno-checking - ICE in IPA-ICF (like in the original
> bug report)
> $ cc1plus -O2 test.cc -fno-devirtualize - OK
> $ cc1plus -O2 test.cc --param partial-inlining-entry-probability=0 - OK
>
> ISTM, this is some IPA-related issue:
> D::m_fn2 and vec_int::~vec_int are inlined into I::m_fn3.
> D::m_fn2 (D::operator-> in previous comments) does not return any value
> (undefined behavior), so gimple_fold_call devirtualizes
> getd().m_fn2()->m_fn1() into __builtin_unreachable during fwprop1.
> fnsplit then tries to split I::m_fn3. This is how the function looks before
> fnsplit:
>
> ;; Function virtual void I::m_fn3() (_ZN1I5m_fn3Ev, funcdef_no=4,
> decl_uid=2299, cgraph_uid=4, symbol_order=6)
>
> virtual void I::m_fn3() (struct I * const this)
> {
> struct C * D.2356;
> void * a.0_3;
> void * a.2_5;
> struct vec_int * b.1_12;
> int _14;
> int * _15;
>
> :
> a.0_3 = a;
> if (a.0_3 != 0B)
> goto ;
> else
> goto ;
>
> :
> getd ();
> a.2_5 = a;
> if (a.2_5 != 0B)
> goto ;
> else
> goto ;
>
> :
> __builtin_abort ();
>
> :
> __builtin_unreachable ();
>
> :
> b.1_12 = b;
> _14 = b.1_12->_M_start;
> if (_14 != 0)
> goto ;
> else
> goto ;
>
> :
> _15 = &b.1_12->_M_start;
> deallocate (_15);
>
> :
> MEM[(struct &)b.1_12] ={v} {CLOBBER};
> return;
>
> }
>
> The splitting pass tries to do this:
>
> Splitting function at:
> Split point at BB 6
> header time: 19646 header size: 10
> split time: 2491 split size: 6
> bbs: 6, 7
> SSA names to pass:
> Introduced new external node (void __builtin_unreachable()/18).
>
> ICE probably happens in this part:
>
> virtual void I::m_fn3() (struct I * const this)
> {
> struct C * D.2356;
> void * a.0_3;
> void * a.2_5;
>
> :
> a.0_3 = a;
> if (a.0_3 != 0B)
> goto ;
> else
> goto ;
>
> :
> getd ();
> a.2_5 = a;
> if (a.2_5 != 0B)
> goto ;
> else
> goto ;
>
> :
> __builtin_abort ();
>
> :
> __builtin_unreachable ();
>
> :
> I::_ZN1I5m_fn3Ev.part.1 ();
> MEM[(struct &)_12] ={v} {CLOBBER};
> return;
>
> }
Hi.
The problem is really in , which contains definition of 'b.1_12' that is
used in return_bb (). The return_bb is eventually merged with .
I'm not sure about proper fix, I would expect that return_bb must be pruned of
all unused stmts (that would be moved to newly created function). Any ideas?
Martin
[Bug target/68483] [5/6 Regression] gcc 5.2: suboptimal code compared to 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68483 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 36811 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36811&action=edit gcc6-pr68483.patch Untested fix.
[Bug ipa/65908] [5 Regression] ICE: in expand_thunk, at cgraphunit.c:1700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908 --- Comment #16 from Martin Liška --- Author: marxin Date: Mon Nov 23 13:58:40 2015 New Revision: 230756 URL: https://gcc.gnu.org/viewcvs?rev=230756&root=gcc&view=rev Log: PR ipa/65908 * ipa-icf.c (sem_item::target_supports_symbol_aliases): Remove construction of arg_types. (sem_function::sem_function): Likewise. (sem_function::~sem_function): Remove destruction of arg_types. (sem_function::compatible_parm_types_p): New function. (sem_function::equals_wpa): Reorg matching of return values and parameter types. (sem_function::equals_private): Reorg mathcing of argument types. (sem_function::parse_tree_args): Remove. (sem_function::param_used_p): New function. * ipa-icf.h (init_wpa): Do not call it. (parse_tree_args): Remove. (compatible_parm_types_p): Declare. (result_type): Remove. (arg_types): Remove. (param_used_p): Declare. * g++.dg/ipa/pr65908.C: New testcase. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/ipa/pr65908.C Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/ipa-icf.c branches/gcc-5-branch/gcc/ipa-icf.h branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug ipa/65908] [5 Regression] ICE: in expand_thunk, at cgraphunit.c:1700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Martin Liška --- Fixed in gcc-5-branch.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #19 from Chen Gang --- (In reply to Andrew Pinski from comment #18) > (In reply to Chen Gang from comment #17) > > I guess the diff below should be OK, I shall give a make check test. > > I would rather have the C front-end behavior for C++ rather than the > opposite way around. Because _Pragma are considered statements. For me, this bug is related with the demands (language definition), and C need not be part of C++. - For me, what cc1plus has done is OK: C++ looks that it always 'likes' more new features, and want to let the users (C++ programmer) use the language freely and in common sense. - But for C, if one feature is in discussing, it should not be treated as a common features (C standard is more stricter than C++). So we need not care about this 'bug' quite much (In real world, C programmers need not use #pragma in this way). In our case (this cc1 'bug'), Instead of returning the 'anbisous' result (it may cause misunderstanding for C/C++ programmers more or less), cc1 need report error during compiling.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #20 from Chen Gang --- (In reply to Andrew Pinski from comment #18) > (In reply to Chen Gang from comment #17) > > I guess the diff below should be OK, I shall give a make check test. > > I would rather have the C front-end behavior for C++ rather than the > opposite way around. Because _Pragma are considered statements. For me, this bug is related with the demands (language definition), and C need not be part of C++. - For me, what cc1plus has done is OK: C++ looks that it always 'likes' more new features, and want to let the users (C++ programmer) use the language freely and in common sense. - But for C, if one feature is in discussing, it should not be treated as a common features (C standard is more stricter than C++). So we need not care about this 'bug' quite much (In real world, C programmers need not use #pragma in this way). In our case (this cc1 'bug'), Instead of returning the 'anbisous' result (it may cause misunderstanding for C/C++ programmers more or less), cc1 need report error during compiling.
[Bug tree-optimization/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68492 --- Comment #4 from H.J. Lu --- (In reply to Ilya Enkovich from comment #3) > Looks like a duplicate of PR68327. r230743 fixed 465.tonto build for me. r230743 still fails for me. Can you show me your linking command line for 465.tonto build?
[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484 --- Comment #7 from Vladimir Sedach --- The "store" pointer could be not only volatile, but also static or global with same error.
[Bug c/68499] Unclear STDC FP_CONTRACT behavior in non-standard modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68499 Vincent Lefèvre changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Vincent Lefèvre --- Sorry, I forgot that I had an alias gcc='gcc -Wall', so that I got a warning for gcc, but not for gcc-snapshot. I've now changed by config to define such an alias for each GCC command found in $PATH. I'm closing this bug since nothing has changed concerning the warnings compared to old GCC versions.
[Bug tree-optimization/68501] New: [6 Regression] sqrt builtin is not used anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68501 Bug ID: 68501 Summary: [6 Regression] sqrt builtin is not used anymore Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: afomin.mailbox at gmail dot com CC: izamyatin at gmail dot com, rsandifo at redhat dot com, ysrumyan at gmail dot com Target Milestone: --- Target: x86_64-*-* Created attachment 36812 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36812&action=edit A reproducer For the attached reproducer compiled with g++ -mavx -Ofast we do not use IA sqrt builtin since r230492 thus emitting more insns. r230491 .L8: vmovaps (%r14,%rax), %ymm0 addl$1, %r12d vmovups 0(%r13,%rax), %xmm1 vinsertf128 $0x1, 16(%r13,%rax), %ymm1, %ymm1 vmulps %ymm1, %ymm1, %ymm1 vmulps %ymm0, %ymm0, %ymm0 vaddps %ymm1, %ymm0, %ymm1 vrsqrtps%ymm1, %ymm2 vmulps %ymm1, %ymm2, %ymm0 vmulps %ymm2, %ymm0, %ymm0 vaddps %ymm4, %ymm0, %ymm0 vmulps %ymm3, %ymm2, %ymm2 vmulps %ymm2, %ymm0, %ymm0 vmovups %xmm0, (%r10,%rax) vextractf128$0x1, %ymm0, 16(%r10,%rax) addq$32, %rax cmpl%r12d, %r9d ja .L8 r230492 .L8: .L8: vmovaps (%r14,%rax), %ymm0 addl$1, %r12d vmovups 0(%r13,%rax), %xmm1 vinsertf128 $0x1, 16(%r13,%rax), %ymm1, %ymm1 vmulps %ymm1, %ymm1, %ymm1 vmulps %ymm0, %ymm0, %ymm0 vaddps %ymm1, %ymm0, %ymm1 vcmpneqps %ymm1, %ymm2, %ymm5 vrsqrtps%ymm1, %ymm0 vandps %ymm5, %ymm0, %ymm0 vmulps %ymm1, %ymm0, %ymm1 vmulps %ymm0, %ymm1, %ymm0 vaddps %ymm4, %ymm0, %ymm0 vmulps %ymm3, %ymm1, %ymm1 vmulps %ymm1, %ymm0, %ymm0 vrcpps %ymm0, %ymm1 vmulps %ymm0, %ymm1, %ymm0 vmulps %ymm0, %ymm1, %ymm0 vaddps %ymm1, %ymm1, %ymm1 vsubps %ymm0, %ymm1, %ymm0 vmovups %xmm0, (%r10,%rax) vextractf128$0x1, %ymm0, 16(%r10,%rax) addq$32, %rax cmpl%r12d, %r9d ja .L8
[Bug tree-optimization/66721] [6 regression] gcc.target/i386/pr61403.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721
--- Comment #3 from Richard Biener ---
So I have a "solution" that I hope to prettify a bit still. The basic issue
is that SLP is "broken" in that it builds a tree of operations instead of a
graph.
That is, it un-CSEs all n in the testcase:
for (i = 0; i < size; ++i)
{
float n = sqrt (in[i].x * in[i].x + in[i].y * in[i].y + in[i].z *
in[i].z);
out[i].x = in[i].x / n;
out[i].y = in[i].y / n;
out[i].z = in[i].z / n;
}
which results in bloat in the SLP tree and initial vectorized code and also
cost which is good in this case. Usually with nicely vector-size aligned
things later passes can CSE all the mess again and the generated code isn't
so bad (so the costs are overly conservative). But in this case with an
"interleaving size" of 3 we end up with three vectors containing 4 groups
we'd want to CSE.
sqrt { in[0].x * in[0].x + in[0].y * in[0].y + ...,
in[0].x *
in[0].x * ...,
in[1].x * in[1].x + in[1].y * ... }
sqrt { ... }
sqrt { ... }
this way we avoid the permutes on the stores of course, but the lack of
CSE here makes the generated code worse (when you look at it with
-fno-vect-cost-model, the cost-model rejects the code even though it
might be profitable at a slightly larger theshold in practice).
.L5:
movups (%r8), %xmm8
addl$1, %r10d
addq$48, %r8
addq$48, %rax
movups -16(%r8), %xmm6
movups -32(%r8), %xmm7
movaps %xmm8, %xmm13
movdqa %xmm6, %xmm11
movdqa %xmm6, %xmm10
movaps %xmm6, %xmm1
movdqa %xmm7, %xmm9
movdqa %xmm7, %xmm0
movaps %xmm7, %xmm12
shufps $252, %xmm6, %xmm1
palignr $8, %xmm7, %xmm11
shufps $175, %xmm7, %xmm13
mulps %xmm1, %xmm1
movaps %xmm7, %xmm2
palignr $12, %xmm7, %xmm10
shufps $252, %xmm11, %xmm11
mulps %xmm11, %xmm11
shufps $240, %xmm7, %xmm12
shufps $252, %xmm10, %xmm10
mulps %xmm10, %xmm10
palignr $4, %xmm8, %xmm9
shufps $5, %xmm6, %xmm2
shufps $192, %xmm9, %xmm9
mulps %xmm9, %xmm9
palignr $8, %xmm8, %xmm0
shufps $192, %xmm0, %xmm0
mulps %xmm0, %xmm0
mulps %xmm13, %xmm13
addps %xmm10, %xmm11
mulps %xmm12, %xmm12
movaps %xmm8, %xmm10
shufps $192, %xmm8, %xmm10
mulps %xmm10, %xmm10
mulps %xmm2, %xmm2
addps %xmm11, %xmm1
addps %xmm13, %xmm12
addps %xmm10, %xmm9
movaps %xmm3, %xmm10
addps %xmm12, %xmm2
addps %xmm9, %xmm0
rsqrtps %xmm0, %xmm9
cmpneqps%xmm0, %xmm10
andps %xmm10, %xmm9
mulps %xmm9, %xmm0
movaps %xmm3, %xmm10
cmpneqps%xmm2, %xmm10
mulps %xmm0, %xmm9
mulps %xmm4, %xmm0
addps %xmm5, %xmm9
mulps %xmm9, %xmm0
rsqrtps %xmm2, %xmm9
andps %xmm10, %xmm9
mulps %xmm9, %xmm2
movaps %xmm3, %xmm10
cmpneqps%xmm1, %xmm10
mulps %xmm2, %xmm9
mulps %xmm4, %xmm2
addps %xmm5, %xmm9
mulps %xmm9, %xmm2
rsqrtps %xmm1, %xmm9
andps %xmm10, %xmm9
mulps %xmm9, %xmm1
mulps %xmm1, %xmm9
mulps %xmm4, %xmm1
addps %xmm5, %xmm9
mulps %xmm9, %xmm1
rcpps %xmm0, %xmm9
mulps %xmm9, %xmm0
mulps %xmm9, %xmm0
addps %xmm9, %xmm9
subps %xmm0, %xmm9
rcpps %xmm2, %xmm0
mulps %xmm9, %xmm8
mulps %xmm0, %xmm2
movups %xmm8, -48(%rax)
mulps %xmm0, %xmm2
addps %xmm0, %xmm0
subps %xmm2, %xmm0
mulps %xmm7, %xmm0
movups %xmm0, -32(%rax)
rcpps %xmm1, %xmm0
mulps %xmm0, %xmm1
mulps %xmm0, %xmm1
addps %xmm0, %xmm0
subps %xmm1, %xmm0
mulps %xmm6, %xmm0
movups %xmm0, -16(%rax)
cmpl%r10d, %r9d
ja .L5
of course it doesn't use any blend instruction. The testcase was to
test interleaving of size 3 support which should better have used
different operations to make SLP impossible (of course the testcase
is also from real-world code which means it is a relevant regression).
[Bug go/66574] Time is provided in millisecond precision instead of nanoseconds as described in go documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66574 --- Comment #7 from Ian Lance Taylor --- I'm a little worried because I'm not 100% confident that clock_gettime is available in the standard library on all systems. I don't want to break GCC 5 is that is the case. Admittedly I haven't seen any bug reports on mainline yet, but it's only been a few days.
[Bug target/68363] [4.9/5/6 Regression] ICE: in recog_memoized, at recog.h:167 with RTL checking with -mfix-cortex-a53-835769 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68363 --- Comment #2 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Nov 23 14:56:03 2015 New Revision: 230760 URL: https://gcc.gnu.org/viewcvs?rev=230760&root=gcc&view=rev Log: [AArch64] PR target/68363 Check that argument is real INSN in aarch64_madd_needs_nop PR target/68363 * config/aarch64/aarch64.c (aarch64_madd_needs_nop): Reject arguments that are not INSN_P. * gcc.target/aarch64/pr68363_1.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr68363_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog
[Bug target/68059] [arm] libgcc uses __write to report error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68059 --- Comment #3 from nsz at gcc dot gnu.org --- Author: nsz Date: Mon Nov 23 15:17:55 2015 New Revision: 230762 URL: https://gcc.gnu.org/viewcvs?rev=230762&root=gcc&view=rev Log: [ARM] PR target/68059 libgcc should not use __write for printing fatal error libgcc/ PR target/68059 * config/arm/linux-atomic-64bit.c (__write): Rename to... (write): ...this and fix the return type. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/arm/linux-atomic-64bit.c
[Bug tree-optimization/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68492 --- Comment #5 from Ilya Enkovich --- (In reply to H.J. Lu from comment #4) > r230743 still fails for me. Can you show me your linking command line > for 465.tonto build? Here it is. Works OK for today's trunk (revision 230759). gfortran -Ofast -funroll-loops -flto -m64 -flto=16 -DSPEC_CPU2000_LP64 -march=core-avx2 -DSPEC_CPU_LP64types.fppized.o system.fppized.o str.fppized.o int.fppized.o real.fppized.o intvec.fppized.o realvec.fppized.o binmat.fppized.o cpxvec.fppized.o realmat.fppized.o parallel.fppized.o intmat.fppized.o buffer.fppized.o intvecvec.fppized.o strvec.fppized.o binvec.fppized.o unitnumber.fppized.o textfile.fppized.o opvector.fppized.o file.fppized.o cpxmat.fppized.o opmatrix.fppized.o archive.fppized.o diis.fppized.o reflection.fppized.o cif.fppized.o cpxmat3.fppized.o realmat3.fppized.o spacegroup.fppized.o slatershell.fppized.o slatershellvec.fppized.o interpolator.fppized.o slaterbasis.fppized.o shell1.fppized.o unitcell.fppized.o shell.fppized.o shellvec.fppized.o basis.fppized.o coppensorbital.fppized.o coppensorbitalvec.fppized.o coppensbasis.fppized.o atom.fppized.o reflectionvec.fppized.o rys.fppized.o cpxmat4.fppized.o gaussian.fppized.o gaussian2.fppized.o realmat4.fppized.o intmat3.fppized.o shell2.fppized.o atomvec.fppized.o crystal.fppized.o scfdata.fppized.o basisvec.fppized.o realmat5.fppized.o gaussian4.fppized.o shell4.fppized.o time.fppized.o colour.fppized.o colourfunction.fppized.o intvecmat3.fppized.o intvecintvechash.fppized.o marchingcube.fppized.o plotgrid.fppized.o isosurface.fppized.o realmat3vec.fppized.o cluster.fppized.o cpxmat5.fppized.o shellpair.fppized.o shellpairvec.fppized.o coppensbasisvec.fppized.o irrep.fppized.o irrepvec.fppized.o pointgroup.fppized.o slaterbasisvec.fppized.o shell1quartet.fppized.o roby.fppized.o dftgrid.fppized.o mol.fppized.o mol_main.fppized.o run_mol.fppized.o blas.o lapack.o -o tonto
[Bug target/68363] [4.9/5/6 Regression] ICE: in recog_memoized, at recog.h:167 with RTL checking with -mfix-cortex-a53-835769 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68363 --- Comment #3 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Nov 23 15:20:42 2015 New Revision: 230763 URL: https://gcc.gnu.org/viewcvs?rev=230763&root=gcc&view=rev Log: [AArch64] PR target/68363 Check that argument is real INSN in aarch64_madd_needs_nop Backport from mainline 2015-11-23 Kyrylo Tkachov PR target/68363 * config/aarch64/aarch64.c (aarch64_madd_needs_nop): Reject arguments that are not INSN_P. * gcc.target/aarch64/pr68363_1.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/pr68363_1.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/aarch64.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/68465] pass_lim doesn't detect identical loop entry conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68465 --- Comment #2 from Richard Biener --- Author: rguenth Date: Mon Nov 23 15:21:32 2015 New Revision: 230764 URL: https://gcc.gnu.org/viewcvs?rev=230764&root=gcc&view=rev Log: 2015-11-23 Richard Biener PR tree-optimization/68465 * tree-ssa-sccvn.c (sccvn_dom_walker::before_dom_children): Also record equalities from multiple predecessor blocks if only one non-backedge exists. * gcc.dg/tree-ssa/ssa-fre-52.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-52.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/68465] pass_lim doesn't detect identical loop entry conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68465 --- Comment #3 from Richard Biener --- Fixed the issue where this originally was observed in (oacc-kernel passes)
[Bug other/68498] Replace LOOPS_MAY_HAVE_MULTIPLE_LATCHES with LOOPS_HAVE_SINGLE_LATCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68498 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-23 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug target/68363] [4.9/5/6 Regression] ICE: in recog_memoized, at recog.h:167 with RTL checking with -mfix-cortex-a53-835769 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68363 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from ktkachov at gcc dot gnu.org --- Fixed on all active branches
[Bug target/68363] [4.9/5/6 Regression] ICE: in recog_memoized, at recog.h:167 with RTL checking with -mfix-cortex-a53-835769 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68363 --- Comment #4 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Nov 23 15:25:36 2015 New Revision: 230765 URL: https://gcc.gnu.org/viewcvs?rev=230765&root=gcc&view=rev Log: [AArch64] PR target/68363 Check that argument is real INSN in aarch64_madd_needs_nop Backport from mainline 2015-11-23 Kyrylo Tkachov PR target/68363 * config/aarch64/aarch64.c (aarch64_madd_needs_nop): Reject arguments that are not INSN_P. * gcc.target/aarch64/pr68363_1.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/pr68363_1.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/aarch64/aarch64.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/68501] [6 Regression] sqrt builtin is not used anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68501 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-23 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Yep, I also saw this. IIRC the recip pass is responsible for this.
[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-11-23
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from David Malcolm ---
Thanks for filing; I can reproduce.
Failing assertion at line 340:
337 bool
338 layout_range::contains_point (int row, int column) const
339 {
340 gcc_assert (m_start.m_line <= m_finish.m_line);
[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473
--- Comment #2 from David Malcolm ---
It's attempting to print this source range:
(gdb) p *range
$8 = {m_start = {m_line = 13, m_column = 12},
m_finish = {m_line = 6, m_column = 26},
m_show_caret_p = true,
m_caret = {m_line = 13, m_column = 12}}
i.e. (after dealing with tabs):
01122334455667
1234567890123456879012345687901234568790123456879012345687901234568790
1 /* { dg-options "-fdiagnostics-show-caret -mno-fp-ret-in-387" } */
2
3 #include
4
5 #define TEST_EQ(FUNC) do { \
6 if ((long)FUNC##l(xl,xl) != (long)xl) \
^FINISH
7 return; \
8} while (0)
9
10 void
11 foo (long double xl)
12 {
13TEST_EQ (fmin);
^
START&CARET
14 }
[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473 --- Comment #3 from David Malcolm --- Oops; I think line 6 above should read: 6if ((long)FUNC##l(xl,xl) != (long)xl) \ ^FINISH
[Bug tree-optimization/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68492 --- Comment #6 from H.J. Lu --- (In reply to Ilya Enkovich from comment #5) > (In reply to H.J. Lu from comment #4) > > r230743 still fails for me. Can you show me your linking command line > > for 465.tonto build? > > Here it is. Works OK for today's trunk (revision 230759). > > gfortran -Ofast -funroll-loops -flto -m64 -flto=16 -DSPEC_CPU2000_LP64 > -march=core-avx2 -DSPEC_CPU_LP64types.fppized.o system.fppized.o It is different from my bug report. Please use the same command line as mine.
[Bug tree-optimization/68502] New: [6 Regression][i686] spec2000/179.art runfails after r222914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68502 Bug ID: 68502 Summary: [6 Regression][i686] spec2000/179.art runfails after r222914 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: izamyatin at gmail dot com Target Milestone: --- There is a segmentation fault during execution r222914 is: r222914 | rguenth | 2015-05-08 18:13:55 +0300 (Fri, 08 May 2015) | 15 lines Changed paths: M /trunk/gcc/ChangeLog M /trunk/gcc/testsuite/ChangeLog A /trunk/gcc/testsuite/gcc.dg/vect/slp-41.c M /trunk/gcc/tree-vect-data-refs.c M /trunk/gcc/tree-vect-stmts.c Options I used - -m32 -static -O3 -mfpmath=sse -march=core-avx2 -m64 is ok
[Bug target/67089] [4.9/5/6 Regression] Integer overflow checks not optimized on x86/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67089
--- Comment #5 from Richard Henderson ---
Author: rth
Date: Mon Nov 23 15:55:58 2015
New Revision: 230767
URL: https://gcc.gnu.org/viewcvs?rev=230767&root=gcc&view=rev
Log:
Add uaddv4_optab and usubv4_optab
PR target/67089
* optabs.def (uaddv4_optab, usubv4_optab): New.
* internal-fn.c (expand_addsub_overflow): Use uaddv4_optab
and usubv4_optab in the u +- u -> u case.
* doc/md.texi (Standard Names): Document addv{m}4, subv{m}4,
mulv{m}4, uaddv{m}4, usubv{m}4, umulv{m}4.
* config/i386/i386.md (uaddv4, usubv4): New.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/doc/md.texi
trunk/gcc/internal-fn.c
trunk/gcc/optabs.def
[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473
--- Comment #4 from David Malcolm ---
No, I was wrong again.
The locus and start of the range are here:
(gdb) call
inform(line_table->location_adhoc_data_map.data[0x17].src_range.m_start,
"m_start")
pr68473-1.c:13:12: note: m_start
TEST_EQ (fmin); /* { dg-error "x87 register return with x87 disabled" } */
^
pr68473-1.c:6:13: note: in definition of macro ‘TEST_EQ’
if ((long)FUNC##l(xl,xl) != (long)xl) \
^~~~
and the finish of the range is here:
(gdb) call
inform(line_table->location_adhoc_data_map.data[0x17].src_range.m_finish,
"m_finish")
pr68473-1.c:6:26: note: m_finish
if ((long)FUNC##l(xl,xl) != (long)xl) \
^
pr68473-1.c:13:3: note: in expansion of macro ‘TEST_EQ’
TEST_EQ (fmin); /* { dg-error "x87 register return with x87 disabled" } */
^~~
via:
Breakpoint 2, error (gmsgid=0x1897930 "x87 register return with x87 disabled")
at ../../src/gcc/diagnostic.c:1153
1153 rich_location richloc (line_table, input_location);
(gdb) p /x input_location
$2 = 0x8017
(gdb) p line_table->location_adhoc_data_map.data[0x17]
$3 = {locus = 2147442627, src_range = {m_start = 2147442627, m_finish =
2147442633}, data = 0x0}
(gdb) p /x line_table->location_adhoc_data_map.data[0x17].src_range.m_start
$5 = 0x7fff5fc3
(gdb) p /x line_table->location_adhoc_data_map.data[0x17].src_range.m_finish
$6 = 0x7fff5fc9
[Bug tree-optimization/66573] Unexpected change in static, branch-prediction cost from O1 to O2 in if-then-else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573 --- Comment #10 from Segher Boessenkool --- GCC thinks bar2 will be executed more often that bar1; the code it generates is perfectly fine for that. If you think GCC's heuristics for branch prediction are no good, could use some improvement, you'll have to come up with more evidence than just a single artificial testcase. Sorry. These things were tuned on real code.
[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484 --- Comment #8 from Vladimir Sedach --- Adding "static" to "volatile" "solves" the problem: static int * volatile x = _x; I'm using this trick to avoid aggressive optimization when measuring the time of execution. The compiler does not skip calculations leading to saving the result in a loop.
[Bug middle-end/67714] [6 Regression] signed char is zero-extended instead of sign-extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67714 ktkachov at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #5 from ktkachov at gcc dot gnu.org --- Changing to P1 as it is a wrong-code regression affecting arm
[Bug middle-end/68279] ICE: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68279 --- Comment #5 from Sebastian Pop --- After fixing the graphite fail, I get these warnings from the testcase in comment4: FAIL: gfortran.dg/graphite/pr68279.f90 -O (test for excess errors) Excess errors: /work/spop/gcc/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:21:19: Warning: Legacy Extension: REAL array index at (1) /work/spop/gcc/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:22:25: Warning: Legacy Extension: REAL array index at (1) /work/spop/gcc/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:22:41: Warning: Legacy Extension: REAL array index at (1) /work/spop/gcc/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:22:29: Warning: Legacy Extension: REAL array index at (1) /work/spop/gcc/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:22:75: Warning: Legacy Extension: REAL array index at (1) /work/spop/gcc/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:22:86: Warning: Legacy Extension: REAL array index at (1) /work/spop/gcc/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:24:27: Warning: Legacy Extension: REAL array index at (1) /work/spop/gcc/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:24:36: Warning: Legacy Extension: REAL array index at (1) /work/spop/gcc/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:25:16: Warning: Legacy Extension: REAL array index at (1) /work/spop/gcc/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:25:34: Warning: Legacy Extension: REAL array index at (1) Is there a flag I can set to avoid these warnings? Thanks!
[Bug tree-optimization/68455] [6 Regression] ICE: tree check: expected integer_cst, have plus_expr in decompose, at tree.h:5123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68455 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Mon Nov 23 17:18:36 2015 New Revision: 230768 URL: https://gcc.gnu.org/viewcvs?rev=230768&root=gcc&view=rev Log: PR tree-optimization/68455 * tree-vrp.c (extract_range_from_binary_expr_1): Don't call extract_range_from_multiplicative_op_1 on symbolic ranges. * gcc.dg/tree-ssa/pr68455.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68455.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/68455] [6 Regression] ICE: tree check: expected integer_cst, have plus_expr in decompose, at tree.h:5123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68455 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
