[Bug c/66865] New: wine segfaults from gcc in trunk (r225757)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 Bug ID: 66865 Summary: wine segfaults from gcc in trunk (r225757) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: austinenglish at gmail dot com Target Milestone: --- It's a regression, I bisected it to: a19b6344800f6faef095c6aa3b0c7bef5e29b2fc is the first bad commit commit a19b6344800f6faef095c6aa3b0c7bef5e29b2fc Author: kugan Date: Tue Jun 2 22:53:15 2015 + gcc/ChangeLog: 2015-06-03 Kugan Vivekanandarajah Zhenqiang Chen PR target/65768 * cprop.c (try_replace_reg): Check cost of constants before propagating. gcc/testsuite/ChangeLog: 2015-06-03 Kugan Vivekanandarajah PR target/65768 * gcc.target/arm/maskdata.c: Remove -fno-gcse. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@224048 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 7e7261a710baead7ef64e15ceb25c4b30f6e7616 8070e793a5b40e1c2f4b5e873e12e6de73b35bf5 M gcc still in trunk. It should be noted that even with this fixed, there's are at least two other issues that are causing wine to crash on start (#66782, already fixed and #66838, patch available). With those patched, and this change reverted, wineboot is able to successfully run (tested on r225757).
[Bug c/66865] wine segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #1 from austinenglish at gmail dot com --- Created attachment 35973 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35973&action=edit revert patch These two patches get wine working in trunk.
[Bug c/66865] wine segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 kugan at gcc dot gnu.org changed: What|Removed |Added CC||kugan at gcc dot gnu.org --- Comment #2 from kugan at gcc dot gnu.org --- Thanks for the bug report. Do you have a test case I can see this issue or is there any easy way to reproduce it.
[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327
--- Comment #4 from Vittorio Zecca ---
For your convenience I repeat here the reproducer:
/* from gcc file fixopts.c */
/* must be compiled with -O2 */
/*gcc-5.1.0/gcc/rtlanal.c:4911:48: runtime error: shift exponent
4294967295 is too large for 64-bit type 'long unsigned int'*/
/*on source line "return nonzero & ((unsigned HOST_WIDE_INT) 1 <<
(bitwidth - 1))"*/
/* because unsigned int bitwidth is zero and bitwitdth-1 is 4294967295
on my x86-64 */
/* I did double check with:
* bitwidth = GET_MODE_PRECISION (mode);
* gcc_assert(bitwidth);
*/
/* the bug appears compiling fixopts.c crc32.c md5.c and many Fedora
21 kernel files*/
/* 66853 duplicato di 64327 */
int strcmp(const char *s1, const char *s2);
int fixinc_mode; /* must be outside main for bug to appear */
int main (void)
{
const char *pz;
if (strcmp (pz, "true") ) fixinc_mode = 0;
}
[Bug tree-optimization/66863] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66863 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-14 Component|ipa |tree-optimization Target Milestone|--- |6.0 Summary|wrong code at -Os and above |[6 Regression] wrong code |on x86_64-linux-gnu |at -Os and above on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- In VRP: _3 = (short int) a.0_2; if (a.0_2 == -2147483648) goto ; else goto ; : _10 = ASSERT_EXPR <_3, _3 == 0>; goto ; : _11 = ASSERT_EXPR <_3, _3 != 0>; The == ASSERT_EXPR looks fine, but this last != ASSERT_EXPR is a bit optimistic.
[Bug tree-optimization/66863] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66863 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Probably caused by 2015-06-30 Richard Biener * tree-vrp.c (register_edge_assert_for_2): Also register asserts for dominating conversion results. I'll have a look.
[Bug rtl-optimization/66865] [6 Regression] wine segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 Richard Biener changed: What|Removed |Added Component|c |rtl-optimization Version|unknown |6.0 Target Milestone|--- |6.0 Summary|wine segfaults from gcc in |[6 Regression] wine |trunk (r225757) |segfaults from gcc in trunk |(regression)|(r225757) (regression)
[Bug tree-optimization/66862] OpenMP SIMD does not work (use SIMD instructions) on conditional code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66862 --- Comment #3 from Richard Biener --- store data-races
[Bug libfortran/66861] [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.2
[Bug fortran/66860] [5/6 Regression] FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66860 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.2
[Bug tree-optimization/66862] OpenMP SIMD does not work (use SIMD instructions) on conditional code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66862
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||kyukhin at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
If you sed -i 's/short/int/' on the testcase, then e.g. with -mavx2 it is
vectorized with vmaskmovd. But AVX2 does not have a masked store for packed
16-bit integers, and as Richard mentioned, using vpminuw/vmovdqu that icc emits
is IMHO invalid, as it introduces a store data race and I see no wording in the
OpenMP standard that would allow introducing store data races, even in omp simd
regions.
Now, it seems AVX512BW (and AVX512VL in some cases) has the needed
instructions,
in particular VMOVDQU{8,16}, but it is not reflected in maskload and
maskstore expanders. CCing Kyrill and Uros on this.
[Bug bootstrap/55807] Support musl libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55807 nsz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||nsz at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #13 from nsz at gcc dot gnu.org --- Bug 55807 has gcc-4.7 patches while 58446 has gcc-4.8 patches attached, however they are both outdated and about the same issue so closing this one (gcc-trunk already has some of the patches after gcc-5 was branched off). *** This bug has been marked as a duplicate of bug 58446 ***
[Bug target/58446] Support for musl libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 nsz at gcc dot gnu.org changed: What|Removed |Added CC||lu_zero at gentoo dot org --- Comment #16 from nsz at gcc dot gnu.org --- *** Bug 55807 has been marked as a duplicate of this bug. ***
[Bug target/52991] attribute packed broken on mingw32?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Pierre Ossman changed: What|Removed |Added CC||ossman at cendio dot se --- Comment #19 from Pierre Ossman --- This bug report is now over three years old. Any progress? I'm still seeing it in 5.1.0. Should the summary also be updated to reflect that this is a regression? And should the default be reverted until the code can be fixed?
[Bug c++/65186] internal compiler error: in tsubst, at cp/pt.c:11738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65186 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #14 from Paolo Carlini --- Fixed.
[Bug libstdc++/66763] [6 Regression] 25_algorithms/remove/requirements/explicit_instantiation/2.cc fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66763 Markus Trippelsdorf changed: What|Removed |Added Target|powerpc-ibm-aix*|powerpc-ibm-aix*, ||powerpc64le-unknown-linux-g ||nu CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf --- Started with the switch to C++14: r225272. trippels@gcc2-power8 testsuite % g++ -std=c++98 -c -I./util/ 25_algorithms/remove/requirements/explicit_instantiation/2.cc trippels@gcc2-power8 testsuite % g++ -c -I./util/ 25_algorithms/remove/requirements/explicit_instantiation/2.cc 25_algorithms/remove/requirements/explicit_instantiation/2.cc:34:22: error: ‘std::value_type* std::remove(std::iterator_type, std::iterator_type, const value_type&)’ is not declared in ‘std’ const value_type&); ^
[Bug libstdc++/66763] [6 Regression] 25_algorithms/remove/requirements/explicit_instantiation/2.cc fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66763 --- Comment #4 from Markus Trippelsdorf --- This is an old issue. It also fails with gcc-4.9 and std=c++11.
[Bug target/58446] Support for musl libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #17 from nsz at gcc dot gnu.org --- gcc-trunk has most of the musl support patches (not backported yet to any release branch), the current state: libitm fix: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222325 fixincludes support: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222327 unwind support: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222328 gthread support: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222329 config changes: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222904 stdint changes: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222905 aarch64 support: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=223766 arm support: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=223749 mips support: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222915 x86 support: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=223218 microblaze support: not yet committed https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00437.html powerpc support: not yet committed https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01640.html sh support: not yet committed https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01636.html
[Bug other/61321] demangler crash on casts in template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61321 --- Comment #8 from Pedro Alves --- The patch was meanwhile approved: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01247.html I'm afraid I won't have time to get back to this for at least a few weeks. If someone else could push it, I'd appreciated it.
[Bug libstdc++/66763] [6 Regression] 25_algorithms/remove/requirements/explicit_instantiation/2.cc fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66763 --- Comment #5 from Jonathan Wakely --- I don't see any problem in libstdc++, the function is right there in the preprocessed output starting at line 34472 # 891 "/tmp/20150703/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/bits/stl_algo.h" 3 template inline _ForwardIterator remove(_ForwardIterator __first, _ForwardIterator __last, const _Tp& __value)
[Bug target/66840] [5/6 Regression] plugins fail to build on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66840 --- Comment #3 from Matthias Klose --- Created attachment 35974 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35974&action=edit patch
[Bug libstdc++/66763] [6 Regression] 25_algorithms/remove/requirements/explicit_instantiation/2.cc fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66763
--- Comment #6 from Jonathan Wakely ---
The difference is that we include ::remove in C++11 and later.
Reduced:
namespace std
{
template
_FIter
remove(_FIter, _FIter, const _Tp&);
}
extern "C" {
extern int remove (const char *__filename) throw ();
}
namespace std
{
using ::remove;
template
inline _ForwardIterator
remove(_ForwardIterator __first, _ForwardIterator __last,
const _Tp& __value)
{
return __first;
}
}
namespace std
{
struct value_type { };
typedef value_type* iterator_type;
template iterator_type remove(iterator_type, iterator_type,
const value_type&);
}
[Bug c++/66763] [6 Regression] 25_algorithms/remove/requirements/explicit_instantiation/2.cc fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66763 Jonathan Wakely changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #7 from Jonathan Wakely --- The reduced testcase fails on all targets, but is valid C++, so this is a FE problem.
[Bug c++/66763] [6 Regression] 25_algorithms/remove/requirements/explicit_instantiation/2.cc fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66763 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > The reduced testcase fails on all targets ... with any -std option, at least as far back as GCC 4.3.6
[Bug target/66866] New: [miscompile] incorrect load address on manual vector shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66866
Bug ID: 66866
Summary: [miscompile] incorrect load address on manual vector
shuffle
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
The following testcase fails at -O2:
#include
typedef short A __attribute__((__may_alias__));
short extr(const __m128i &d, int index) { return reinterpret_cast(&d)[index]; }
A &extr(__m128i &d, int index) { return reinterpret_cast(&d)[index]; }
__m128i shuf(const __m128i v)
{
__m128i r;
for (int i = 0; i + 4 <= 8; i += 4) {
extr(r, i + 0) = extr(v, i + 1);
extr(r, i + 1) = extr(v, i + 0);
extr(r, i + 2) = extr(v, i + 3);
extr(r, i + 3) = extr(v, i + 2);
}
return r;
}
int main()
{
__attribute__((aligned(16))) short mem[8];
*reinterpret_cast<__m128i *>(mem) = shuf(_mm_setr_epi16(0, 1, 2, 3, 4, 5, 6,
7));
if (mem[0] == 1 && mem[1] == 0 && mem[2] == 3 && mem[3] == 2 && mem[4] == 5
&&
mem[5] == 0 && mem[6] == 7 && mem[7] == 6) {
abort();
}
return 0;
}
Here's a little survey:
for CXX in /opt/*/bin/{g++,clang++}; do echo -n "$CXX: "; $CXX -O2 testcase.cpp
&& ./a.out && echo passed || echo failed; done
/opt/gcc-4.5.2/bin/g++: passed
/opt/gcc-4.5.3/bin/g++: passed
/opt/gcc-4.5.4/bin/g++: passed
/opt/gcc-4.6.0/bin/g++: passed
/opt/gcc-4.6.1/bin/g++: passed
/opt/gcc-4.6.3/bin/g++: passed
/opt/gcc-4.7.0/bin/g++: failed
/opt/gcc-4.7.1/bin/g++: failed
/opt/gcc-4.7.2/bin/g++: failed
/opt/gcc-4.8.0/bin/g++: failed
/opt/gcc-4.8.2/bin/g++: failed
/opt/gcc-4.9.0/bin/g++: failed
/opt/gcc-4.9.1/bin/g++: failed
/opt/gcc-5.1.0/bin/g++: failed
/opt/gcc-6-snapshot/bin/g++: failed
/opt/clang-3.2/bin/clang++: passed
/opt/clang-3.3/bin/clang++: passed
/opt/clang-3.4/bin/clang++: passed
/opt/clang-3.5/bin/clang++: passed
/opt/clang-3.6/bin/clang++: passed
/opt/clang-master/bin/clang++: passed
The value at index 5 is assigned incorrectly from v[0] instead of v[4]. The
issue goes away if I manually unroll the loop.
[Bug c/66867] New: Suboptimal code generation for C11 atomic_compare_exchange_strong_explicit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867
Bug ID: 66867
Summary: Suboptimal code generation for C11
atomic_compare_exchange_strong_explicit()
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
At least on ARM and PowerPC for the following test case
#include
void f(atomic_uint *a)
{
unsigned int e = 0;
atomic_compare_exchange_strong_explicit(a, &e, 1, memory_order_relaxed,
memory_order_relaxed);
}
a superfluous stack frame and store is generated:
.file "test-cas.c"
.machine ppc
.section".text"
.align 2
.globl f
.type f, @function
f:
stwu 1,-24(1) <- Superfluous
li 9,0
li 10,1
stw 9,8(1) <- Superfluous
.L2:
lwarx 9,0,3
cmpwi 0,9,0
bne- 0,.L3
stwcx. 10,0,3
bne- 0,.L2
.L3:
addi 1,1,24 <- Superfluous
blr
.size f, .-f
.ident "GCC: (GNU) 6.0.0 20150714 (experimental)"
[Bug tree-optimization/66863] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66863 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/66863] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66863 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Jul 14 11:39:14 2015 New Revision: 225768 URL: https://gcc.gnu.org/viewcvs?rev=225768&root=gcc&view=rev Log: 2015-07-14 Richard Biener PR tree-optimization/66863 * tree-vrp.c (register_edge_assert_for_2): Properly restrict what we record for conversion use stmt lhs inequalities. * gcc.dg/torture/pr66863.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr66863.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/66868] New: [5/6 Regression] wrong code generated with -O3 (dead code removal?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66868
Bug ID: 66868
Summary: [5/6 Regression] wrong code generated with -O3 (dead
code removal?)
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
Created attachment 35975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35975&action=edit
preprocessed source
[forwarded from https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1473674]
seen in the apt package manager, when built with -O3. Works with -O2 or -O3
-fno-inline-functions -finline-small-functions, on at least x86_64 and
powerpc64le. The test CDROMTest.FindPackages from the apt testsuite then fails.
built with g++ -c -g -O3 -fPIE -fstack-protector-strong -fPIC
upstream writes:
There is a Cdrom wrapper:
"""
class Cdrom : public pkgCdrom {
public:
bool FindPackages(std::string const &CD,
std::vector &List,
std::vector &SList,
std::vector &SigList,
std::vector &TransList,
std::string &InfoDir) {
std::string const startdir = SafeGetCWD();
EXPECT_FALSE(startdir.empty());
bool const result = pkgCdrom::FindPackages(CD, List, SList, SigList,
TransList, InfoDir, NULL, 0);
...
}
"""
and a unittest that calls it:
"""
TEST(CDROMTest,FindPackages)
{
Cdrom cd;
std::string InfoDir;
EXPECT_TRUE(cd.FindPackages(path, Packages, Sources, Signatur, Translation,
InfoDir));
...
EXPECT_EQ(path + "/.disk/", InfoDir);
}
"""
The actual code for this is apt-pkg/cdrom.cc:
"""
bool pkgCdrom::FindPackages(string CD,
vector &List,
vector &SList,
vector &SigList,
vector &TransList,
string &InfoDir, pkgCdromStatus *log,
unsigned int Depth)
{
...
if (DirectoryExists(".disk") == true)
{
if (InfoDir.empty() == true)
InfoDir = CD + ".disk/";
}
...
"""
So I suspect that the optimizer gets confused that InfoDir is a reference or it
gets confused because InfoDir is not used in FindPackages anymore and it
assumes its dead code.
I tried to create a simplified testcase but failed so far. Whats interessting
is that if I add a std::cerr << "debug" line into cdrom.cc lines (or even a "CD
= CD"):
"""
if (DirectoryExists(".disk") == true)
{
if (InfoDir.empty() == true) {
std::cerr << "debug" << std::endl;
InfoDir = CD + ".disk/";
}
}
"""
it works (which indicates dead-code elimination to me).
[Bug target/66866] [miscompile] incorrect load address on manual vector shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66866
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-07-14
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
The gimple looks ok to me:
__m128i shuf(__m128i) (const __m128i v)
{
__m128i r;
__m128i _16;
...
:
_43 = MEM[(const A * {ref-all})&v + 2B];
MEM[(A & {ref-all})&r] = _43;
_47 = MEM[(const A * {ref-all})&v];
MEM[(A & {ref-all})&r + 2] = _47;
_57 = MEM[(const A * {ref-all})&v + 6B];
MEM[(A & {ref-all})&r + 4] = _57;
_61 = MEM[(const A * {ref-all})&v + 4B];
MEM[(A & {ref-all})&r + 6] = _61;
_73 = MEM[(const A * {ref-all})&v + 10B];
MEM[(A & {ref-all})&r + 8] = _73;
_77 = MEM[(const A * {ref-all})&v + 8B];
MEM[(A & {ref-all})&r + 10] = _77;
_87 = MEM[(const A * {ref-all})&v + 14B];
MEM[(A & {ref-all})&r + 12] = _87;
_91 = MEM[(const A * {ref-all})&v + 12B];
MEM[(A & {ref-all})&r + 14] = _91;
_16 = r;
r ={v} {CLOBBER};
return _16;
The assembler is slightly convoluted:
_Z4shufDv2_x:
.LFB527:
.cfi_startproc
movaps %xmm0, -24(%rsp)
movq%xmm0, %rax
movd%xmm0, %edx
pxor%xmm0, %xmm0
sarl$16, %edx
pinsrw $0, %edx, %xmm0
movq%rax, %rdx
sarq$48, %rdx
salq$16, %rax
sarq$48, %rax
pinsrw $1, -24(%rsp), %xmm0
pinsrw $2, %edx, %xmm0
pinsrw $3, %eax, %xmm0
movq-16(%rsp), %rax
movl%eax, %edx
sarl$16, %edx
pinsrw $4, %edx, %xmm0
movq%rax, %rdx
salq$16, %rax
sarq$48, %rdx
sarq$48, %rax
pinsrw $5, -24(%rsp), %xmm0
pinsrw $6, %edx, %xmm0
pinsrw $7, %eax, %xmm0
ret
but the duplicate -24(%rsp) source in the pinsrw instructions looks
suspicious indeed.
Manually unrolling only inlines the function, the function itself is
still miscompiled the same way.
Reduced testcase:
#include
typedef short A __attribute__((__may_alias__));
short extr(const __m128i &d, int index) { return reinterpret_cast(&d)[index]; }
A &extr(__m128i &d, int index) { return reinterpret_cast(&d)[index]; }
__m128i __attribute__((noinline))
shuf(const __m128i v)
{
__m128i r;
extr(r, 5) = extr(v, 4);
return r;
}
int main()
{
__attribute__((aligned(16))) short mem[8];
*reinterpret_cast<__m128i *>(mem) = shuf(_mm_setr_epi16(0, 1, 2, 3, 4, 5, 6,
7));
if (mem[5] != 4)
abort ();
return 0;
}
[Bug tree-optimization/66868] [5/6 Regression] wrong code generated with -O3 (dead code removal?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66868 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- Have you tried to build with -fsanitize=undefined?
[Bug target/66866] [miscompile] incorrect load address on manual vector shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66866
--- Comment #2 from Richard Biener ---
More reduced, fails at -O1:
extern "C" void abort (void);
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
typedef short A __attribute__((__may_alias__));
__m128i __attribute__((noinline))
shuf(const __m128i v)
{
__m128i r;
reinterpret_cast(&r)[5] = reinterpret_cast(&v)[4];
return r;
}
int main()
{
__attribute__((aligned(16))) short mem[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
*reinterpret_cast<__m128i *>(mem) = shuf (*reinterpret_cast<__m128i *>(mem));
if (mem[5] != 4)
abort ();
return 0;
}
_Z4shufDv2_x:
.LFB527:
.cfi_startproc
movaps %xmm0, -24(%rsp)
pxor%xmm0, %xmm0
pinsrw $5, -24(%rsp), %xmm0
ret
[Bug libfortran/66861] [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 --- Comment #5 from Rainer Emrich --- (In reply to Janne Blomqvist from comment #3) > Or rather, also fixing another similar potential issue, you might instead > want to test this: > > diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c > index e5fc6e1..a1ce9a3 100644 > --- a/libgfortran/io/unix.c > +++ b/libgfortran/io/unix.c > @@ -1525,7 +1525,10 @@ compare_file_filename (gfc_unit *u, const char *name, > int len) >goto done; > } > # endif > - ret = (strcmp(path, u->filename) == 0); > + if (u->filename) > +ret = (strcmp(path, u->filename) == 0); > + else > +ret = 0; > #endif > done: >free (path); > @@ -1570,7 +1573,7 @@ find_file0 (gfc_unit *u, FIND_FILE0_DECL) > } >else > # endif > -if (strcmp (u->filename, path) == 0) > +if (u->filename && strcmp (u->filename, path) == 0) >return u; > #endif This solves the issue! Richard set target milestone to 5.2. So I suppose this should go into trunk and the gcc-5 branch.
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #9 from Salvatore Filippone --- (In reply to Salvatore Filippone from comment #8) > (In reply to Paul Thomas from comment #7) > Salvatore Spoke too quickly: I get this linker error ppde3d.f90:(.text+0x9d0): undefined reference to `__psb_error_mod_MOD_psb_perror' ../../lib/libpsb_prec.a(psb_dilu_fct.o): In function `psb_dilu_fct_': psb_dilu_fct.f90:(.text+0x6a0): undefined reference to `__psb_error_mod_MOD_psb_serror' psb_dilu_fct.f90:(.text+0x21db): undefined reference to `__psb_error_mod_MOD_psb_serror' whereas the relevant implementation submodule shows: T __psb_error_impl_mod_MOD_psb_perror 0220 T __psb_error_impl_mod_MOD_psb_serror i.e. the name mangling is going wrong. Salvatore
[Bug target/66866] [miscompile] incorrect load address on manual vector shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66866
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target||x86_64-*-*
CC||uros at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
Expansion is already wrong:
;; MEM[(A * {ref-all})&r + 10B] = _2;
(insn 6 5 7 (set (reg:TI 92)
(subreg:TI (reg/v:V2DI 91 [ v ]) 0)) t.c:8 -1
(nil))
(insn 7 6 8 (set (reg:V8HI 93)
(vec_merge:V8HI (vec_duplicate:V8HI (subreg:HI (reg:TI 92) 0))
(subreg:V8HI (reg/v:V2DI 89 [ r ]) 0)
(const_int 32 [0x20]))) t.c:8 -1
(nil))
(insn 8 7 0 (set (reg/v:V2DI 89 [ r ])
(subreg:V2DI (reg:V8HI 93) 0)) t.c:8 -1
(nil))
(subreg:HI (reg:TI 92) 0) selects the wrong source.
We go
/* In cases where an aligned union has an unaligned object
as a field, we might be extracting a BLKmode value from
an integer-mode (e.g., SImode) object. Handle this case
by doing the extract into an object as wide as the field
(which we know to be the width of a basic mode), then
storing into memory, and changing the mode to BLKmode. */
if (mode1 == VOIDmode
...
op0 = extract_bit_field (op0, bitsize, bitpos, unsignedp,
(modifier == EXPAND_STACK_PARM
? NULL_RTX : target),
ext_mode, ext_mode);
(gdb) p debug_rtx (op0)
(reg/v:V2DI 91 [ v ])
(gdb) p bitsize
$7 = 16
(gdb) p bitpos
$8 = 64
(gdb) p ext_mode
$9 = HImode
which gets us
(gdb) p debug_rtx (op0)
(subreg:HI (reg:TI 92) 8)
so handling the load is fine. Ultimately returned to
#0 0x00c1bf17 in store_field (target=0x76a49d80, bitsize=16,
bitpos=80, bitregion_start=80, bitregion_end=95, mode=HImode,
exp=, alias_set=0, nontemporal=false)
at /space/rguenther/tramp3d/trunk/gcc/expr.c:6643
#1 0x00c1582a in expand_assignment (to=,
from=, nontemporal=false)
at /space/rguenther/tramp3d/trunk/gcc/expr.c:5016
and leading to
#0 store_bit_field_1 (str_rtx=0x76a49d80, bitsize=16, bitnum=80,
bitregion_start=80, bitregion_end=95, fieldmode=HImode,
value=0x76a49f18, fallback_p=true)
at /space/rguenther/tramp3d/trunk/gcc/expmed.c:881
876 /* If OP0 is a multi-word register, narrow it to the affected word.
877 If the region spans two words, defer to store_split_bit_field. */
878 if (!MEM_P (op0) && GET_MODE_SIZE (GET_MODE (op0)) > UNITS_PER_WORD)
879 {
and finally using the insv path.
Breakpoint 7, store_bit_field_using_insv (insv=0x7fffd380,
op0=0x76a49f48, bitsize=16, bitnum=16, value=0x76a49f18)
at /space/rguenther/tramp3d/trunk/gcc/expmed.c:508
508 rtx xop0 = op0;
(gdb) p debug_rtx (op0)
(subreg:DI (reg/v:V2DI 89 [ r ]) 8)
$40 = void
(gdb) p debug_rtx (value)
(subreg:HI (reg:TI 92) 8)
$41 = void
creating insv with
611 create_fixed_operand (&ops[0], xop0);
612 create_integer_operand (&ops[1], bitsize);
613 create_integer_operand (&ops[2], bitnum);
614 create_input_operand (&ops[3], value1, op_mode);
(gdb) p debug_rtx (xop0)
(subreg:DI (reg/v:V2DI 89 [ r ]) 8)
$47 = void
(gdb) p debug_rtx (value1)
(subreg:DI (reg:TI 92) 8)
$48 = void
(gdb) p bitsize
$49 = 16
(gdb) p bitnum
$50 = 16
[Bug target/66866] [miscompile] incorrect load address on manual vector shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66866
--- Comment #4 from Richard Biener ---
bool
ix86_expand_pinsr (rtx *operands)
{
...
if (GET_CODE (src) == SUBREG)
src = SUBREG_REG (src);
and lost SUBREG_OFFSET.
[Bug target/66866] [miscompile] incorrect load address on manual vector shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66866
--- Comment #5 from Richard Biener ---
"Safe" fix:
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 225768)
+++ gcc/config/i386/i386.c (working copy)
@@ -50528,7 +50528,11 @@ ix86_expand_pinsr (rtx *operands)
}
if (GET_CODE (src) == SUBREG)
-src = SUBREG_REG (src);
+{
+ if (SUBREG_BYTE (src) != 0)
+ return false;
+ src = SUBREG_REG (src);
+}
switch (GET_MODE (dst))
{
but with awful consequences for code-generation (-O2, for the reduced
testcase):
_Z4shufDv2_x:
.LFB0:
.cfi_startproc
pxor%xmm1, %xmm1
movabsq $-4294901761, %rdx
movaps %xmm0, -24(%rsp)
movq-16(%rsp), %rax
movaps %xmm1, -24(%rsp)
movzwl %ax, %eax
salq$16, %rax
movq-16(%rsp), %rcx
andq%rcx, %rdx
orq %rax, %rdx
movq%rdx, -16(%rsp)
movdqa -24(%rsp), %xmm0
ret
[Bug tree-optimization/66868] [5/6 Regression] wrong code generated with -O3 (dead code removal?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66868 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.2
[Bug tree-optimization/66868] [5/6 Regression] wrong code generated with -O3 (dead code removal?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66868 --- Comment #2 from Matthias Klose --- the testsuite passes with -fsanitize=undefined (no additional output) and both -fsanitize=undefined -fsanitize-undefined-trap-on-error doesn't abort either.
[Bug libgcc/66854] libgcc2.c:1846:9: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854 Sebastian Huber changed: What|Removed |Added CC||meissner at linux dot vnet.ibm.com --- Comment #1 from Sebastian Huber --- 8b2f7251e4502efddba091ba4468e385ac435b52 is the first bad commit commit 8b2f7251e4502efddba091ba4468e385ac435b52 Author: meissner Date: Thu Jul 9 18:55:01 2015 + 2015-07-09 Michael Meissner * config/rs6000/rs6000-protos.h (rs6000_secondary_reload_memory): Use machine mode, not enum machine_mode in the prototype. * config/rs6000/rs6000.h (FLOAT128_IEEE_P): New helper macros to classify 128-bit floating point support. (FLOAT128_IBM_P): Likewise. (FLOAT128_VECTOR_P): Likewise. (FLOAT128_2REG_P): Likewise. (SCALAR_FLOAT_MODE_NOT_VECTOR_P): Likewise. (SLOW_UNALIGNED_ACCESS): Add IEEE 128-bit floating point support. (HARD_REGNO_CALLER_SAVE_MODE): Likewise. (HARD_REGNO_CALL_PART_CLOBBERED): Likewise. * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Drop tests against TFmode/TDmode, since those modes do not use VSX addresses. (rs6000_hard_regno_mode_ok): Add IEEE 128-bit floating point support. (rs6000_init_hard_regno_mode_ok): Use new helper macros instead of tests against TFmode, etc. (invalid_e500_subreg): Add tests against IFmode/KFmode. (reg_offset_addressing_ok_p): Likewise. (rs6000_legitimate_offset_address_p): Likewise. (rs6000_legitimize_address): Likewise. (rs6000_legitimize_reload_address): Likewise. (rs6000_legitimate_address_p): Clean up tests against TFmode and TDmode to use the new helper macros, which will include IFmode and KFmode. (rs6000_emit_move): Likewise. (rs6000_darwin64_record_arg_recurse): Likewise. (print_operand): Likewise. (rs6000_member_type_forces_blk): Treat IEEE 128-bit floating point that uses a single vector register as a vector and not as a floating point register in terms of the calling sequence. (rs6000_discover_homogeneous_aggregate): Likewise. (rs6000_return_in_memory): Likewise. (init_cumulative_args): Likewise. (rs6000_function_arg_boundary): Likewise. (rs6000_function_arg_advance_1): Likewise. (rs6000_function_arg): Likewise. (rs6000_pass_by_reference): Likewise. (rs6000_gimplify_va_arg): Likewise. (rs6000_secondary_reload_memory): Use machine_mode not enum machine mode. (rs6000_split_multireg_move): Use new helper macros. (spe_func_has_64bit_regs_p): Likewise. (rs6000_output_function_epilogue): Add IFmode/KFmode support. (output_toc): Use new helper macros. (rs6000_register_move_cost): Likewise. (rs6000_function_value): Add IEEE 128-bit floating point calling sequence support. (rs6000_libcall_value): Likewise. (rs6000_scalar_mode_supported_p): Add support for IEEE 128-bit floating point support. (rs6000_vector_mode_supported_p): Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225631 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 20fc90df33f1389e7c30b7b9e2499cb9045f0eca 8dffd9d0aa758f63d522a76fc4edea6a610bc9fc M gcc
[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726 --- Comment #12 from kugan at gcc dot gnu.org --- Created attachment 35976 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35976&action=edit patch for tree-ssa-reassoc Here is a prototype patch (to fix comment 9) that makes tree-ssa-reassoc understand after sinking the casts. Not fully tested yet.
[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834 --- Comment #12 from Andrew Sutton --- > So it seems that applying the DR 1430 tentative resolution to concepts > severely > limits the usability of variadic concepts, and we should reconsider that, so > that instead we delay normalization of template-ids with variadic arguments > until instantiation time. > > The restriction on expansion arguments to non-expansion parameters initially > applied to all variadic templates until N2555, which Eric was also involved > with... I don't think that's a good idea. It means the template-id would be characterized as an atomic constraint for purposes of partial ordering. You lose the ability to order on constraints within the concept, which means you're no better off than using a type trait for the definition. I would make the following observations: 1. Variadics require meteaprogramming and pattern matching 2. The constraint are not intended to be turing complete, so we can't reason about metaprograms 3. There may be useful logical extensions to the constraint language for working with variadics in principled ways 4. Some variadic constraints might be useful as core language constraints (intrinsics). Plus, I have a feeling that I'm going to to have to re-think the entire concept definition and requires-expression bit when we propose concepts for C++. There were too many NB comments to ignore. Andrew
[Bug target/66840] [5/6 Regression] plugins fail to build on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66840 --- Comment #4 from Matthias Klose --- Author: doko Date: Tue Jul 14 13:47:21 2015 New Revision: 225771 URL: https://gcc.gnu.org/viewcvs?rev=225771&root=gcc&view=rev Log: 2015-07-14 Matthias Klose PR target/66840 * config/rs6000/t-rs6000 (TM_H): Add rs6000-cpus.def. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/rs6000/t-rs6000
[Bug target/66840] [5/6 Regression] plugins fail to build on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66840 --- Comment #5 from Matthias Klose --- Author: doko Date: Tue Jul 14 13:50:01 2015 New Revision: 225772 URL: https://gcc.gnu.org/viewcvs?rev=225772&root=gcc&view=rev Log: 2015-07-14 Matthias Klose PR target/66840 * config/rs6000/t-rs6000 (TM_H): Add rs6000-cpus.def. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/t-rs6000
[Bug target/66840] [5/6 Regression] plugins fail to build on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66840 Matthias Klose changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Matthias Klose --- fixed on the gcc-5 branch and the trunk.
[Bug c/66869] New: [6 regression] -Wunused-function no longer warns for static declarations without definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66869 Bug ID: 66869 Summary: [6 regression] -Wunused-function no longer warns for static declarations without definition Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sirl at gcc dot gnu.org Target Milestone: --- Up to gcc-5.1.1 r225711 -Wunused-functions warns like that: > echo 'static void test(void);' | LANG=C gcc-5 -c -Wunused-function -x c - :1:13: warning: 'test' declared 'static' but never defined [-Wunused-function] > But gcc-6.0.0 r225711 remains silent: > echo 'static void test(void);' | LANG=C gcc-6 -c -Wunused-function -x c - > BTW, maybe it would make sense to split out this part from -Wunused-function into a separate -Wstatic-decl-without-def. That's because likely more people would like to turn this part of the warning into an error instead of all of -Wunused-function.
[Bug go/66870] New: split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 Bug ID: 66870 Summary: split stack issues on ppc64le and ppc64 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: boger at us dot ibm.com CC: amodra at gmail dot com, cmang at google dot com, sch...@linux-m68k.org Target Milestone: --- Target: ppc64le, ppc64 Created attachment 35977 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35977&action=edit Detect no_split_stack attribute when generating split stack prologue. There are a few issues to be resolved with the split stack implementation on ppc64le, ppc64, and disabling it correctly when building for ppc (32 bit BE). 1) When building on a system with glibc >= 2.18 and doing a multilib build, the ppc 32 build incorrectly has the split stack flag set, causing an error during the build. This was identified in gcc-patches and a proposed fix suggested: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00963.html https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01038.html (Note: this seems to fix the problem but I don't understand why. The setting of the flag was simply moved past a few statements and I don't see why that should affect the outcome, since the opt argument passed in this case is &global_options.) 2) For functions with the _no_split_stack attribute set, the split stack code generation was not always correct on ppc64le & ppc64. I have a patch for that which is attached. This problem was not obvious when building on ppc64le (where most of my testing was done) but occurs often when built on ppc64. 3) The file gcc/go/gospec.c generates options to be passed to the linker based on a define of #TARGET_CAN_SPLIT_STACK but this define is never set for a build for ppc64le or ppc64. The first occurrence in the function lang_specific_driver generates the fsplit-stack option when calling the linker, the second occurrence sets -Wl,-u pthread_create. I believe the setting of this define has to be consistent with the result of rs6000_supports_split_stack in gcc/common/config/rs6000/rs6000-common.c -- but that function depends on the setting of rs6000_isa_flags which has not been updated by the time lang_specific_driver is called. I'm assuming it is wrong for these options not to be generated and passed to the linker when using split stack? 4) I believe we always want to use the gold linker with gccgo on ppc64le and ppc64 and probably ppc is OK too. This is necessary to get the minimum storage allocated for goroutines (which is the whole point of providing this option) and also prevents errors with split stack that could happen in some cases. I've exchanged some notes with iant on this topic and he suggested this: The -fuse-ld=gold option is newer than gccgo. I suppose it would be nice if: * the GCC configure process checks whether -fuse-ld=gold works; if so: * -fuse-ld=gold is passed to the libgo configure/build >>> I think this is already done by the libgo configure -- or at least it attempts to see if the linker associated with the gccgo it is using to build libgo supports split stack and then sets the flag libgo_cv_c_linker_supports_split_stack and that makes it all work. So if we build gccgo with the gold linker as its linker then this should just work. * -fuse-ld=gold is used by default by the gccgo driver program >>> Not sure how best to do this just for gccgo and not the other gcc compilers. I can keep looking but if anyone has a suggestion let me know. There are probably other creative ways to do this by setting spec defines that are only available for ppc64le, ppc64 builds but haven't figured it out yet.
[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834 --- Comment #13 from Jason Merrill --- (In reply to Andrew Sutton from comment #12) > I don't think that's a good idea. It means the template-id would be > characterized as an atomic constraint for purposes of partial > ordering. You lose the ability to order on constraints within the > concept, which means you're no better off than using a type trait for > the definition. True, I guess it's a trade-off between power and ease of use. Should I re-apply the change to coerce_template_parms?
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #1 from Ian Lance Taylor --- The various issues in this bug are in different parts of the code base. The bug is assigned to me, but, to be clear, I have no plans to work on anything in the PPC-specific code. For x86, TARGET_CAN_SPLIT_STACK is defined in gcc/config/i386/gnu-user-common.h. The intent of the code in gospec.c is to pass -fsplit-stack and -Wl,-u,pthread_create when linking. When compiling, split stack is turned on by the code in go_langhook_init_options_struct in gcc/go/go-lang.c. When linking, we want to pass -fsplit-stack so that gcc/gcc.c uses STACK_SPLIT_SPEC. If the target defines TARGET_CAN_SPLIT_STACK for all cases where it might support it, I think the code will more or less work even for cases where split stack is not supported. If we don't pass those options, then the split-stack code will not work entirely correctly because new threads won't know their stack size.
[Bug middle-end/18355] [4.0 regression] cross toolchains don't build libstdc++: m32r-elf v850-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18355 --- Comment #2 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Jul 14 15:03:11 2015 New Revision: 225776 URL: https://gcc.gnu.org/viewcvs?rev=225776&root=gcc&view=rev Log: Sync toplevel files binutils-gdb Sync with binutils-gdb: 2015-05-01 H.J. Lu PR ld/18355 * Makefile.def: Add extra_configure_flags to host zlib. * configure.ac (extra_host_zlib_configure_flags): New. Set to --enable-host-shared When bfd is to be built as shared library. AC_SUBST. * Makefile.in: Regenerated. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/configure trunk/configure.ac
[Bug libgcc/66854] libgcc2.c:1846:9: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854 Michael Meissner changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #2 from Michael Meissner --- What options did you use to configure the compiler with? Are the RTEMS include files and libraries available on the internet so that I can try to build a cross compiler to debug the problem?
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #2 from boger at us dot ibm.com --- (In reply to Ian Lance Taylor from comment #1) > The various issues in this bug are in different parts of the code base. The > bug is assigned to me, but, to be clear, I have no plans to work on anything > in the PPC-specific code. > Understood. > For x86, TARGET_CAN_SPLIT_STACK is defined in > gcc/config/i386/gnu-user-common.h. The intent of the code in gospec.c is to > pass -fsplit-stack and -Wl,-u,pthread_create when linking. When compiling, > split stack is turned on by the code in go_langhook_init_options_struct in > gcc/go/go-lang.c. When linking, we want to pass -fsplit-stack so that > gcc/gcc.c uses STACK_SPLIT_SPEC. If the target defines > TARGET_CAN_SPLIT_STACK for all cases where it might support it, I think the > code will more or less work even for cases where split stack is not > supported. If we don't pass those options, then the split-stack code will > not work entirely correctly because new threads won't know their stack size. In gcc.c there is STACK_SPLIT_SPEC which sets --wrap=pthread_create in the LINK_COMMAND_SPEC if -fsplit-stack is set. Is there a reason there are 2 different split stack dependent link options are being set in two different ways?
[Bug preprocessor/66871] New: .incbin in .S files does not appear in automatically generated dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66871 Bug ID: 66871 Summary: .incbin in .S files does not appear in automatically generated dependencies Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: dwmw2 at infradead dot org Target Milestone: --- $ cat foo.S .incbin "foo.bin" $ gcc -Wp,-MD,foo.d -o foo.o -c foo.S $ cat foo.d foo.o: foo.S /usr/include/stdc-predef.h $ Why is 'foo.bin' not included in the dependencies?
[Bug preprocessor/66871] .incbin in .S files does not appear in automatically generated dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66871 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Because you are not using a preprocessor directive to include the file, instead you are using an assembly directive to that.
[Bug fortran/66864] floor function error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66864
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-07-14
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||4.7.4, 4.8.5, 4.9.3, 5.1.1,
||6.0
--- Comment #1 from kargl at gcc dot gnu.org ---
It seems constant folding in simplify.c may be broken. Here's
a testcase suitable for the testsuite once the bug is fixed.
! { dg-do run }
! PR fortran/66864
!
program t
implicit none
real(8) x
x = 2.0d0**26.5d0
if (floor(x) /= 94906265) call abort
if (floor(2.0d0**26.5d0)/= 94906265) call abort
x = 777666555.6d0
if (floor(x) /= 777666555) call abort
if (floor(777666555.6d0) /= 777666555) call abort
x = 2000111222.6d0
if (floor(x) /= 2000111222) call abort
if (floor(2000111222.6d0) /= 2000111222) call abort
end program t
[Bug preprocessor/66871] .incbin in .S files does not appear in automatically generated dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66871 --- Comment #2 from David Woodhouse --- It would still be extremely useful for it to emit dependencies on those files which are actually included (after preprocessing). Otherwise we end up screwing around with preprocessing it and then looking for '.incbin' and generating the full set of dependencies manually. Which is horrid.
[Bug middle-end/66872] New: fold a & ((1 << b) - 1) to a & ~(-1 << b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66872
Bug ID: 66872
Summary: fold a & ((1 << b) - 1) to a & ~(-1 << b)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bonzini at gnu dot org
Target Milestone: ---
This can save one or two instructions on some architectures. For example, when
compiling
int f(int x, int t)
{
return x & ((1 << t) - 1);
}
vs.
int f(int x, int t)
{
return x & ~(-1 << t);
}
with -march=haswell you get before:
movl$1, %edx
shlx%esi, %edx, %esi
subl$1, %esi # not sure why no lea here?
movl%esi, %eax
andl%edi, %eax
ret
and after:
movl$-1, %edx
shlx%esi, %edx, %esi
andn%edi, %esi, %eax
ret
Even if you account for the strange register allocation in the first assembly
listing, using andn can save one instruction. Also, with -mtune=generic the
size is the same. Before:
movl%esi, %ecx
movl$1, %edx
sall%cl, %edx
subl$1, %edx
movl%edx, %eax
andl%edi, %eax
ret
After:
movl%esi, %ecx
movl$-1, %edx
sall%cl, %edx
notl%edx
movl%edx, %eax
andl%edi, %eax
ret
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #3 from Ian Lance Taylor --- > In gcc.c there is STACK_SPLIT_SPEC which sets --wrap=pthread_create in the > LINK_COMMAND_SPEC if -fsplit-stack is set. Is there a reason there are 2 > different split stack dependent link options are being set in two different > ways? Sort of. All uses of -fsplit-stack can and should pass -Wl,--wrap=pthread_create to the linker. That option does nothing if the program is not threaded. If the program is threaded it will cause the code in libgcc/generic-morestack-thread.c to be used. All uses of -fsplit-stack and -static for threaded code should pass -Wl,-u,pthread_create to the linker. Otherwise, in some cases, we may not pull in the threading functions we need. But, unlike the --wrap option, if the program is not threaded, and not linked against -lpthread, this option will cause the link to fail. Go programs are always threaded, so it's safe to add this in gospec.c. It's not safe to add it in a link spec in gcc.c, unless we have some way of determining from the link spec whether the program is threaded. (There is some discussion of why this is needed at https://groups.google.com/d/msg/golang-nuts/y2RIy0XLJ24/uFIdOE8wPL8J .)
[Bug fortran/66864] floor function error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66864 --- Comment #2 from Steve Kargl --- On Tue, Jul 14, 2015 at 05:03:55PM +, kargl at gcc dot gnu.org wrote: > > --- Comment #1 from kargl at gcc dot gnu.org --- > It seems constant folding in simplify.c may be broken. Here's > a testcase suitable for the testsuite once the bug is fixed. I have a patch.
[Bug fortran/66864] floor function error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66864 --- Comment #3 from Steve Kargl --- On Tue, Jul 14, 2015 at 07:02:32PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66864 > > --- Comment #2 from Steve Kargl --- > On Tue, Jul 14, 2015 at 05:03:55PM +, kargl at gcc dot gnu.org wrote: > > > > --- Comment #1 from kargl at gcc dot gnu.org --- > > It seems constant folding in simplify.c may be broken. Here's > > a testcase suitable for the testsuite once the bug is fixed. > > I have a patch. > Patch posted. https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01193.html
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #4 from Andreas Schwab --- > past a few statements Huh??
[Bug libfortran/66861] [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 --- Comment #6 from Janne Blomqvist --- Author: jb Date: Tue Jul 14 20:26:06 2015 New Revision: 225788 URL: https://gcc.gnu.org/viewcvs?rev=225788&root=gcc&view=rev Log: PR 66861 Fix null pointer crash on mingw. 2015-07-14 Janne Blomqvist PR libfortran/66861 * io/unix.c (compare_file_filename): Verify that u->filename is non-NULL before strcmp. (find_file0): Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c
[Bug libfortran/66861] [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 --- Comment #7 from Janne Blomqvist --- Fixed on trunk. I'm not sure if the milestone thing implies an Ok to commit to the gcc-5 branch, as we're already on 5.2 rc2, I'll ask explicitly for an Ok.
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #5 from boger at us dot ibm.com --- (In reply to Andreas Schwab from comment #4) > > past a few statements > > Huh?? Here is your patch diff --git a/gcc/go/go-lang.c b/gcc/go/go-lang.c index ce4dd9b..d952e0f 100644 --- a/gcc/go/go-lang.c +++ b/gcc/go/go-lang.c @@ -158,10 +158,6 @@ go_langhook_init_options_struct (struct gcc_options *opts) opts->x_flag_errno_math = 0; opts->frontend_set_flag_errno_math = true; - /* We turn on stack splitting if we can. */ - if (targetm_common.supports_split_stack (false, opts)) -opts->x_flag_split_stack = 1; - /* Exceptions are used to handle recovering from panics. */ opts->x_flag_exceptions = 1; opts->x_flag_non_call_exceptions = 1; @@ -295,6 +291,11 @@ go_langhook_post_options (const char **pfilename ATTRIBUTE_UNUSED) && global_options.x_write_symbols == NO_DEBUG) global_options.x_write_symbols = PREFERRED_DEBUGGING_TYPE; + /* We turn on stack splitting if we can. */ + if (!global_options_set.x_flag_split_stack + && targetm_common.supports_split_stack (false, &global_options)) +global_options.x_flag_split_stack = 1; + /* Returning false means that the backend should be used. */ return false; } Your change moved the if statement containing the call to targetm_common.supports_split_stack to a different location in the file (past a few statements) and re-added them along with a check for global_options_set.x_flag_split_stack. It looks to me that the values in the rs6000_isa_flags are still the same whether you call supports_split_stack where it was or where you moved it to. I'm trying to fix some of the other issues mentioned in this bugzilla and even with your fix I sometimes hit the original problem when building with m32.
[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3 or -miamcu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66626 --- Comment #19 from Vladimir Makarov --- Author: vmakarov Date: Tue Jul 14 20:54:00 2015 New Revision: 225789 URL: https://gcc.gnu.org/viewcvs?rev=225789&root=gcc&view=rev Log: 2015-07-14 Vladimir Makarov PR rtl-optimization/66626 * lra-constraints.c (lra_constraints): Prevent equivalence substitution for static chain pseudo in functions with nonlocal goto. 2015-07-14 Vladimir Makarov PR rtl-optimization/66626 * gcc.target/i386/pr66626.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr66626.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug c++/65091] decltype(~arg) fails for template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65091 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- Mine again.
[Bug libgcc/66854] libgcc2.c:1846:9: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854 --- Comment #3 from Michael Meissner --- Created attachment 35978 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35978&action=edit Proposed patch to fix the problem I believe this patch fixes the problem. I was able to build libgcc with this patch installed. I could not complete a full RTEMS build (I suspect I am missing some parts of the software).
[Bug fortran/66864] floor function error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66864 --- Comment #4 from Steve Kargl --- On Tue, Jul 14, 2015 at 12:31:11PM -0700, Steve Kargl wrote: > On Tue, Jul 14, 2015 at 07:02:32PM +, sgk at troutmask dot > apl.washington.edu wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66864 > > > > --- Comment #2 from Steve Kargl > > --- > > On Tue, Jul 14, 2015 at 05:03:55PM +, kargl at gcc dot gnu.org wrote: > > > > > > --- Comment #1 from kargl at gcc dot gnu.org --- > > > It seems constant folding in simplify.c may be broken. Here's > > > a testcase suitable for the testsuite once the bug is fixed. > > > > I have a patch. > > > > Patch posted. > > https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01193.html > I committed the patch to trunk, but forgot to include the PR number in the ChangeLog entry.
[Bug fortran/66175] ICE in gfc_free_namespace with unbalanced BLOCKs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66175 Louis Krupp changed: What|Removed |Added CC||t56xjcu6dh at snkmail dot com --- Comment #1 from Louis Krupp --- Created attachment 35979 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35979&action=edit Suggested patch for 66175 Recovery from nested incomplete BLOCKs
[Bug rtl-optimization/66865] [6 Regression] wine segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #3 from marcus at jet dot franken.de --- dlls/ntdll/sec.c, and probably RtlConvertSidToUnicodeString is miscompiled... looking further.
[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3 or -miamcu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66626 --- Comment #20 from H.J. Lu --- Testcase in comment #1 still fails with r225789.
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #6 from Andreas Schwab --- > (past a few statements) Huh? @@ -158,10 +158,6 @@ go_langhook_init_options_struct (struct gcc_options *opts) @@ -295,6 +291,11 @@ go_langhook_post_options (const char **pfilename
[Bug c++/65071] ICE on valid, sizeof...() of template template parameter pack in return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65071 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Jul 14 22:36:50 2015 New Revision: 225793 URL: https://gcc.gnu.org/viewcvs?rev=225793&root=gcc&view=rev Log: /cp 2015-07-14 Andrea Azzarone PR c++/65071 * parser.c (cp_parser_sizeof_pack): Also consider template template parameters. /testsuite 2015-07-14 Andrea Azzarone PR c++/65071 * g++.dg/cpp0x/vt-65071.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-65071.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/65071] ICE on valid, sizeof...() of template template parameter pack in return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65071 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #5 from Paolo Carlini --- Fixed.
[Bug tree-optimization/66873] New: fortran variant of outer-1.c not parallelized by autopar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873
Bug ID: 66873
Summary: fortran variant of outer-1.c not parallelized by
autopar
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this example, a fortran version of autopar/outer-1.c:
...
program main
implicit none
integer, parameter :: n = 500
integer, dimension (0:n-1, 0:n-1) :: x
integer:: i, j, ii, jj
do ii = 0, n - 1
do jj = 0, n - 1
x(ii, jj) = ii + jj + 3
end do
end do
do i = 0, n - 1
do j = 0, n - 1
if (x(i, j) .ne. i + j + 3) call abort
end do
end do
end program main
...
When trying to parallelize this using -O2 -ftree-parallelize-loops=2, it fails
on the dependencies:
...
(Data Dep:
#(Data Ref:
# bb: 4
# stmt: x[_12] = _14;
# ref: x[_12];
# base_object: x;
# Access function 0: {{0, +, 1}_3, +, 500}_4
#)
#(Data Ref:
# bb: 4
# stmt: x[_12] = _14;
# ref: x[_12];
# base_object: x;
# Access function 0: {{0, +, 1}_3, +, 500}_4
#)
access_fn_A: {{0, +, 1}_3, +, 500}_4
access_fn_B: {{0, +, 1}_3, +, 500}_4
(subscript
iterations_that_access_an_element_twice_in_A: [0]
last_conflict: scev_not_known
iterations_that_access_an_element_twice_in_B: [0]
last_conflict: scev_not_known
(Subscript distance: 0 ))
inner loop index: 0
loop nest: (3 4 )
distance_vector: 0 0
distance_vector: 500 -1
direction_vector: ==
direction_vector: +-
)
FAILED: data dependencies exist across iterations
...
[Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873
vries at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from vries at gcc dot gnu.org ---
Once noticeable difference with outer-1.c, is that pass_iv_canon make the inner
and outer loop ivs run downwards (from 500 to 0).
Removing pass_iv_canon from the pass list fixes that, but doesn't change
anything about the dependency analysis in parloops:
...
(Data Dep:
#(Data Ref:
# bb: 4
# stmt: x[_12] = _14;
# ref: x[_12];
# base_object: x;
# Access function 0: {{0, +, 1}_3, +, 500}_4
#)
#(Data Ref:
# bb: 4
# stmt: x[_12] = _14;
# ref: x[_12];
# base_object: x;
# Access function 0: {{0, +, 1}_3, +, 500}_4
#)
access_fn_A: {{0, +, 1}_3, +, 500}_4
access_fn_B: {{0, +, 1}_3, +, 500}_4
(subscript
iterations_that_access_an_element_twice_in_A: [0]
last_conflict: scev_not_known
iterations_that_access_an_element_twice_in_B: [0]
last_conflict: scev_not_known
(Subscript distance: 0 ))
inner loop index: 0
loop nest: (3 4 )
distance_vector: 0 0
distance_vector: 500 -1
direction_vector: ==
direction_vector: +-
)
FAILED: data dependencies exist across iterations
...
[Bug rtl-optimization/66865] [6 Regression] wine segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #4 from kugan at gcc dot gnu.org --- Ok, I downloaded wine-1.7.47.tar.bz2 and built it with trunk gcc. What do I have to do to reproduce this please?
[Bug rtl-optimization/66865] [6 Regression] wine64 segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 austinenglish at gmail dot com changed: What|Removed |Added Summary|[6 Regression] wine |[6 Regression] wine64 |segfaults from gcc in trunk |segfaults from gcc in trunk |(r225757) (regression) |(r225757) (regression) --- Comment #5 from austinenglish at gmail dot com --- (In reply to kugan from comment #4) > Ok, I downloaded wine-1.7.47.tar.bz2 and built it with trunk gcc. What do I > have to do to reproduce this please? Sorry, forgot to specify it only happens with wine64. In any case, to reproduce: tar xjvf wine-1.7.47.tar.bz2 cd wine ./configure --enable-win64 --disable-tests make -j4 ./wine wineboot Expected behavior: wineboot runs to completion, exits 0 Actual behavior: wine segfaults as I pointed out previously, if you don't apply the patch for bug 66838, you will likely see that wine crashes instead of exiting 0 (but you will only see that with the cprop.c changes reverted) Hope that helps, please let me know if anything is unclear.
[Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873
--- Comment #2 from vries at gcc dot gnu.org ---
Another obvious difference is that the fortran 2-dimensional array access is
rewritten into a single dimension array access:
...
:
# ii_7 = PHI <0(2), ii_16(7)>
pretmp_52 = (integer(kind=8)) ii_7;
pretmp_53 = pretmp_52 * 500;
:
# jj_10 = PHI <0(3), jj_15(5)>
_11 = (integer(kind=8)) jj_10;
_12 = _11 + pretmp_53;
_13 = ii_7 + jj_10;
_14 = _13 + 3;
x[_12] = _14;
jj_15 = jj_10 + 1;
if (jj_10 == 499)
goto ;
else
goto ;
...
While the outer-1.c 2-dimensional array access is still 2-dimensional:
...
:
# i_34 = PHI <0(3), i_15(8)>
goto ;
:
# j_36 = PHI <0(9), j_14(4)>
_11 = i_34 + j_36;
_12 = _11 + 3;
x[i_34][j_36] = _12;
j_14 = j_36 + 1;
if (N_9(D) > j_14)
goto ;
else
goto ;
...
Which results in different access functions, and the dependence analysis
succeeds:
...
(Data Dep:
#(Data Ref:
# bb: 5
# stmt: x[i_34][j_36] = _12;
# ref: x[i_34][j_36];
# base_object: x;
# Access function 0: {0, +, 1}_4
# Access function 1: {0, +, 1}_1
#)
#(Data Ref:
# bb: 5
# stmt: x[i_34][j_36] = _12;
# ref: x[i_34][j_36];
# base_object: x;
# Access function 0: {0, +, 1}_4
# Access function 1: {0, +, 1}_1
#)
access_fn_A: {0, +, 1}_4
access_fn_B: {0, +, 1}_4
(subscript
iterations_that_access_an_element_twice_in_A: [0]
last_conflict: scev_not_known
iterations_that_access_an_element_twice_in_B: [0]
last_conflict: scev_not_known
(Subscript distance: 0 ))
access_fn_A: {0, +, 1}_1
access_fn_B: {0, +, 1}_1
(subscript
iterations_that_access_an_element_twice_in_A: [0]
last_conflict: scev_not_known
iterations_that_access_an_element_twice_in_B: [0]
last_conflict: scev_not_known
(Subscript distance: 0 ))
inner loop index: 0
loop nest: (1 4 )
distance_vector: 0 0
direction_vector: ==
)
SUCCESS: may be parallelized
...
[Bug rtl-optimization/66865] [6 Regression] wine64 segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #6 from marcus at jet dot franken.de --- Created attachment 35980 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35980&action=edit foo.patch the comment out TRACE() makes the function RtlConvertSidToUnicodeString build correctly. if not built correctly, it will crash instead.
[Bug rtl-optimization/66865] [6 Regression] wine64 segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #7 from marcus at jet dot franken.de --- (can continue to work on this tomorrow. good night)
[Bug rtl-optimization/66865] [6 Regression] wine64 segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #8 from marcus at jet dot franken.de --- FWIW, it seems it is thinking that %rsi stays alive over sprintfW calls. leaqformatW.23952(%rip), %rsi #, movzbl (%r14), %edx# MEM[(const struct SID *)pSid_9(D)].Revision, D.26187 leaq2(%r13), %rbx #, tmp159 .loc 1 1767 0 movw%ax, 48(%rsp) #, MEM[(WCHAR *)&buffer] .loc 1 1768 0 xorl%eax, %eax # movq%rbx, %rdi # tmp159, callsprintfW@PLT# .LVL800: .loc 1 1769 0 movzbl 4(%r14), %edx # MEM[(const struct SID *)pSid_9(D)].IdentifierAuthority.Value, D.26187 .loc 1 1768 0 cltq .loc 1 1769 0 movzbl 7(%r14), %ecx # MEM[(const struct SID *)pSid_9(D)].IdentifierAuthority.Value, D.26189 .loc 1 1768 0 leaq(%rbx,%rax,2), %rbx #, p .LVL801: .loc 1 1769 0 movzbl 5(%r14), %eax # MEM[(const struct SID *)pSid_9(D)].IdentifierAuthority.Value, D.26189 movq%rbx, %rdi # p, sall$8, %edx#, D.26187 orl %eax, %edx # D.26189, D.26189 movzbl 6(%r14), %eax # MEM[(const struct SID *)pSid_9(D)].IdentifierAuthority.Value, D.26187 sall$16, %edx #, D.26191 sall$8, %eax#, D.26187 orl %ecx, %eax # D.26189, D.26189 movzwl %ax, %eax # D.26189, D.26191 orl %eax, %edx # D.26191, D.26191 xorl%eax, %eax # callsprintfW@PLT# %rsi seems expected at this last sprintfW, but is already clobbered by the previous one. We had two of these bugs already.
[Bug rtl-optimization/66865] [6 Regression] wine64 segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #9 from marcus at jet dot franken.de --- Created attachment 35981 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35981&action=edit sec.s.good good assembly (with TRACE)
[Bug rtl-optimization/66865] [6 Regression] wine64 segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #10 from marcus at jet dot franken.de --- Created attachment 35982 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35982&action=edit sec.s.bad bad assembly. %rsi not restored with formatW
[Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873
--- Comment #3 from vries at gcc dot gnu.org ---
The fortran example succeeds when floop-parallelize-all is used.
Even though the access function in graphite seems the same:
...
Access function 0: {{0, +, 1}_3, +, 500}_4
...
[Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873 --- Comment #4 from vries at gcc dot gnu.org --- Created attachment 35983 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35983&action=edit Tentative patch Using this tentative patch, we use graphite analysis (if available) by default for parloops. That way, we manage to parallelize the fortran example using just -ftree-parallelize-loops=2.
[Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to vries from comment #0) > Consider this example, a fortran version of autopar/outer-1.c: > ... > program main > implicit none > integer, parameter :: n = 500 > integer, dimension (0:n-1, 0:n-1) :: x > integer:: i, j, ii, jj > > do ii = 0, n - 1 > do jj = 0, n - 1 > x(ii, jj) = ii + jj + 3 > end do > end do > > do i = 0, n - 1 > do j = 0, n - 1 > if (x(i, j) .ne. i + j + 3) call abort > end do > end do > > end program main > ... > > When trying to parallelize this using -O2 -ftree-parallelize-loops=2, it > fails on the dependencies: Does the loop ordering matter? Fortran is a column major language, so your nested loops are backwards. One would normally write. do jj = 0, n - 1 do ii = 0, n - 1 x(ii, jj) = ii + jj + 3 end do end do where the first loop index varies most rapidly.
[Bug libgcc/66874] New: RFE: x86_64_fallback_frame_state more robust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874 Bug ID: 66874 Summary: RFE: x86_64_fallback_frame_state more robust Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: jreiser at bitwagon dot com Target Milestone: --- In libgcc/config/i386/linux-unwind.h function x86_64_fallback_frame_state() please check the value of pc before accessing memory in the statement: - unsigned char *pc = context->ra; // snip if (*(unsigned char *)(pc+0) == 0x48 && *(unsigned long long *)(pc+1) == RT_SIGRETURN_SYSCALL) - I have seen pc values of 0, 2, 0x, etc due to missing or incorrect debug info, particularly when the code that is being unwound was compiled with no frame pointer, or was compiled by other compilers. The result is SIGSEGV, which is a major disappointment. I suggest a check in the spirit of: if ((unsigned long)pc < 4096) return _URC_END_OF_STACK; or similar. Obviously this is heuristic, but it is much better than SIGSEGV.
[Bug c++/66850] Adding a forward declaration of a template containing a template template parm causes ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66850 --- Comment #3 from Patrick Palka --- Author: ppalka Date: Wed Jul 15 00:01:21 2015 New Revision: 225801 URL: https://gcc.gnu.org/viewcvs?rev=225801&root=gcc&view=rev Log: Fix PR c++/66850 gcc/cp/ChangeLog: PR c++/66850 * pt.c (redeclare_class_template): Set the DECL_CONTEXTs of each template template parm in the redeclaration. (lookup_template_class_1): Peel off irrelevant template levels from current_template_parms before augmenting the argument list. gcc/testsuite/ChangeLog: PR c++/66850 * g++.dg/template/pr66850.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/pr66850.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/66872] fold a & ((1 << b) - 1) to a & ~(-1 << b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66872 James Almer changed: What|Removed |Added CC||jamrial at gmail dot com --- Comment #1 from James Almer --- Ideally, for -mbmi2 (which is enabled with -march=haswell) the compiler should generate a single bzhi instruction instead, as i mentioned in pr65871. The generated code for your example would then be bzhi%esi, %edi, %eax ret Also, left shift of negative value is undefined behavior in C. Try compiling that code with -Wshift-negative-value using gcc trunk.
[Bug c++/66850] Adding a forward declaration of a template containing a template template parm causes ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66850 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Patrick Palka --- Fixed.
[Bug c++/66850] Adding a forward declaration of a template containing a template template parm causes ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66850 --- Comment #5 from Patrick Palka --- Fixed.
[Bug libgcc/66874] RFE: x86_64_fallback_frame_state more robust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-15 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- I have seen bogus PC like 0xffb2 on i386: https://sourceware.org/bugzilla/show_bug.cgi?id=18635
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-15 Ever confirmed|0 |1 --- Comment #7 from Alan Modra --- The attached patch looks good, but it would be slightly better if the condition "flags_split_stack && lookup_attribute (...) == 0" were used throughout rs6000_emit_prologue. Probably best implemented by assigning a new auto var at the start of rs6000_emit_prologue then using that in place of flag_split_stack.
[Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873
--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to kargl from comment #5)
> Does the loop ordering matter? Fortran is a column major language,
> so your nested loops are backwards. One would normally write.
>
> do jj = 0, n - 1
> do ii = 0, n - 1
> x(ii, jj) = ii + jj + 3
> end do
>end do
>
> where the first loop index varies most rapidly.
Thanks for letting me know. I'm obviously not fluent in Fortran.
Interchanging ii and jj in the array access of the example, and again disabling
pass_iv_canon, gives:
...
(Data Dep:
#(Data Ref:
# bb: 4
# stmt: x[_12] = _14;
# ref: x[_12];
# base_object: x;
# Access function 0: {{0, +, 500}_3, +, 1}_4
#)
#(Data Ref:
# bb: 4
# stmt: x[_12] = _14;
# ref: x[_12];
# base_object: x;
# Access function 0: {{0, +, 500}_3, +, 1}_4
#)
access_fn_A: {{0, +, 500}_3, +, 1}_4
access_fn_B: {{0, +, 500}_3, +, 1}_4
(subscript
iterations_that_access_an_element_twice_in_A: [0]
last_conflict: scev_not_known
iterations_that_access_an_element_twice_in_B: [0]
last_conflict: scev_not_known
(Subscript distance: 0 ))
inner loop index: 0
loop nest: (3 4 )
distance_vector: 0 0
distance_vector: 1 -500
direction_vector: ==
direction_vector: +-
)
FAILED: data dependencies exist across iterations
...
Again, using -floops-parallelize-all allows the outer loop to be paralelized.
[Bug middle-end/66872] fold a & ((1 << b) - 1) to a & ~(-1 << b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66872 --- Comment #2 from Paolo Bonzini --- > left shift of negative value is undefined behavior in C It's not in any of GCC's intermediate representations, though.
[Bug rtl-optimization/66865] [6 Regression] wine64 segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #11 from marcus at jet dot franken.de --- Created attachment 35984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35984&action=edit 707.c delta reduced testcase. gcc -O2 -fPIC -c 707.c
