RE: Question about omp-low.c
-Original Message-
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: Thursday, December 19, 2013 2:40 AM
To: Iyer, Balaji V
Cc: Jason Merrill (ja...@redhat.com); 'gcc@gcc.gnu.org'
Subject: Re: Question about omp-low.c
On Thu, Dec 19, 2013 at 05:14:16AM +, Iyer, Balaji V wrote:
I looked into this, but the issue I have is, for the following code:
Int main (void) {
_Cilk_for (int ii = W; ii (X+Y); ii = ii + (q+z))
This doesn't have a body, Int won't compile either. Can you post -fdump-
tree-{original,gimple,omplower,ompexp} dump for some short simple
testcase just to see what design decisions you've made so far? Perhaps
something should be reconsidered...
Yes I didn't put a body because it wasn't relevant for what I was talking
about. I wanted to talk about parameters of the _Cilk_for. The body should be
pushed into the child function and that is straight forward.
Int is int after Outlook decided to capitalize it :-) and I forgot to undo it
:-(
Jakub
gcc-4.8-20131219 is now available
Snapshot gcc-4.8-20131219 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20131219/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 206135 You'll find: gcc-4.8-20131219.tar.bz2 Complete GCC MD5=666ef08f87649f941bc5512e13a88fdc SHA1=37ab603250d7b68ae3a4a909b811a42720f2518e Diffs from 4.8-20131212 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Remove spam in GCC mailing list
More spam posts to be removed! http://gcc.gnu.org/ml/gcc/2003-12/msg00883.html http://gcc.gnu.org/ml/gcc/2004-01/msg00649.html http://gcc.gnu.org/ml/gcc/2004-01/msg00650.html http://gcc.gnu.org/ml/gcc/2004-01/msg00651.html http://gcc.gnu.org/ml/gcc/2005-05/msg00686.html http://gcc.gnu.org/ml/gcc/2005-05/msg00687.html http://gcc.gnu.org/ml/gcc/2005-05/msg00689.html http://gcc.gnu.org/ml/gcc/2005-05/msg00690.html http://gcc.gnu.org/ml/gcc/2005-05/msg00692.html http://gcc.gnu.org/ml/gcc/2005-05/msg00693.html http://gcc.gnu.org/ml/gcc/2005-05/msg00694.html http://gcc.gnu.org/ml/gcc/2005-05/msg00695.html http://gcc.gnu.org/ml/gcc/2005-05/msg00696.html http://gcc.gnu.org/ml/gcc/2005-05/msg00697.html http://gcc.gnu.org/ml/gcc/2005-05/msg00698.html http://gcc.gnu.org/ml/gcc/2005-05/msg00699.html http://gcc.gnu.org/ml/gcc/2005-05/msg00700.html http://gcc.gnu.org/ml/gcc/2005-05/msg00701.html http://gcc.gnu.org/ml/gcc/2005-05/msg00702.html http://gcc.gnu.org/ml/gcc/2005-05/msg00704.html http://gcc.gnu.org/ml/gcc/2005-05/msg00705.html http://gcc.gnu.org/ml/gcc/2005-05/msg00709.html http://gcc.gnu.org/ml/gcc/2005-05/msg00710.html http://gcc.gnu.org/ml/gcc/2005-05/msg00711.html http://gcc.gnu.org/ml/gcc/2005-05/msg00713.html http://gcc.gnu.org/ml/gcc/2005-05/msg00715.html http://gcc.gnu.org/ml/gcc/2005-05/msg00716.html http://gcc.gnu.org/ml/gcc/2005-05/msg00717.html http://gcc.gnu.org/ml/gcc/2005-05/msg00721.html http://gcc.gnu.org/ml/gcc/2005-05/msg00726.html http://gcc.gnu.org/ml/gcc/2005-05/msg00731.html http://gcc.gnu.org/ml/gcc/2005-05/msg00737.html http://gcc.gnu.org/ml/gcc/2005-05/msg00738.html http://gcc.gnu.org/ml/gcc/2005-05/msg00742.html http://gcc.gnu.org/ml/gcc/2005-05/msg00744.html http://gcc.gnu.org/ml/gcc/2005-05/msg00745.html http://gcc.gnu.org/ml/gcc/2005-05/msg00747.html http://gcc.gnu.org/ml/gcc/2005-05/msg00749.html http://gcc.gnu.org/ml/gcc/2005-05/msg00752.html http://gcc.gnu.org/ml/gcc/2005-05/msg00753.html http://gcc.gnu.org/ml/gcc/2005-05/msg00755.html http://gcc.gnu.org/ml/gcc/2005-05/msg00757.html http://gcc.gnu.org/ml/gcc/2005-05/msg00758.html A. Julliard removed posting permissions for wine-devel for the seotaewong40 at gmail.com email address. You log on as seotaewong40 in Mozilla Bugzilla. And you get message account disabled. Please enable your account from Mozilla Bugzilla. -- Tae-Wong Seo Korea, Republic of
Re: Remove spam in GCC mailing list
On 19 December 2013 23:15, Tae Wong wrote: More spam posts to be removed! Using an email address with seo in it makes you look like a spammer. Posting links to spam makes you look like a spammer. Posting meaningless crap about mozilla bugzilla permissions and wine-devel makes you look like a bot. Can we ban this sender?
Re: Remove spam in GCC mailing list
On Fri, 2013-12-20 at 00:04 +, Jonathan Wakely wrote: On 19 December 2013 23:15, Tae Wong wrote: More spam posts to be removed! Using an email address with seo in it makes you look like a spammer. Posting links to spam makes you look like a spammer. Posting meaningless crap about mozilla bugzilla permissions and wine-devel makes you look like a bot. Can we ban this sender? Agreed, FWIW see also: https://mail.python.org/pipermail/python-dev/2013-December/130727.html
Re: Remove spam in GCC mailing list
On 20 December 2013 01:12, David Malcolm wrote: On Fri, 2013-12-20 at 00:04 +, Jonathan Wakely wrote: On 19 December 2013 23:15, Tae Wong wrote: More spam posts to be removed! Using an email address with seo in it makes you look like a spammer. Posting links to spam makes you look like a spammer. Posting meaningless crap about mozilla bugzilla permissions and wine-devel makes you look like a bot. Can we ban this sender? Agreed, FWIW see also: https://mail.python.org/pipermail/python-dev/2013-December/130727.html The motivation seems obvious to me: create archived links to the spam posts, giving them higher page rank. We should find him and kneecap him, or if that's not possible ban him from the list.
Re: proposal to make SIZE_TYPE more flexible
Where is the right place to set the array of this __intN mode is enabled flags? I initially set it in tree.c where __int128 is set up, but that happens *after* c_parse_init() needs the flag to set up the RID_* keywords for them. Alternately, should I be calling targetm.scalar_mode_supported_p() all over the place? We'd need to be careful to not call that too early too...
[Bug c++/59554] Errors with const and volatile in templates.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59554 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andreas Schwab sch...@linux-m68k.org --- Not a bug.
[Bug other/59545] Signed integer overflow issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Perhaps it would be nice to compare on the same codebase what clang and gcc catch (it would have to be --disable-bootstrap build and start with separately built same version of gcc, installed into some temp directory and just use -fsanitize=undefined in stage1 flags (or wrap both compilers)?)
[Bug target/52794] gcc.dg/tree-prof/pr52027.c fails on x86_64/i386-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52794 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- I confirm that this PR is fixed by r206070, see http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg01811.html and http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg01813.html.
[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536
--- Comment #10 from bin.cheng amker.cheng at gmail dot com ---
The offending loop before IVOPT is like:
bb 350:
# var_index_1889 = PHI 1(924), var_index_983(923)
# var_index.250_1269 = PHI 1(924), var_index.250_1959(923)
if (var_index.250_1269 _1237)
goto bb 351;
else
goto bb 885;
bb 351:
loopi_952 = MEM[(const struct vec
*)pretmp_2270].m_vecdata[var_index.250_1269];
_947 = loopi_952-num;
if (_947 == pretmp_2268)
goto bb 352;
else
goto bb 923;
bb 923:
var_index_983 = var_index_1889 + 1;
var_index.250_1959 = (unsigned int) var_index_983;
goto bb 350;
bb 924:
goto bb 350;
The patch can recognize var_index.250_1269 is an iv with {1, 1}_loop, thus
rewriting the loop into:
bb 350:
# var_index_1889 = PHI 1(924), var_index_983(923)
# ivtmp.1067_1968 = PHI ivtmp.1067_696(924), ivtmp.1067_884(923)
var_index.250_1269 = (unsigned int) var_index_1889;
if (var_index_1889 != _958)
goto bb 351;
else
goto bb 885;
bb 351:
_111 = (void *) ivtmp.1067_1968;
loopi_952 = MEM[base: _111, offset: 0B];
ivtmp.1067_884 = ivtmp.1067_1968 + 4;
_947 = loopi_952-num;
if (_947 == pretmp_2268)
goto bb 352;
else
goto bb 923;
bb 923:
var_index_983 = var_index_1889 + 1;
goto bb 350;
bb 924:
_1542 = pretmp_2270 + 12;
ivtmp.1067_696 = (unsigned int) _1542;
_958 = (int) _1237;
goto bb 350;
The transformation looks good and takes advantage of post-increment addressing
mode for memory access MEM[base: _111, offset: 0B].
The loop is expanded into rtl like:
4438: L4438:
1814: NOTE_INSN_BASIC_BLOCK 352
1815: r626:SI=r817:SI
1816: cc0=cmp(r817:SI,r492:SI)
1817: pc={(cc0==0)?L4244:pc}
REG_BR_PROB 900
1818: NOTE_INSN_BASIC_BLOCK 353
1819: r490:SI=[r829:SI]
1820: r829:SI=r829:SI+0x4
1821: cc0=cmp([r490:SI],r864:SI)
1822: pc={(cc0!=0)?L4435:pc}
...
4435: L4435:
4436: NOTE_INSN_BASIC_BLOCK 952
4437: r817:SI=r817:SI+0x1
4439: pc=L4438
4440: barrier
4441: L4441:
4442: NOTE_INSN_BASIC_BLOCK 953
4443: r829:SI=r865:SI+0xc
: r492:SI=r621:SI
44: r817:SI=0x1
4445: pc=L4438
Then instruction 1819/1820 are combined by auto-inc-dec pass into:
1819: r490:SI=[r829:SI++]
REG_INC r829:SI
1821: cc0=cmp([r490:SI],r864:SI)
REG_DEAD r490:SI
1822: pc={(cc0!=0)?L4435:pc}
REG_BR_PROB 9550
Problem comes from reload which puts both r490 and r829 into %a0 (reg 8?) and
generates below code:
1819: %a0:SI=[%a0:SI++]
REG_INC %a0:SI
1821: cc0=cmp([%a0:SI],%d2:SI)
1822: pc={(cc0!=0)?L4435:pc}
REG_BR_PROB 9550
Insn 1819 is now bogus and causes assertion in cselib.
In IRA, there are dumps like:
Popping a1119(r829,l0: a921(r829,l17)) -- assign reg 8
Popping a1122(r,l0: a924(r,l17)) -- assign reg 8
Popping a1120(r494,l0: a922(r494,l17)) -- assign reg 9
Popping a1147(r1054,l0: a1006(r1054,l15)) -- assign reg 8
Popping a1157(r490,l0: a1124(r490,l17: a959(r490,l18))) -- assign reg 2
But in reload, there are dumps:
Reloads for insn # 1819
Reload 0: reload_in (SI) = (post_inc:SI (reg:SI 829 [ ivtmp.1067 ]))
reload_out (SI) = (post_inc:SI (reg:SI 829 [ ivtmp.1067 ]))
ADDR_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1), inc by 4
reload_in_reg: (post_inc:SI (reg:SI 829 [ ivtmp.1067 ]))
reload_reg_rtx: (reg:SI 8 %a0)
Reload 1: reload_out (SI) = (reg/v/f:SI 490 [ loopi ])
GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (reg/v/f:SI 490 [ loopi ])
Reload 2: reload_in (SI) = (mem/f:SI (post_inc:SI (reg:SI 829 [ ivtmp.1067 ]))
[4 MEM[base: _111, offset: 0B]+0 S4 A16])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
reload_in_reg: (mem/f:SI (post_inc:SI (reg:SI 829 [ ivtmp.1067 ])) [4
MEM[base: _111, offset: 0B]+0 S4 A16])
So I am not sure if there are some bugs in reload for m68k, or ivopt is doing
something very trick and wrong?
Thanks,
bin
[Bug fortran/46991] [OOP] polymorphic assumed-size actual arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46991 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-19 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compiling the test in comment 0 with gfortran 4.8.2 or trunk r206033 gives pr46991.f90:16.39: CLASS(REC), INTENT(IN) :: A(*) 1 Error: Assumed size polymorphic objects or components, such as that at (1), have not yet been implemented pr46991.f90:34.43: CLASS(REC), INTENT(IN) :: A(*) 1 Error: Assumed size polymorphic objects or components, such as that at (1), have not yet been implemented pr46991.f90:18.19: CALL SUB2(A, N) 1 Warning: Type mismatch in argument 'a' at (1); passed REAL(4) to TYPE(rec) pr46991.f90:38.9: A = [ (REC2(I, I+1), I = 1, 10) ] 1 Error: Variable must not be polymorphic in intrinsic assignment at (1) - check that there is a matching specific subroutine for '=' operator pr46991.f90:39.19: CALL SUB1(A, 10) 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(rec) to REAL(4)
[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 bin.cheng amker.cheng at gmail dot com changed: What|Removed |Added CC||bernds at codesourcery dot com, ||uweigand at de dot ibm.com --- Comment #11 from bin.cheng amker.cheng at gmail dot com --- Add reload maintainer for some suggestions.
[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 --- Comment #12 from Andreas Schwab sch...@linux-m68k.org --- -fno-auto-inc-dec avoids the crash. Dup of #52306?
[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 --- Comment #13 from bin.cheng amker.cheng at gmail dot com --- (In reply to Andreas Schwab from comment #12) -fno-auto-inc-dec avoids the crash. Dup of #52306? It looks like, AFAICT. Only this time it's blocking bootstrap :(
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #23 from Andreas Schwab sch...@linux-m68k.org --- *** Bug 59536 has been marked as a duplicate of this bug. ***
[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #14 from Andreas Schwab sch...@linux-m68k.org --- As confirmed by comment 9 there. *** This bug has been marked as a duplicate of bug 52306 ***
[Bug target/59203] config/cris/cris.c:2491: possible typo ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59203 --- Comment #2 from David Binderman dcb314 at hotmail dot com --- (In reply to Hans-Peter Nilsson from comment #1) Thanks for catching, yep, s/t1/t2/ there. You are welcome. Not sure why you mean by code rework, looks otherwise clear to me. I am not familiar with the code, so if the code is clear to you, then proceed with s/t1/t2.
[Bug c++/59555] New: bogus error: template with C linkage with preprocessed c++ file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59555 Bug ID: 59555 Summary: bogus error: template with C linkage with preprocessed c++ file Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amker.cheng at gmail dot com Created attachment 31478 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31478action=edit preprocessed c++ file For attached preprocessed file, arm-none-eabi-g++ and m68k-unknown-elf-g++ give below error messages with either -xc++ or -xc++-cpp-output: In file included from /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/stringfwd.h:40:0, from /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:39, from /daten/cross/m68k-linux/m68k-linux/sys-root/usr/include/gmp.h:25, from ../../gcc/gcc/system.h:647, from ../../gcc/gcc/tree-loop-distribution.c:45: /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/memoryfwd.h:63:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/memoryfwd.h:66:3: error: template specialization with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/memoryfwd.h:70:3: error: template with C linkage In file included from /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:39:0, from /daten/cross/m68k-linux/m68k-linux/sys-root/usr/include/gmp.h:25, from ../../gcc/gcc/system.h:647, from ../../gcc/gcc/tree-loop-distribution.c:45: /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/stringfwd.h:52:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/stringfwd.h:55:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/stringfwd.h:59:3: error: template specialization with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/stringfwd.h:65:3: error: template specialization with C linkage In file included from /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:40:0, from /daten/cross/m68k-linux/m68k-linux/sys-root/usr/include/gmp.h:25, from ../../gcc/gcc/system.h:647, from ../../gcc/gcc/tree-loop-distribution.c:45: /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/postypes.h:111:3: error: template with C linkage In file included from /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:40:0, from /daten/cross/m68k-linux/m68k-linux/sys-root/usr/include/gmp.h:25, from ../../gcc/gcc/system.h:647, from ../../gcc/gcc/tree-loop-distribution.c:45: /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/postypes.h:214:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/bits/postypes.h:219:3: error: template with C linkage In file included from /daten/cross/m68k-linux/m68k-linux/sys-root/usr/include/gmp.h:25:0, from ../../gcc/gcc/system.h:647, from ../../gcc/gcc/tree-loop-distribution.c:45: /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:76:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:79:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:82:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:85:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:88:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:91:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:95:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:99:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:103:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:107:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:110:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:113:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:116:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:119:3: error: template with C linkage /daten/cross/m68k-linux/gcc-4.8/m68k-linux/include/c++/4.8.2/iosfwd:122:3: error: template with C linkage In file included from
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-19 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Vladimir Makarov from comment #9) (In reply to Richard Earnshaw from comment #5) I think major problem is in wrong alternative choices as thumb lo/hi reg usage is complicated. That is probably going to be the reason. I take this bug very seriously. If I cannot fix it till end of Jan (sorry, it is a vacation time), probably we should switch to reload pass for thumb. Thanks very much for taking this so seriously. To be honest, I don't know why 12 is not fixed. It results in using 12 by IRA and bigger code when even reload is used. I believe it should fixed too. According to the ABI r12 is a caller saved register. Am I correct in understanding that we are taking out a caller-saved register to allow for lra to be able to choose other low regs and thereby prevent movements to and from r12 ? Taking out r12 will have performance implications, so any change here needs to be benchmarked very carefully on all cores with Thumb1 and Thumb2 to make sure that the impact. Additionally we shouldn't be needing to do this in ARM state, so this patchlet as it stands is not enough. regards Ramana
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #32 from Dominique d'Humieres dominiq at lps dot ens.fr --- Would it be possible to post the fix? TIA. Committed upstream as http://llvm.org/viewvc/llvm-project?rev=196779view=rev Feel free to commit the exact same change to gcc or wait for the next merge (will try this week, but no promises) Thanks for the pointer, it allowed to bootstrap r205803. I understand no promises, but it is broken bootstrap with a known fix. Waiting for more than a week seems excessive!
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #33 from Kostya Serebryany kcc at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #32) Would it be possible to post the fix? TIA. Committed upstream as http://llvm.org/viewvc/llvm-project?rev=196779view=rev Feel free to commit the exact same change to gcc or wait for the next merge (will try this week, but no promises) Thanks for the pointer, it allowed to bootstrap r205803. I understand no promises, but it is broken bootstrap with a known fix. Waiting for more than a week seems excessive! Sorry. Feel free to commit the exact fix as in http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_platform_limits_posix.cc?r1=196779r2=196778pathrev=196779 directly to GCC.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #34 from Dominique d'Humieres dominiq at lps dot ens.fr --- Feel free to commit the exact fix as in ... Sorry, no write access.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #35 from Kostya Serebryany kcc at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #34) Feel free to commit the exact fix as in ... Sorry, no write access. Give me 1-2 hours. Just in case, please verify that the patch still works on Mac 10.6 (I don't have access to 10.6)
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Ramana Radhakrishnan from comment #11) (In reply to Vladimir Makarov from comment #9) (In reply to Richard Earnshaw from comment #5) I think major problem is in wrong alternative choices as thumb lo/hi reg usage is complicated. That is probably going to be the reason. I take this bug very seriously. If I cannot fix it till end of Jan (sorry, it is a vacation time), probably we should switch to reload pass for thumb. Thanks very much for taking this so seriously. To be honest, I don't know why 12 is not fixed. It results in using 12 by IRA and bigger code when even reload is used. I believe it should fixed too. According to the ABI r12 is a caller saved register. Am I correct in understanding that we are taking out a caller-saved register to allow for lra to be able to choose other low regs and thereby prevent movements to and from r12 ? Scratch that : it's already for t16 and Os. Changing LAST_HI_REGNUM to 14 in arm.h should be enough. regards Ramana
[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
--- Comment #20 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to bin.cheng from comment #19)
not about an iv use appearing in memory reference while not marked as
address_p, and can be fixed by revise the existing check condition, is
it true?
No, even expressing an address this way is broken as for example dependence
analysis via scev can get confused about the actual base object.
Agree, only I think it's not scev's responsibility since scev only cares
base value initialized for the analyzing loop, rather than the BASE object.
IIRC previously we already avoided the mem-use case and I had to generalize
it
to also avoid addresses.
Not all.
For the reported case, use and cand like:
use 3
generic
in statement vect_p.70_247 = PHI vect_p.70_248(17), vect_p.73_246(6)
at position
type vector(8) unsigned char *
base batmp.71_245 + 1
step 8
base object (void *) batmp.71_245
is a biv
related candidates
candidate 15
depends on 3
var_before ivtmp.154
var_after ivtmp.154
incremented before exit test
type unsigned int
base (unsigned int) pDst_39(D) - (unsigned int) p1
step (unsigned int) (pretmp.21_118 + 1)
The check:
if (address_p
|| (use-iv-base_object
cand-iv-base_object
POINTER_TYPE_P (TREE_TYPE (use-iv-base_object))
POINTER_TYPE_P (TREE_TYPE (cand-iv-base_object
{
/* Do not try to express address of an object with computation based
on address of a different object. This may cause problems in rtl
level alias analysis (that does not expect this to be happening,
as this is illegal in C), and would be unlikely to be useful
anyway. */
if (use-iv-base_object
cand-iv-base_object
!operand_equal_p (use-iv-base_object, cand-iv-base_object, 0))
return infinite_cost;
}
still evaluates to false because:
use-iv-base_object != NULLcand-iv-base_object == NULL
As I said in the PR that was last fixed with change of this code it is a
quick dirty fix (because we were in stage3 again).
A better fix would be to detect reliably whether we are expressing an IV
with base A using an IV with base B != A (reliably == conservatively
correct) and then use whatever means (read: eventually to be invented)
to avoid the alias code from deriving bogus assumptions. One mean is
to use a non-pointer IV, but that only works for non-mem uses (a TMR
with a NULL TMR_BASE is not valid).
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 philipp at marek dot priv.at changed: What|Removed |Added CC||philipp at marek dot priv.at --- Comment #4 from philipp at marek dot priv.at --- I have this or a very similar problem with debian amd64 4:4.8.2-1: main.c: In function ‘main’: main.c:1231:23: error: ‘rv’ may be used uninitialized in this function [-Werror=maybe-uninitialized] return (rv_main = 0 rv_main 0x70) ? rv_main : 1;
[Bug other/59545] Signed integer overflow issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- FWIW here's the list issues clang catches on r206105: gcc/combine.c:11867:14: runtime error: left shift of negative value -4096 gcc/config/i386/i386.c:21805:37: runtime error: left shift of negative value -1073807360 gcc/config/i386/i386.c:21805:37: runtime error: left shift of negative value -65537 gcc/config/i386/i386.c:21805:44: runtime error: left shift of negative value -140739635838976 gcc/config/i386/i386.c:21805:44: runtime error: left shift of negative value -2305983746702049280 gcc/cp/error.c:448:7: runtime error: call to function pp_cxx_type_specifier_seq(cxx_pretty_printer*, tree_node*) through pointer to incorrect function type 'void (*)(c_pretty _printer *, tree_node *)' gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 + 9223372036854775807 cannot be represented in type 'long' gcc/dce.c:278:16: runtime error: left shift of negative value -1 gcc/double-int.c:141:13: runtime error: negation of -9223372036854775808 cannot be represented in type 'long'; cast to an unsigned type to negate this value to itself gcc/dwarf2out.c:11516:61: runtime error: left shift of negative value -1 gcc/dwarf2out.c:11531:54: runtime error: left shift of negative value -1 gcc/expmed.c:2986:15: runtime error: left shift of negative value -1 gcc/expr.c:3986:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long' gcc/genattrtab.c:622:27: runtime error: signed integer overflow: 4568797 * 613 cannot be represented in type 'int' gcc/genautomata.c:3497:23: runtime error: shift exponent 64 is too large for 64-bit type 'set_el_t' (aka 'unsigned long') gcc/ggc-common.c:133:7: runtime error: call to function gt_ggc_m_S(void const*) through pointer to incorrect function type 'void (*)(void *)' gcc/ggc-common.c:501:2: runtime error: call to function gt_pch_n_S(void const*) through pointer to incorrect function type 'void (*)(void *)' gcc/haifa-sched.c:1160:24: runtime error: left shift of negative value -1 gcc/haifa-sched.c:1423:26: runtime error: left shift of negative value -1 gcc/ipa-split.c:1051:20: runtime error: load of value 100, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 108, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 116, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 124, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 12, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 132, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 140, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 156, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 164, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 172, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 188, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 196, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 204, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 20, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 212, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 220, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 224, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 228, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 236, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 244, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 252, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 28, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 36, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 44, which is not a valid value for type 'bool' gcc/ipa-split.c:1051:20: runtime error: load of value 4, which is not a valid value for type 'bool'
[Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org ---
I've looked at dozens of the failures, except for one they were all about an
expected TREE_VEC being written as 0s (i.e. ERROR_MARK) in the PCH file, the
one exception was TREE_LIST instead of TREE_VEC. But it isn't always the same
place that refers to the previously TREE_VEC, sometimes it is
t-type_with_lang_specific-lang_specific-u.c.template_info-typed.type-decl_non_common-arguments
which points to ERROR_MARK code instead of TREE_VEC, sometimes it is
static tree
get_template_argument_pack_elems_folded (const_tree t)
{
return fold_cplus_constants (get_template_argument_pack_elems (t));
}
where get_template_argument_pack_elems returns TREE_TYPE of something and the
TREE_TYPE is a TREE_VEC with 0s in the PCH file, etc.
I've tried to disable ggc_free altogether (return early in the function), but
that didn't fix this up. Using setarch x86_64 -R seems to reliably make the
problem away, so whether we hit this or not depends on address space
randomization of the process that saves the PCH file.
So no idea how to debug this actually, perhaps only through instrumenting the
kernel somehow (systemtap, something else)? I'd imagine if we recorded all the
random values used during address space randomization of selected processes
(cc1plus would be interesting for us), then run in a loop the PCH saving + PCH
reading commands mentioned above until it fails and when it fails, looked into
logs (systemtap, something else) what exact values the PCH saving cc1plus
process used and then somehow arranged to replay those values reliably for all
cc1plus invocations under some session, then supposedly it could be reliably
reproduced.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #36 from Dominique d'Humieres dominiq at lps dot ens.fr --- Give me 1-2 hours. Just in case, please verify that the patch still works on Mac 10.6 (I don't have access to 10.6) Already done: see comment 27. Anyway, I guarantee a quick feedback!-)
[Bug testsuite/59556] New: Floating-point __sec_reduce_add tests not robust in face of contraction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59556
Bug ID: 59556
Summary: Floating-point __sec_reduce_add tests not robust in
face of contraction
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: bhaveet.shah at arm dot com
If fused-mac is available on the target, the following
__sec_reduce_add (taken from
gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_func_double.c) on a
floating-point type could be implemented using a fused-mac:
x = __sec_reduce_add (array3[:] * array4[:]);
The test cases also contain the following loop:
add_value = 0.;
mul_value = 1.;
for (ii = 0; ii 10; ii++)
{
add_value += (array3[ii] * array4[ii]);
mul_value *= (array3[ii] * array4[ii]);
}
In this case, a compiler could reasonably do the multiply and addition
separately so that the multiply result could be used for both
add_value and mul_value. If the semantics of the fused-mac
and the separate instructions are not equivalent, the result from this
loop could be different compared to the __sec_reduce_add case.
The test compares the results of these two using a bitwise comparison,
hence this test will fail. This test case should be made more robust to
handle this case.
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to philipp from comment #4) I have this or a very similar problem with debian amd64 4:4.8.2-1: main.c: In function ‘main’: main.c:1231:23: error: ‘rv’ may be used uninitialized in this function [-Werror=maybe-uninitialized] return (rv_main = 0 rv_main 0x70) ? rv_main : 1; Can you attach a small, preprocessed testcase? See http://gcc.gnu.org/bugs/minimize.html
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #24 from Mikael Pettersson mikpelinux at gmail dot com --- So where does that leave us? Disable -fauto-inc-dec by default, or try to make m68k work with LRA (which hopefully should avoid this reload bug)?
[Bug libstdc++/59557] [4.8/4.9 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Known to work||4.8.1 Target Milestone|--- |4.8.3 Known to fail||4.8.2
[Bug libstdc++/59557] New: [4.8/4.9 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 Bug ID: 59557 Summary: [4.8/4.9 Regression] Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Created attachment 31479 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31479action=edit testcase A libstdc++ change between r202388 and the 4.8.2 release broke Eigen. Preprocessing the attached testcase with 4.8.2 and then compiling with -O0 gives ./a.out Brute force distance = 0.00428018, calls = 1 Segmentation fault while preprocessing with 4.8.1 gets the correct ./a.out Brute force distance = 0.00428018, calls = 1 BVH distance = 0.00428018, calls = 756
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 --- Comment #6 from philipp at marek dot priv.at --- I'm trying to get a minimized file via creduce. In case you have an experienced guess please look at src/main.c from github.com:ClusterLabs/booth.git 44b06e6d3c9c81d287020fe017a05f1386ae5e6e Thanks.
[Bug libstdc++/59557] [4.8/4.9 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||chris at bubblescope dot net, ||kariya_mitsuru at hotmail dot com --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The diff of the preprocessed sources points at +2013-09-30 Chris Jefferson ch...@bubblescope.net + + PR libstdc++/58437 + * include/bits/stl_algo.h (__move_median_first): Rename to + __move_median_to_first, change to take an addition argument. + (__unguarded_partition_pivot): Adjust. + * testsuite/performance/25_algorithms/sort.cc: New. + * testsuite/performance/25_algorithms/sort_heap.cc: Likewise. + * testsuite/performance/25_algorithms/stable_sort.cc: Likewise. + +2013-09-19 Mitsuru Kariya kariya_mits...@hotmail.com + Chris Jefferson ch...@bubblescope.net + + PR libstdc++/58358 + * include/bits/stl_algo.h (search_n): Fix to guarantee a number + of comparisons = number of elements in the range. + * testsuite/25_algorithms/search_n/58358.cc: New. + * testsuite/25_algorithms/search_n/iterator.cc: Extend.
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to philipp from comment #6) I'm trying to get a minimized file via creduce. In case you have an experienced guess please look at src/main.c from github.com:ClusterLabs/booth.git 44b06e6d3c9c81d287020fe017a05f1386ae5e6e Thanks. My guess is that it is exactly the same issue: inlining + variable coalescing. The inlining part could be improved, but variable coalescing seems a harder problem as long as we warn after coalescing (a unique name has to be chosen). See comment #2.
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 --- Comment #9 from philipp at marek dot priv.at --- Created attachment 31480 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31480action=edit main.c not much use because of includes.
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 --- Comment #8 from philipp at marek dot priv.at --- I forgot to say that the uninitialized rv is in query_get_string_answer(). I've got a reduced main.c - but sadly there are still includes to other files, so it won't help that much. I'll attach it here anyway.
[Bug c++/59558] New: [MSP430-gcc] CPU setup, pre start program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59558 Bug ID: 59558 Summary: [MSP430-gcc] CPU setup, pre start program Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jkroby at p3r dot info Gcc: msp430-gcc (GNU GCC patched mspgcc-20110716) 4.5.3 Run on msp430G2553 Library used: Energia 0101E0009 compiled on host: Linux version 3.2.0-56-generic (buildd@roseapple) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #86-Ubuntu SMP Wed Oct 23 09:20:45 UTC 2013 I have wrote a big program with many library and i test it from some month, all OK but, when i add new code i found a strange think, the CPU do nothink so i use debugger and i find the problem: using msp430g2553 with 510 bytes of ram memory used (512 max), (calculation way: i enlarge the variable and i use the linker error to calculate the size, i reduce the size for stay in the limit) With debugger i discover: the first instruction CPU load from 0x0120 WDTCTL in 0x03fc address ram and make an or so the location becam 0x5408, it use this value for reset wdt, i think before energia initialize it, SP is initialized to 0x0400 when the code use CALL and RET (for init) overwrite that value at 0x03fc so when it use the value for clear Watchdog happen a PUC because the write pin(password) is not correct (WDTPW that has to be 5A high byte is 0xda, call return address of the stack). i reduce the code of 4 bytes for be sure and it works. All is ok only the space conflict with stack and temporary variable is a problem. I hope to be clear, i'm ready to give more detail. I think is a problem of the library for initialization but i don't know which component is. Roberto Pomo jkr...@p3r.info
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 --- Comment #10 from philipp at marek dot priv.at --- Well, I've found the culprit, so it's not that important to me anymore. Getting a completely wrong code location is the problem - you don't know what to fix, and have to do some kind of search.
[Bug tree-optimization/59387] [4.9 Regression] wrong code (hangs) at -Os on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59387 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|wrong code (hangs) at -Os |[4.9 Regression] wrong code |on x86_64-linux-gnu |(hangs) at -Os on ||x86_64-linux-gnu --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r196792. Looking at it.
[Bug middle-end/52306] [4.8/4.9 regression] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Summary|ICE in cselib_record_set, |[4.8/4.9 regression] ICE in |at cselib.c:2158|cselib_record_set, at ||cselib.c:2158 Severity|normal |major --- Comment #25 from Eric Botcazou ebotcazou at gcc dot gnu.org --- We should fix reload, it's too late for LRA.
[Bug middle-end/52306] [4.8/4.9 regression] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #26 from Andreas Schwab sch...@linux-m68k.org --- What does that mean, it's too late?
[Bug tree-optimization/59387] [4.9 Regression] wrong code (hangs) at -Os on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59387 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Seems it is SCCP that breaks this. We have a loop like: bb 4: c.2_10 = (unsigned char) c_lsm.11_20; _11 = c.2_10 + 255; c.3_12 = (char) _11; _14 = b_f1_lsm.12_7 + 1; bb 5: # c_lsm.11_20 = PHI c_lsm.11_15(3), c.3_12(4) # b_f1_lsm.12_7 = PHI 0(3), _14(4) if (b_f1_lsm.12_7 = 23) goto bb 4; else goto bb 6; bb 6: # b_f1_lsm.12_36 = PHI b_f1_lsm.12_7(5) # c_lsm.11_40 = PHI c_lsm.11_20(5) where c.2/c.3/c_lsm.11 is signed char. Note the c decrement done carefully in unsigned char type. But then comes sccp and does: final value replacement: c_lsm.11_40 = PHI c_lsm.11_20(5) with c_lsm.11_40 = c_lsm.11_15 + -24; which is invalid, because it is subtracted in signed type instead of the unsigned type originally. Dunno if scev remembers somewhere what type the arithmetics has been actually performed in. Richard, can you please have a look?
[Bug middle-end/52306] [4.8/4.9 regression] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 bin.cheng amker.cheng at gmail dot com changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #27 from bin.cheng amker.cheng at gmail dot com --- (In reply to Andreas Schwab from comment #26) What does that mean, it's too late? We are in stage 3 now, enabling LRA needs non-trivial work, so it's very likely we can't make it work in time.
[Bug tree-optimization/59387] [4.9 Regression] wrong code (hangs) at -Os on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59387
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Note already the chrec is {c_lsm.11_15, +, -1}_2 with char type everywhere (but
the 2 which is int, but that is irrelevant), so the information that the
decrement was performed carefully in non-wrapping type is lost at that point.
Dunno if we want and whether it would be possible to generate a chrec with
unsigned char type in that case instead
(i.e. (char) {(unsigned char)c_lsm.11_15, +, 255}_2 instead), or some special
bit on the chrec to tell us that it is wrapping.
[Bug fortran/59104] Wrong result with SIZE specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-19 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed at r206105. Using result(res) as in module m1 implicit none integer, parameter :: dp = kind([double precision::]) contains recursive function f(x) result(res) integer, intent(in) :: x real(dp) res(x/2) integer y(size(res)+1) if (x==1) return write(*,*) 'size(f) = ',size(res) write(*,*) 'size(y) = ',size(y) res = f(x/2) end function f end module m1 program bug3 use m1 implicit none real y y = sum(f(8)) print *, y end program bug3 make the code working: size(f) =4 size(y) =5 size(f) =2 size(y) =3 size(f) =1 size(y) =2 0.
[Bug target/38183] Useless move to memory when passing small structs to functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38183 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-19 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- It works on the trunk for x86_64 darwin. Confirmed for trunk r206002 _f: LFB0: addsd%xmm1, %xmm0 ret What is the status of this five years old PR on x86_64-linux-gnu?
[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r205959.
[Bug bootstrap/47016] bootstrap on darwin needs much more disk space than expected to complete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47016 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any reason to keep this PR open?
[Bug boehm-gc/18135] gctest (boehm-gc) uses the installed libgcc_s on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18135 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Posted more than three years ago: Andrew, Do you still see this issue with current gcc trunk since... Any reason to keep this PR open?
[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 bin.cheng amker.cheng at gmail dot com changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #3 from bin.cheng amker.cheng at gmail dot com --- I will look into it.
[Bug tree-optimization/59413] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- I couldn't reproduce this either, neither -m32/-m64 helps, tried also r205733 and various other snapshots, everything prints 7.
[Bug libstdc++/59557] [4.8/4.9 Regression] Miscompilation after libstdc++ change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug target/38183] Useless move to memory when passing small structs to functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38183 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- Works on Linux/x86-64 with GCC 4.8.
[Bug gcov-profile/59542] [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59542 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #37 from Kostya Serebryany kcc at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #36) Give me 1-2 hours. Just in case, please verify that the patch still works on Mac 10.6 (I don't have access to 10.6) Already done: see comment 27. Anyway, I guarantee a quick feedback!-) Done, r206113. Is there anything else left in this bug?
[Bug bootstrap/59541] [4.9 Regression] Revision 206070 breaks bootstrap on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug middle-end/59559] New: ICE: invalid RTX sharing in expmed.c:expand_divmod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59559
Bug ID: 59559
Summary: ICE: invalid RTX sharing in expmed.c:expand_divmod
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
In expmed.c:expand_divmod() we have the following code:
t1 = expmed_mult_highpart
(compute_mode, op0,
gen_int_mode (ml, compute_mode),
NULL_RTX, 1, max_cost - extra_cost);
if (t1 == 0)
goto fail1;
t2 = force_operand (gen_rtx_MINUS (compute_mode,
op0, t1),
NULL_RTX);
t3 = expand_shift (RSHIFT_EXPR, compute_mode,
t2, 1, NULL_RTX, 1);
t4 = force_operand (gen_rtx_PLUS (compute_mode,
t1, t3),
NULL_RTX);
This code produces invalid RTX sharing for t1 if some conditions are met:
- The code is used after tree-RTL lowering which can happen in
some loop optimizations. A possible call chain is from
loop_doloop.c:doloop_modify() and if the force_operand there
operates on a UDIV or DIV expression and finally ends up with the
expmed.c code from above.
- The value for t1 is a SUBREG like (subreg:SI (reg:DI xxx) 4)
This depends on the backend and if and how it implements
(widening) multiplication and mul_highpart insns.
- The ICE will depend on the cost model of the target.
- The ICE will only pop up if RTL checking is enabled.
I could not reproduce this ICE with a standard GCC target, I just see it for a
private port. However, this might also be a latent problem for official GCC
targets. The problem is that the loop optimization above runs after RTL
unsharing so that the sharing of the SUBREG is not resolved.
A possible fix is obviously to t1 = copy_rtx (t1) after the first use of t1 and
befor its second use.
FYI, the code for which I see the ICE is gcc.c-torture/execute/loop-3b.c from
GCC's test suite -- but as already said I found no official target that breaks
there.
There is also a simpler example like the code below, but fpr x86 and rs6000 it
works fine :-(
int n;
void f (int val)
{
while (n 0)
{
val++;
n -=45;
}
}
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, ra Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug bootstrap/59528] Profiledbootstrap should use stage1 compiler during stagefeedback
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59528 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Can you point to a version where we did that?
[Bug middle-end/59471] [4.9 Regression] ICE using vector extensions (non-top-level BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- The reason I added this verification is that code does not expect those to appear at non-outermost handled-component. a V_C_E around a vector type B_F_R should have been split into two different stmts with a temporary. Eventually gimplification doesn't ensure this (and thus force_gimple_operand and friends may generate invalid gimple). So the fix probably has a piece in gimplify.c at least - make sure is_gimple_reg_type () B_F_R, RP_E, IP_E get a temporary. RP_E and IP_E are probably safe as complex types are quite constrained.
[Bug middle-end/59471] [4.9 Regression] ICE using vector extensions (non-top-level BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/59471] [4.9 Regression] ICE using vector extensions (non-top-level BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- If nobody beats me to it I'll take care of the gimplify.c piece after holidays.
[Bug gcov-profile/59527] [4.9 Regression] ICE: in fixup_reorder_chain, at cfgrtl.c:3739 during PGO Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/59521] __builtin_expect not effective in switch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug target/59516] [4.9 Regression] Multiple definition of `X' / of `non-virtual thunk to X' errors with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59516 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59493 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from janus at gcc dot gnu.org --- After it has been fixed on 4.8 and trunk (with some additional cleanup on trunk), I think this PR can be closed. Thanks for reporting!
[Bug debug/59515] -Og doesn't generate out-of-line copies of inline functions like -O0 does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59515
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-12-19
CC||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Thanks for the report - I agree that -Og should preserve an OOL copy of inlined
functions. I'll see what I can do here (with C++ and a lot of abstraction
penalty the code size impact of that could be quite big though, and via that
also the compile-time increase). We definitely need to avoid inlining into the
unused offline copy - but usually that's too late because we inline from the
leafs - if we don't the code-size impact is exponential ... :/
Honza, is there a way to do this in a clean way? That is, create a clone
of all initially reachable functions that we don't inline into, but remove
the clone if the original function prevails? That is, for
inline int bar () { return 42; }
inline int foo () { return bar() + bar(); }
int main()
{
return foo ();
}
have main return 84 but offline copies of bar and foo while foo should still
call bar twice?
Not sure if the exponential size consideration matters for -Og which
inlines for size improvements only.
[Bug middle-end/58344] [4.9 Regression] ICE with segfault at -O1 and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58344 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|ICE with segfault at -O1|[4.9 Regression] ICE with |and above on|segfault at -O1 and above |x86_64-linux-gnu|on x86_64-linux-gnu --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r200211.
[Bug driver/59512] Incomplete output files when compiler is killed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59512 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-19 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. GCC cleans up after receiving interceptible signals already, so this issue is minor and likely affects almost every software around in the world. That said, working patches welcome.
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #23 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #15)
We should analyze why we end up with missing symbol. __attribute__ ((used))
will prevent privatization of the symbol. Rather than that it would be
better to figure out what object file of the library actually need it and
look at the preprocessed source code if the inline version is there.
I just rebuilt without testing and indeed it seems that cprop and df seems
to degenerate here quite noticeably.
It is lookupIntrinsicID that consume a lot of time and its CFG is not small:
$4 = {x_entry_block_ptr = 0x765b22d8, x_exit_block_ptr = 0x765b2340,
x_basic_block_info = 0x748df000, x_n_basic_blocks = 13898, x_n_edges =
22158,
x_last_basic_block = 13898, last_label_uid = 8660, x_label_to_block_map =
0x0, x_profile_status = PROFILE_GUESSED, x_dom_computed = {DOM_NONE,
DOM_NONE}, x_n_bbs_in_dom_tree = {0, 0},
max_jumptable_ents = 34}
But it does not really explain why cprop should that that much of time.
It seems that the function is huge sequence of ifs compiling into:
L3807:
_3982 = MEM[(void *)_5 + 31B];
_3983 = memcmp (_3982, tore, 4);
if (_3983 != 0)
goto bb 4208;
else
goto bb 5260;
plus a lot of PHIs that probably makes cprop to work hard...
I wonder if we can't inline those stupid memcmps somehow.
Marking as NEW at least for the performance problem. Still unsure if the
original problem is source bug or GCC bug.
See PR52171.
[Bug rtl-optimization/59511] [4.9 Regression] FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa with -mtune=corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59511 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug debug/59510] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212 with -O2 -g --param=large-stack-frame-growth=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59510 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug fortran/59560] New: Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 Bug ID: 59560 Summary: Resolution generic procedure of derived types fail Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: klaas_giesbertz at hotmail dot com I want to achieve some more complicated structure in fortran2008 and I am not sure how to do it according to the standard. So I am even not sure if it is a bug, or simply not possible with fortran2008. I want to make a base class, preferably an abstract one, which promises a subroutine which operates on TWO arguments of this base class. The derived class should implement this and there is some other class using this procedure which only knows about the base class. This was actually possible with gcc 4.7 by declaring both arguments of the subroutine as class. As an example, consider the following program (sorry, quite lengthy due to the several classes): module BaseModule implicit none private type, public, abstract :: BaseClass contains procedure(FuncAbstr), deferred :: Func end type abstract interface subroutine FuncAbstr(self, other) import class(BaseClass), intent(inout) :: self class(BaseClass), intent(in):: other end subroutine end interface end module module UseBaseModule use BaseModule implicit none private type, public :: UseBaseClass class(BaseClass), pointer :: base = null() contains procedure :: Init procedure :: CallFunc end type contains subroutine Init(self, base) class(UseBaseClass), intent(inout) :: self class(BaseClass), pointer, intent(in):: base self%base = base end subroutine subroutine CallFunc(self) class(UseBaseClass), intent(inout) :: self class(BaseClass), allocatable :: newBase allocate(newBase, mold=self%base) call newBase%Func(self%base) end subroutine end module module DerivedModule use BaseModule implicit none private type, public, extends(BaseClass) :: DerivedClass real :: x contains procedure :: Func end type contains subroutine Func(self, other) class(DerivedClass), intent(inout) :: self class(DerivedClass), intent(in):: other self%x = other%x write(*,*) 'Derived Func called' end subroutine end module program Test use BaseModule use UseBaseModule use DerivedModule implicit none class(BaseClass), allocatable :: derived type(UseBaseClass) :: useBase allocate(DerivedClass :: derived) call useBase%Init(derived) call useBase%CallFunc() end program This code compiles and runs correctly with gcc4.7.3, but gcc4.8.2 gives the following compile error: Test1.f08:58.13: procedure :: Func 1 Error: Argument mismatch for the overriding procedure 'func' at (1): Type/rank mismatch in argument 'other' and some more which are not relevant. I actually do not even know if this code is supposed to compile, since it is not clear to me if such kind of overloading is allowed by the fortran standard. One way around this problem might be to give up the possibility to use an abstract type and to use a generic interface with an explicit type for the 2nd argument of the subroutine. The type is now required to facilite the resolution of the generic subroutine. However, this generic subroutine is not correctly resolved. As an example consider the following code (again quite lengthy, sorry): module BaseModule implicit none private type, public :: BaseClass contains procedure :: BaseFunc generic :: Func = BaseFunc end type contains subroutine BaseFunc(self, other) class(BaseClass), intent(inout) :: self type(BaseClass), intent(in):: other write(*,*) 'Base Func called' end subroutine end module module DerivedModule use BaseModule implicit none private type, public, extends(BaseClass) :: DerivedClass real :: x contains procedure :: DerivedFunc generic :: Func = DerivedFunc !Extend generic Func end type contains subroutine DerivedFunc(self, other) class(DerivedClass), intent(inout) :: self type(DerivedClass), intent(in):: other self%x = other%x write(*,*) 'Derived Func called' end subroutine end module module UseBaseModule use BaseModule implicit none private type, public :: UseBaseClass class(BaseClass), pointer :: base = null() contains procedure :: Init procedure :: CallFunc end type contains subroutine Init(self, base) class(UseBaseClass), intent(inout) :: self class(BaseClass), target, intent(in):: base self%base = base end subroutine subroutine CallFunc(self) class(UseBaseClass), intent(in) :: self class(BaseClass), allocatable :: newBase allocate(newBase, mold=self%base) call newBase%Func(self%base)
[Bug tree-optimization/59501] [4.9 Regression] Vector Gather with GCC 4.9 2013-12-08 Snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59501 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Known to work||4.8.2 Target Milestone|--- |4.9.0 Summary|Vector Gather with GCC 4.9 |[4.9 Regression] Vector |2013-12-08 Snapshot |Gather with GCC 4.9 ||2013-12-08 Snapshot
[Bug bootstrap/59496] [4.9 Regression] Bootstrap fails on powerpc-apple-darwin9 after r205685
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59496 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized vect_[^\\n]*\\+ 13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Well, I don't think configuring with arbitrary --with-cpu/tune is a supported configuration for zero testsuite FAILs ...?
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #1 from klaas_giesbertz at hotmail dot com --- Sorry, the 2nd argument of Init of UseBase in the 1st test should have been target instead of pointer. In that case 'program Test' becomes the same as in the 2nd test.
[Bug fortran/59561] New: [4.9 Regression] warning: iteration 4 invokes undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561
Bug ID: 59561
Summary: [4.9 Regression] warning: iteration 4 invokes
undefined behavior
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: janus at gcc dot gnu.org
Found when working on PR 55207 ...
With the following modification:
Index: gcc/testsuite/gfortran.dg/inline_sum_bounds_check_1.f90
===
--- gcc/testsuite/gfortran.dg/inline_sum_bounds_check_1.f90(revision
206100)
+++ gcc/testsuite/gfortran.dg/inline_sum_bounds_check_1.f90(working copy)
@@ -3,7 +3,8 @@
integer, parameter :: nx = 3, ny = 4
- integer :: i, j, too_big
+ integer :: i, j
+ integer, save :: too_big
integer, parameter, dimension(nx,ny) :: p =
reshape((/ (i*i, i=1,size(p)) /), shape(p))
so that this test case becomes:
! { dg-do run }
! { dg-options -fbounds-check }
integer, parameter :: nx = 3, ny = 4
integer :: i, j
integer, save :: too_big
integer, parameter, dimension(nx,ny) :: p =
reshape((/ (i*i, i=1,size(p)) /), shape(p))
integer, dimension(nx,ny) :: a
integer, dimension(:), allocatable :: b
allocate(b(nx))
a = p
too_big = ny + 1
b = sum(a(:,1:too_big),2)
end
! { dg-shouldfail outside of expected range }
trunk gives:
$ gfortran-4.9 inline_sum_bounds_check_1.f90 -O2
inline_sum_bounds_check_1.f90: In function ‘MAIN__’:
inline_sum_bounds_check_1.f90:21:0: warning: iteration 4 invokes undefined
behavior [-Waggressive-loop-optimizations]
b = sum(a(:,1:too_big),2)
^
inline_sum_bounds_check_1.f90:21:0: note: containing loop
inline_sum_bounds_check_1.f90: In function ‘main’:
inline_sum_bounds_check_1.f90:21:0: warning: iteration 4 invokes undefined
behavior [-Waggressive-loop-optimizations]
b = sum(a(:,1:too_big),2)
^
inline_sum_bounds_check_1.f90:21:0: note: containing loop
with -O2 and -O3, while 4.8 did not do that. Probably the warning is ok, since
the test case is supposed to trigger a runtime error (Index '5' of dimension 2
of array 'a' outside of expected range (4:1)).
However, I see three possible problems:
1) The question is why it only happens with SAVE.
2) I don't understand why the warning has 'iteration 4'. Shouldn't iteration 5
be the problem?
3) The warning appears twice.
[Bug fortran/59561] [4.9 Regression] warning: iteration 4 invokes undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Isn't that effectively a duplicate of the P1 regression PR57904?
[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 Yufeng Zhang yufeng at gcc dot gnu.org changed: What|Removed |Added CC||yufeng at gcc dot gnu.org --- Comment #7 from Yufeng Zhang yufeng at gcc dot gnu.org --- What is the current status?
[Bug libstdc++/59557] [4.8/4.9 Regression] Miscompilation after libstdc++ change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 --- Comment #2 from Chris Jefferson chris at bubblescope dot net --- Investigating
[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #4 from bin.cheng amker.cheng at gmail dot com ---
First clue.
b_lsm.11_13 is recognized as chrec {1, +, 1}_2 with the patch, thus the loop
can be vectorized now.
bb 5:
bb 6:
# b.4_30 = PHI b.4_12(5), 1(12)
# prephitmp_28 = PHI c.1_9(5), c.1_21(12)
# b_lsm.11_13 = PHI b.4_12(5), 1(12)
# ivtmp_46 = PHI ivtmp_45(5), 13(12)
c.1_9 = prephitmp_28 | 1;
b.4_12 = b.4_30 + 1;
ivtmp_45 = ivtmp_46 - 1;
if (ivtmp_45 != 0)
goto bb 5;
else
goto bb 7;
Problem arises in calling stack like:
vect_do_peeling_for_loop_bound
slpeel_tree_peel_loop_to_edge
slpeel_update_phi_nodes_for_guard1
for phi node : # b_lsm.11_13 = PHI b.4_12(5), 1(12)
It looks like loop peeling has difficulty in coping with peeled phi node.
[Bug libstdc++/59557] [4.8/4.9 Regression] Miscompilation after libstdc++ change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 --- Comment #3 from Chris Jefferson chris at bubblescope dot net --- Can I just confirm I am testing this code correctly? caj@caj-laptop ~/Downloads g++ BVH_Example.cpp -O0 caj@caj-laptop ~/Downloads ./a.out Brute force distance = 0.00428018, calls = 1 BVH distance = 0.00428018, calls = 756 caj@caj-laptop ~/Downloads g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.2 (Debian 4.8.2-10)
[Bug c/59562] New: __builtin_assume_aligned loses constness when used as initializer element
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59562 Bug ID: 59562 Summary: __builtin_assume_aligned loses constness when used as initializer element Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: stoeps at gmail dot com __builtin_assume_aligned appears to change the semantics of a constant expression, but only in C. The following snippet compiles in C++, but fails in C: -- input $ cat c.c #define INT_PTR ((int*)0) #define INT_PTR_BAA ((int*)__builtin_assume_aligned(0, 4)) int * i = INT_PTR; int * i_baa = INT_PTR_BAA; -- compiled as C $ gcc -c c.c c.c:5:1: error: initializer element is not constant $ -- compiled as C++ $ gcc -x c++ -c c.c $ I know about the different things that are considered constant between C++ and C, but wouldn't expect a GCC builtin to be among them. Am I wrong? Reproduced with various GCC versions/targets: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) $ gcc -v Using built-in specs. COLLECT_GCC=c:\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T Thread model: win32 gcc version 4.8.1 (GCC) $ m68k-elf-gcc -v Using built-in specs. COLLECT_GCC=C:\MinGW\msys\1.0\local\gnu-m68k\bin\m68k-elf-gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/msys/1.0/local/gnu-m68k/bin/../libexec/gcc/m68k-elf/4.8.2/lto-wrapper.exe Target: m68k-elf Configured with: ../gcc-4.8.2/configure --build=i686-pc-linux-gnu --host=i686-w64-mingw32 --target=m68k-elf --prefix=/usr/local/gnu-m68k --enable-interwork --enable-languages=c,c++ --with-newlib --disable-shared --disable-libssp --disable-nls --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --with-debug-prefix-map=/home/tom/m68k-build=/MinGW/msys/1.0/local/gnu-m68k/src Thread model: single gcc version 4.8.2 (GCC) Thanks, Tom
[Bug libstdc++/59557] [4.8/4.9 Regression] Miscompilation after libstdc++ change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Chris Jefferson from comment #3) Can I just confirm I am testing this code correctly? caj@caj-laptop ~/Downloads g++ BVH_Example.cpp -O0 caj@caj-laptop ~/Downloads ./a.out Brute force distance = 0.00428018, calls = 1 BVH distance = 0.00428018, calls = 756 caj@caj-laptop ~/Downloads g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.2 (Debian 4.8.2-10) Looks like so. Werid, I definitely can reproduce with FSF 4.8.2 and SUSE 4.8.2 on x86_64. Are the libstdc++ includes those from 4.8.2-10, too?
[Bug middle-end/52306] [4.8/4.9 regression] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.8.3
[Bug debug/54694] [4.7/4.8/4.9 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug fortran/52370] [4.7/4.8/4.9 Regression] Spurious may be used uninitialized warning for check of optional argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52370 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug middle-end/58746] [4.9 Regression] Incorrect warning with -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/59115] [4.7/4.8/4.9 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59115 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug fortran/59414] [4.8/4.9 Regression] [OOP] ICE in in gfc_conv_expr_descriptor on ALLOCATE inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.3
[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59224 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug libfortran/59513] [4.7/4.8/4.9] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
