[Bug c/58016] stdatomic.h missing in 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Noone disputes it's not conforming. The point is the support is incomplete. It's known to be incomplete. It's documented as incomplete. Reporting a bug to say it's incomplete doesn't serve any useful purpose, it will be complete when it's completed.
[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-07/msg01368.htm ||l Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- Author: uros Date: Mon Jul 29 11:17:51 2013 New Revision: 201308 URL: http://gcc.gnu.org/viewcvs?rev=201308root=gccview=rev Log: 2013-07-29 Uros Bizjak ubiz...@gmail.com * config/i386/i386.md (float post-reload splitters): Do not check for subregs of SSE registers. 2013-07-29 Uros Bizjak ubiz...@gmail.com H.J. Lu hongjiu...@intel.com PR target/57954 PR target/57988 * config/i386/i386.md (post-reload splitter to avoid partial SSE reg dependency stalls): New pattern. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- Fixed.
[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954 --- Comment #8 from vincenzo Innocente vincenzo.innocente at cern dot ch --- thanks for getting in the trunk. will be possible to back port to at least 4.8? (this issue is there till 4.4!)
[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
Yuri Rumyantsev ysrumyan at gmail dot com changed:
What|Removed |Added
CC||ysrumyan at gmail dot com
--- Comment #9 from Yuri Rumyantsev ysrumyan at gmail dot com ---
Uros,
I assume that this fix is not good and must be reverted - I will prepare
another fix for your reviewing. There are at least 2 problems:
1. New split for int -- fp converisons is done under TARGET_SSE2 and
TARGET_SSE_PARTIAL_REG_DEPENDENCY which include both Atom chips - SLT and SLM.
I checked that zeroing of xmm register before conversion leads to performance
slowdown on SLM (-5%) for proveded test-case. I assume that TARGET_AVX must be
used instead of TARGET_SSE2.
2. This zeroing must redundant and should not be inserted, e.g. for the
following simple test-case:
void foo (float* p, int n)
{
int i;
for (i=0; in; i++)
p[i] = (float) i;
}
with H.J patch we got the following assembly (I compiled it for slm but it does
not matter):
.L3:
xorps%xmm0, %xmm0
cvtsi2ss%eax, %xmm0
movss%xmm0, (%ecx,%eax,4)
addl$1, %eax
cmpl%edx, %eax
jne.L3
It is clear that zeroing is redundant for it and must be deleted.
[Bug tree-optimization/58012] Gcc bootstrap failed with cloog-isl: undefined reference to std::istream::ignore(long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58012 goughost goughost at yahoo dot com.cn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from goughost goughost at yahoo dot com.cn --- It's not the function definition, but `#include iostream' that caused the error. Either isl should get patched to `#include ostream'; or gcc provide a bigger libstdc++convenience.a that has the missing bits. The previous is easier, as long as only std::ostream is used in that header.
[Bug libfortran/37634] Fix libgfortran compiling to support GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37634 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #5 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- I think this bug was fixed by Steve Ellcey in revision 200374: r200374 | sje | 2013-06-24 17:24:19 +0200 (Mon, 24 Jun 2013) | 5 lines 2013-06-24 Steve Ellcey sell...@mips.com * configure.ac (AC_CHECK_FUNCS_ONCE): Put into if statement. * configure: Regenerate. (though, for some reason, this commit message cannot be found in libgfortran/ChangeLog). I'm closing, please reopen if it is not actually fixed (with current explanation of what goes wrong).
[Bug c/58016] stdatomic.h missing in 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
__STDC_VERSION__ describes *intent* of command-line options (as regards
differences between standard versions, to the extent that those are
implemented). This is the same principle that has been documented for
__STDC__ since at least GCC 2.0.
Sometimes people say that defining @code{__STDC__} in a compiler that
does not completely conform to the ANSI C standard somehow violates the
standard. This is illogical. The standard is a standard for compilers
that are supposed to conform. It says nothing about what any other
compilers should do. Whatever the ANSI C standard says is relevant to
the design of plain @samp{gcc} without @samp{-ansi} only for pragmatic
reasons, not as a requirement.
(quoted from the GCC 2.0 manual).
As a pragmatic matter, it's useful for users of standards modes that are
incomplete to be able to tell which of those modes is in use, and
__STDC_VERSION__ is the natural macro to define to distinguish between
them. gcc -std=c11 is a compiler explicitly claimed not to conform.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- In my opinion it would be great if you could concretely propose a patch. I'm sure that both Gaby and the other library maintainers, like me, would be fast at reviewing it. Of course, if large it would require a Copyright assignment, but maybe not.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #4 from Roy Stogner roystgnr at ices dot utexas.edu --- I oversimplified the code here to try and make the failure as easy to reproduce as possible. The term here isn't con-fusion, it's kernel fusion, which the original user code is trying to do with libstdc++ valarray expressions (and VexCL expressions, and Eigen expressions, etc; those cases work); this is essentially the opposite of assuming that expression templates match their input types. To keep equations in their own functions (for maintainability) while still doing parallel evaluation in a single loop (for efficiency), those functions need to return the expression templates which embody their equations. However, this does assume that expression template move constructors (or copy constructors if move constructors aren't defined) don't do a shallow copy of the representations of subexpression objects, and I can't see anything in C++2011 or C++2014 standards drafts *mandating* anything about those constructors. If my amateur standards-lawyering is correct, it would be fair for you to mark this as wontfix or whatever bugzilla term signifies go_bug_standards_committee_instead. On the third hand, there's nothing in the current standard mandating that the implementation *not* be robust when doing kernel fusion with user functions, either. Storing subexpressions by value in _BinBase (specializing to store by reference when the subexpression is just a valarray) might be a sufficient fix.
[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
--- Comment #10 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Yuri Rumyantsev from comment #9)
I assume that this fix is not good and must be reverted - I will prepare
another fix for your reviewing. There are at least 2 problems:
1. New split for int -- fp converisons is done under TARGET_SSE2 and
TARGET_SSE_PARTIAL_REG_DEPENDENCY which include both Atom chips - SLT and
SLM.
I checked that zeroing of xmm register before conversion leads to
performance slowdown on SLM (-5%) for proveded test-case. I assume that
TARGET_AVX must be used instead of TARGET_SSE2.
The patch is effective for my target (IvyBridge), but I see no problem to
fine-tune the split condition for other targets. Perhaps Atom should be taken
out od TARGET_SSE_PARTIAL_REG_DEPENDENCY ?
2. This zeroing must redundant and should not be inserted, e.g. for the
following simple test-case:
void foo (float* p, int n)
{
int i;
for (i=0; in; i++)
p[i] = (float) i;
}
with H.J patch we got the following assembly (I compiled it for slm but it
does not matter):
.L3:
xorps %xmm0, %xmm0
cvtsi2ss%eax, %xmm0
movss %xmm0, (%ecx,%eax,4)
addl$1, %eax
cmpl%edx, %eax
jne .L3
It is clear that zeroing is redundant for it and must be deleted.
Hm, it is not that clear. If the stall is happening in cvtsi2ss, then following
movss shouldn't matter, or at least it shouldn't make things any worse. Of
course, you have much more information at hand, so instead of the patch revert
(the patch *is* effective for certain targets), I suggest to submit a follow-up
patch that fine-tunes the split condition.
[Bug rtl-optimization/51041] g++ strange optimisation behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51041
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com ---
I guess RA is doing right thing. Pseudo 84 corresponding to variable sum when
the second printf is uncommented lives through insn throwing an
exception. The code affecting p84 allocation (putting it into memory
as SSE_REGS have no caller-saved regs) is
ira-lives.c::process_bb_node_lives:
if (can_throw_internal (insn))
{
IOR_HARD_REG_SET (OBJECT_CONFLICT_HARD_REGS (obj),
call_used_reg_set);
IOR_HARD_REG_SET (OBJECT_TOTAL_CONFLICT_HARD_REGS (obj),
call_used_reg_set);
}
Where insn is:
(call_insn 141 140 142 22 (call (mem:QI (symbol_ref:DI (_ZdlPv) [flags 0x41]
function_decl 0x71ae2400 operator delete) [0 operator delete S1 A8])
(const_int 0 [0]))
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/new_allocator.h:100
648 {*call}
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:REG_FRAME_RELATED_EXPR (use (reg:DI 5 di))
(nil)))
it is a destructor in new_allocator.h:
void
deallocate(pointer __p, size_type)
{ ::operator delete(__p); }
The problem could be solved by p84 live range splitting. By default IRA does
live range splitting only when the register pressure is high. This is not the
case for the test where max pressure for GENERAL_REGS and SSE_REGS is only 4.
We can modify semantics -fira-region=all to form a region for any loop on which
border live range splitting is done. I tried that and with -fira-region=all
the same speed is achieved for the test. Unfortunately, with the new semantics
permitting too aggressive spilling, the generated code is about 0.5% worse on
SPEC2000 for x86-64.
I guess we should pay more attention in optimizations to deal with code with EH
regions, as C++ code have a lot of such code.
I'll think what can I do more with the problem.
[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- Uh oh, but I do not really feel comfortable submitting a patch like this that I do not understand at all but happens to pass the testsuite :-)
[Bug c/58019] New: Problem with -O3 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58019
Bug ID: 58019
Summary: Problem with -O3 optimization
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: william.jordan at vbrick dot com
I wrote a simple program to solve the 8 queens chess problem (i.e. put 8 queens
on a chessboard so that no queen can take any other queen). When I compile the
program normally or with -O1 -O2 optimization it finds solutions and prints
them out. When I compile with -O3 optimization it finds no solutions.
Below is the compiler version and source code. This was also reproduced using
gcc 4.1.2.
gcc -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --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
--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
--with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
Source code to reproduce problem:
#include stdio.h
int TestPiece(int ipos, int jpos, int board[8][8])
{
int i, j;
for (i = 0; i 8; i++) {
for (j = 0; j 8; j++) {
if (board[i][j] (i != ipos || j!= jpos)) {
if (i == ipos) {
return(1);
} else if (j == jpos) {
return(2);
} else if ((ipos - i == jpos - j) || (i - ipos == jpos - j)) {
return(3);
}
}
}
}
return(0);
}
int TestBoard(int board[8][8])
{
int i, j;
for (i = 0; i 8; i++) {
for (j = 0; j 8; j++) {
if (board[i][j]) {
if (TestPiece(i, j, board)) {
return(1);
}
}
}
}
}
int PrintBoard(int board[8][8])
{
int i, j;
printf(Solution found\n\n);
for (i = 0; i 8; i++) {
for (j = 0; j 8; j++) {
if (board[i][j]) {
printf(Q);
} else {
printf(-);
}
}
printf(\n);
}
printf(\n);
}
int main(int argc, char *argv[])
{
int board[8][8];
int i, j, k, numchecks = 1;
for (i = 0; i 8; i++) {
numchecks *= 8;
for (j = 0; j 8; j++) {
if (j == 0) {
board[i][j] = 1;
} else {
board[i][j] = 0;
}
}
}
for (i = 0; i numchecks; i++) {
if (!TestBoard(board)) {
PrintBoard(board);
}
for (j = 7; j = 0; j--) {
if (board[j][7]) {
board[j][7] = 0;
board[j][0] = 1;
} else {
for (k = 0; k 7; k++) {
if (board[j][k]) {
board[j][k] = 0;
board[j][k + 1] = 1;
break;
}
}
break;
}
}
}
}
[Bug c/58016] stdatomic.h missing in 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 --- Comment #5 from Jeff Hammond jeff.science at gmail dot com --- Can someone tell me where the appropriate place to define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ in GCC so I can submit a patch? I'd rather solve the problem and take 1-2 steps forward towards C11 compliance rather than debate the philosophical aspects of the problem.
[Bug c/58019] Problem with -O3 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58019 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-07-29 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Your testcase produces obvious warnings with -Wall -Wextra. Please provide a fixed testcase (or close the bug if following the warnings solves your issue).
[Bug c/58016] stdatomic.h missing in 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 Jeff Hammond jeff.science at gmail dot com changed: What|Removed |Added CC||jeff.science at gmail dot com --- Comment #6 from Jeff Hammond jeff.science at gmail dot com --- Created attachment 30568 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30568action=edit patch to define macros indicating missing C11 support If GCC defines __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__, it is no longer non-compliant w.r.t. C11 to not provide stdatomic.h and threads.h. This would resolve bugs 53769 and 58016, albeit in a trivial way. I will not be surprised at all if this patch is rejected, if for no other reason than my institution has not signed a contributor agreement with FSF (they almost certainly will if I ask). My goal is to inspire someone else to do it properly since it seems trivial and arguably necessary.
[Bug c/58016] stdatomic.h missing in 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 --- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot com --- __STDC_NO_THREADS__ is defined in glibc's stdc-predef.h because it describes combination compiler and library properties. The correct fix for atomics for 4.9 will be to implement them - see Andrew MacLeod's patches and recent discussion on gcc-patches - and the state of C11 in 4.8 is what it is and 4.8 is subject to normal release branch rules (regression and documentation fixes only, generally).
[Bug c/58019] Problem with -O3 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58019 Bill william.jordan at vbrick dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Bill william.jordan at vbrick dot com --- Close the bug. I fixed the warnings produced by -Wall and it worked correctly.
[Bug libfortran/58020] New: Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 Bug ID: 58020 Summary: Code for handling IEEE exceptions Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com Dr. Richard Hanson has written code to provide IEEE exception handling to gfortran. He is the sole owner of that code and it could be used by gcc as they wish. The code is on my server at http://mathalacarte.com/hpcconsult He can be contacted at richard.koolh...@gmail.com. This feature is one of the oldest language features not available in gfortran, and can be a real impediment portability.
[Bug c/58016] stdatomic.h missing in 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 Jeff Hammond jeff.science at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Jeff Hammond jeff.science at gmail dot com --- My patch was w.r.t. the trunk as of earlier today, not 4.8 but that's fine. I just subscribed to various GCC lists to track these developments. I'll apply my patch locally so that I can use 4.8.1 and get the desired behavior.
[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954 --- Comment #11 from Evgeniy Dushistov dushistov at mail dot ru --- (In reply to Yuri Rumyantsev from comment #9) I checked that zeroing of xmm register before conversion leads to performance slowdown on SLM (-5%) for proveded test-case. I assume that with H.J patch we got the following assembly (I compiled it for slm but it does not matter): .L3: xorps %xmm0, %xmm0 cvtsi2ss%eax, %xmm0 movss %xmm0, (%ecx,%eax,4) addl$1, %eax cmpl%edx, %eax jne .L3 By the way, I tried compile my sample (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57988) for atom, icc(13.1.3 20130607) produce: xorps %xmm2,%xmm2 cvtsi2sd %rax,%xmm2 may be 5% measuring error?
[Bug fortran/57800] Wasted work in gfc_match_call()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Patch installed on trunk.
[Bug fortran/57801] Wasted work in resolve_variable()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57801 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Patch installed on trunk.
[Bug fortran/57791] Wasted work in gfc_check_pointer_assign()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Patch installed on trunk.
[Bug fortran/57802] Wasted work in set_loop_bounds()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57802 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Patch installed on trunk.
[Bug fortran/57804] Wasted work in gfc_trans_transfer()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57804 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Patch installed on trunk.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- 1) Hanson needs to have a copyright assignment on file with FSF before the code can be used. 2) More importantly, the code appears to only support the i386 and amd64 architectures. gfortran runs are far more processors than these. 3) messy_m.f90 includes the statement: ! This code is free for noncommercial use as long as this source ! file is included. It is recommended that the test file, tmessy ! be included as well. I haven't looked at the code to determine if messy_m.f90 is actually needed.
[Bug rtl-optimization/58021] New: MODE_EXIT switches at NOTE_INSN_DELETED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58021
Bug ID: 58021
Summary: MODE_EXIT switches at NOTE_INSN_DELETED
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amylaar at gcc dot gnu.org
The last function of gcc.dg/fold-mulconj-1.c:
_Complex int bar(_Complex int z)
{
return z * ~z;
}
gets miscompiled for epiphany-elf.
In compute_pre_exit, we break the do .. while (nregs).. loop with
last_insn pointing to a NOTE_INSN_DELETED, above which there are
two multiplies - needing a mode different than the exit.
However, because the NOTE_INSN_DELETED fails the INSN_P test,
the code that does the first split_block call is not executed,
and pre_exit ends up containing the multiplies.
[Bug c++/58022] New: Compiler rejects abstract class in template class with friend operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022
Bug ID: 58022
Summary: Compiler rejects abstract class in template class with
friend operator
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
First, apologies for the vague subject line, I really don't know what to call
this bug...
Consider the following test case:
// --- begin bug.cpp ---
#include iostream
using namespace std;
template class T class foo;
template class T ostream operator(ostream o, const fooT l);
template class T class foo {
friend ostream operator T (ostream o, const fooT l);
};
class bar;
foobar fb;
class bar { virtual void baz()=0; };
// --- end bug.cpp ---
The test case was isolated using multidelta on a large code base that compiles
cleanly with gcc-4.7 and earlier.
Compiling it with gcc-4.8.1 gives the error: cannot allocate an object of
abstract type ‘bar’, and identifying this function in ostream:
templatetypename _CharT, typename _Traits
inline basic_ostream_CharT, _Traits
operator(basic_ostream_CharT, _Traits __out, _CharT __c)
{ return __ostream_insert(__out, __c, 1); }
Replacing using namespace std with std::ostream everywhere allows it to
compile, as does moving the definition of bar above the friend declaration.
I'm not 100% certain the code is valid C++, seeing as how it instantiates a
template using an incomplete type, but there are still several issues:
1. The compiler gives no hint whatsoever where the real problem is, leaving the
user to infer the context in some other way; it took 2h with multidelta to
isolate the above test case and finally see what had happened.
2. The declaration of operator (which accepts a const ref) should not
interfere with the one in ostream (which accepts a value); without the const
ref declaration the compiler (rightfully!) complains that template-id
‘operator bar’ for ‘std::ostream operator(std::ostream, const
foobar)’ does not match any template declaration
3. At no point is bar actually instantiated, passed by value, or its members
accessed; even if operator did do one of those things, operator is never
actually called with foobar as an argument, so the template shouldn't be
instantiated.
For now, the workaround seems to be ensuring that bar is fully defined before
any template class mentions it, but that's not going to be easy given how hard
it is to find the problem (and the fact that the foo template is in a utility
library and really should be included first under normal circumstances).
[Bug c++/57948] internal compiler error: in initialize_reference, at cp/call.c:9285
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57948 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.9.0 Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c++/58022] Compiler rejects abstract class in template class with friend operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Please try to reduce the testcase further, no includes. You have a number of options here: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
[Bug c++/58022] Compiler rejects abstract class in template class with friend operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This compiles fine in mainline, doesn't with current 4_8-branch.
[Bug c++/57901] [4.8/4.9 Regression] Cannot call-by-value such that class has non-trivial (constexpr) move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57901 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.8.2
[Bug c++/58022] [4.8 Regression] Compiler rejects abstract class in template class with friend operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022
--- Comment #3 from Ryan Johnson scovich at gmail dot com ---
(In reply to Paolo Carlini from comment #1)
Please try to reduce the testcase further, no includes. You have a number of
options here: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
Sorry, I thought ostream was an important part of the bug and did some work
to put it back in... Here's the fully reduced case:
// --- begin bug.cpp ---
templatetypename _CharT
class basic_ostream;
typedef basic_ostreamchar ostream;
templatetypename T
basic_ostreamT operator(basic_ostreamT, T);
template class T class foo;
template class T ostream operator(ostream, const fooT);
template class T class foo {
friend ostream operator T (ostream, const fooT);
};
class bar;
foobar fb;
class bar { virtual void baz()=0; };
// --- end bug.cpp ---
[Bug c++/58022] [4.8 Regression] Compiler rejects abstract class in template class with friend operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-29 Target Milestone|--- |4.8.2 Ever confirmed|0 |1 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks. Confirmed as a regression present only in 4_8-branch.
[Bug middle-end/57748] [4.8/4.9 Regression] ICE on ARM with -mfloat-abi=softfp -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #5)
expand_assignment, offset as filled in get_inner_reference is the same,
however get_object_alignment (tem) used to return 64, and now only returns
32 which then pushes us the wrong path which does not handle this case. So
now I guess I should figure out why get_object_alignment thinks the
alignment is so small...
hhmm..
set_ptr_info_alignment is always called with align=4,
and by the way, the crash goes away if I change this line
(but I cannot tell if the code is correct):
--- builtins.c.jj 2013-07-06 11:34:17.0 +0200
+++ builtins.c 2013-07-29 21:50:56.0 +0200
@@ -503,7 +503,7 @@ get_pointer_alignment_1 (tree exp, unsig
*bitposp = ptr_misalign * BITS_PER_UNIT;
*alignp = ptr_align * BITS_PER_UNIT;
/* We cannot really tell whether this result is an approximation. */
- return true;
+ return false;
}
else
{
[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #23 from Thorsten Glaser tg at mirbsd dot org --- Can this please be committed, it definitely fixes gcc-4.8 on Debian/m68k (applied it locally for now and asked the maintainer to include it in the source package).
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #2 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- 1. Hanson is willing to assign the copyright if you expect to be using this work. There were thoughts to include this work on a SIAM website where we think SIAM would want the copyright, but if gfortran wants to use this work it could be posted someplace that does not require copyright. Perhaps you could provide a link that describe how this assignment can be done. The SIAM publication is still work in progress and the package can be noted as copyrighted in accordance with your standards. 2. There are no plans to support other architectures. The code is useful for the most prevalent one, and it is hoped would be useful there, as well as helpful to people interested in ports to other platforms. The Fortran standard says it is ok to *not* implement the IEEE modules, but there should be a module present on non-x86 machines that indicates this lack of support. Presently there is no support and no IEEE module of any kind. 3. The messy code is code I wrote, and is currently (I think) likely to be published in the Transactions on Mathematical Software. That code is used only in the testing code and is not used in what should be considered the main submission. It does nothing more that give pretty output of results. Please let us know, if given the above, you have an interest in pursuing this further. Fred
[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[OOP] ICE on valid with |[OOP] [F08] ICE on valid |class pointer |with class pointer |initialization |initialization --- Comment #5 from janus at gcc dot gnu.org --- Btw, pointer init is an F08 feature ...
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Mon, Jul 29, 2013 at 09:03:53PM +, fkrogh#gcc at mathalacarte dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #2 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- 1. Hanson is willing to assign the copyright if you expect to be using this work. There were thoughts to include this work on a SIAM website where we think SIAM would want the copyright, but if gfortran wants to use this work it could be posted someplace that does not require copyright. Perhaps you could provide a link that describe how this assignment can be done. The SIAM publication is still work in progress and the package can be noted as copyrighted in accordance with your standards. Given your 2) below, I suspect that the code would not be used within gfortran. If the code appears on the SIAM site or some other (semi-)permanent websire, then adding a link from the gfortran wiki under Using gfortran may be appropriate. 2. There are no plans to support other architectures. The problem is that gfortran works on a large selection of architectures. We cannot simply pick to support i386/x86_64 and ignore all the others. At the very least, IEEE_FEATURES should report that IEEE 754 is not supported for these lesser archs. The Fortran standard says it is ok to *not* implement the IEEE modules, This is sort of true. but there should be a module present on non-x86 machines that indicates this lack of support. This is not required by the standard. Presently there is no support and no IEEE module of any kind. Yep, which is permitted by the standard. The standard actually states: Whether the modules are provided is processor dependent. 3. The messy code is code I wrote, and is currently (I think) likely to be published in the Transactions on Mathematical Software. That code is used only in the testing code and is not used in what should be considered the main submission. It does nothing more that give pretty output of results. Thanks for the clarification on the messy code.
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #28 from Sebastian Pop spop at gcc dot gnu.org ---
(In reply to Evgeniy Dushistov from comment #26)
void mult(const double * const __restrict__ A, const double * const
__restrict__ B, double * const __restrict__ C, const size_t N)
{
for (size_t j = 0; j N; ++j)
for (size_t i = 0; i N; ++i)
for (size_t k = 0; k N; ++k)
C[i * N + j] += A[i * N + k] + B[k * N + j];
This code has the same problem as the Fortran program: it has linearized memory
access functions. This code won't be transformed by Graphite unless you
instantiate N with a compile time constant, or otherwise you'll have to
delinearize the array accesses, and we don't have code to do that yet.
[Bug fortran/58023] New: ICE on invalid with missing NOPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58023 Bug ID: 58023 Summary: ICE on invalid with missing NOPASS Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com The following causes and ICE using gfortran 4.9.0 (r201320): module m implicit none abstract interface double precision function mr() end function mr end interface type :: sfd procedure(mr), pointer :: mr1 procedure(mr), pointer :: mr2 end type sfd contains subroutine go() implicit none type(sfd):: d write (0,*) d%mr2() return end subroutine go end module m $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib --with-gmp=/home/abenson/Galacticus/Tools Thread model: posix gcc version 4.9.0 20130729 (experimental) (GCC) $ gfortran -c bug.F90 -o bug.o bug.F90:10.34: procedure(mr), pointer :: mr1 1 Error: Procedure pointer component 'mr1' with PASS at (1) must have at least one argument f951: internal compiler error: in update_ppc_arglist, at fortran/resolve.c:5346 0x58332a update_ppc_arglist ../../gcc-trunk/gcc/fortran/resolve.c:5346 0x57f63c resolve_expr_ppc ../../gcc-trunk/gcc/fortran/resolve.c:6020 0x57f63c gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:6119 0x5860bb resolve_code ../../gcc-trunk/gcc/fortran/resolve.c:9692 0x585e0b gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:9006 0x586099 resolve_code ../../gcc-trunk/gcc/fortran/resolve.c:9682 0x588c8e resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:14471 0x588b97 resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:14457 0x588d72 gfc_resolve ../../gcc-trunk/gcc/fortran/resolve.c:14499 0x5755bf gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4645 0x5b1545 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. The code is invalid because both procedure pointers in the sfd derived type should have the NOPASS attribute (since the mr abstract interface declares no arguments). The ICE only occurs if two (or more) procedure points are declared in this way, AND the procedure pointer is accessed (via the write statement in this example).
[Bug tree-optimization/57993] [4.9 Regression] ICE: verify_ssa failed (definition in block n does not dominate use in block m)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Bill Schmidt wschmidt at gcc dot gnu.org --- Fixed as r201325.
[Bug libstdc++/58025] New: Cannot use std::hash without setting off -Wmismatched-tags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58025 Bug ID: 58025 Summary: Cannot use std::hash without setting off -Wmismatched-tags Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: whatmannerofburgeristhis at gmail dot com The headers inconsistently declare / forward declare std::hash using struct and class, resulting in this warning when you try to use either. They should be made to consistently use struct. Testcase attached. $ clang++ -std=c++11 -Wmismatched-tags -c libstdcpp_mismatched_tags_warning.cpp -o /dev/null libstdcpp_mismatched_tags_warning.cpp:42:5: warning: 'hash' defined as a struct template here but previously declared as a class template [-Wmismatched-tags] struct hashFooB ^ /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/bits/stl_bvector.h:523:31: note: did you mean struct here? templatetypename friend class hash; ^ libstdcpp_mismatched_tags_warning.cpp:51:5: warning: 'hash' defined as a class template here but previously declared as a struct template [-Wmismatched-tags] class hashFooA ^ /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/bits/functional_hash.h:58:5: note: did you mean class here? struct hash; ^ 2 warnings generated.
[Bug libstdc++/58025] Cannot use std::hash without setting off -Wmismatched-tags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58025 --- Comment #1 from Matt Arsenault whatmannerofburgeristhis at gmail dot com --- Created attachment 30570 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30570action=edit Testcase
[Bug libstdc++/56627] class hash instead of struct hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||whatmannerofburgeristhis@gm ||ail.com --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 58025 has been marked as a duplicate of this bug. ***
[Bug libstdc++/58025] Cannot use std::hash without setting off -Wmismatched-tags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58025 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- This is one of the most questionable warnings that clang added. They should be made to consistently use struct. No they don't have to be consistent at using struct vs class in standard C++. *** This bug has been marked as a duplicate of bug 56627 ***
[Bug libstdc++/56627] class hash instead of struct hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627 --- Comment #9 from Matt Arsenault whatmannerofburgeristhis at gmail dot com --- (In reply to Andrew Pinski from comment #8) *** Bug 58025 has been marked as a duplicate of this bug. *** They don't have to be consistent by the standard, but the purpose of warnings is not to strictly report deviations from the standard. Many point out likely mistakes or inconsistencies in standard conforming code (e.g. -Wlogical-op). This is an absolutely trivial fix.
[Bug libstdc++/56627] class hash instead of struct hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627 --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Matt Arsenault from comment #9) (In reply to Andrew Pinski from comment #8) *** Bug 58025 has been marked as a duplicate of this bug. *** They don't have to be consistent by the standard, but the purpose of warnings is not to strictly report deviations from the standard. Many point out likely mistakes or inconsistencies in standard conforming code (e.g. -Wlogical-op). This is an absolutely trivial fix. Actually this warning makes less sense than -Wlogical-op due to the way struct and class are defined. -Wlogical-op makes sense since due to forgetting how || and interact, there is no interaction here, only using struct in one case and class in another which is valid and known what happens even without looking up what happens. The real reason why they added this option is due to another compiler which implements non-standard behavior for struct and class (not naming the company here but they also don't care about C99).
