[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59573 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- You need to fix qemu to implement insn 0x5ee09800 (cmeq d0, d0, #0).
[Bug fortran/59577] New: OpenMP: ICE with type(c_ptr) in private()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59577
Bug ID: 59577
Summary: OpenMP: ICE with type(c_ptr) in private()
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: 06needhamt at gmail dot com
CC: burnus at gcc dot gnu.org, jonathan.hogg at stfc dot ac.uk,
pascal22p at parois dot net, reijo.keskitalo at gmail dot
com,
spam.brian.taylor at gmail dot com
+++ This bug was initially created as a clone of Bug #51024 +++
Reported at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5513dcf7bb4b9abc
The following program segfaults at
omp_add_variable (flags=10, decl=, ctx=) at
gcc/gimplify.c:5544
5544 if (TREE_CODE (t) != INTEGER_CST)
The dump looks OK:
test ()
{
void * alloc_fftinout;
#pragma omp parallel default(none) private(alloc_fftinout)
{
{
(void) 0;
}
}
}
Test case - compiled with "-fopenmp":
program test
use, intrinsic :: iso_c_binding
implicit none
type(C_PTR) :: alloc_fftinout
!$OMP PARALLEL default(none) &
!$OMP& private(alloc_fftinout)
!$OMP END PARALLEL
end program
[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59573 Dennis.Yxun changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Dennis.Yxun --- 1) I still don't get why with this commit, it will lead to generate "cmeq" instruction, is this really necessary? 2) yes, I'd admit that the qemu I built did *not* support cmeq scalar mode, but I do have a patch which implemented this insn. and it still result at an un-usable system, very weird error.,, also I will ping qemu maintainer for suggestion.
[Bug fortran/52075] OpenMP atomic update failing if -fbounds-check specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52075 Bud Davis changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis --- The attached code does not demonstrate the error shown on the following: GNU Fortran (GCC) 4.9.0 20131220 (experimental) 32 bit / CentOS 6
[Bug c++/59394] Unused code generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59394 Georg-Johann Lay changed: What|Removed |Added Attachment #31385|0 |1 is obsolete|| --- Comment #2 from Georg-Johann Lay --- Created attachment 31500 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31500&action=edit C++ source. Please follow the bug reporting instructions and don't include headers, especcialy ones that the common GCC developer does not have. Attached a source file that compiles fine without headers. And there is nothing avr specific here.
[Bug c++/59394] Unused code generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59394 Georg-Johann Lay changed: What|Removed |Added Target|AVR | Severity|major |normal
[Bug c++/59394] Unused code generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59394 --- Comment #3 from Georg-Johann Lay --- Some more notes: If you don't want that small functions are being inlined, consider -fno-inline-small-functions. If a function is being inlined then it's body is still implemented except in the case where GCC can prove the body is never needed, for example if the function is static. If you implement two functions that result in the same code, GCC won't reuse the code for you. If you have redundant code, it is up to you to reuse it.
[Bug target/59578] New: Overuse of v prefix for SSE instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59578
Bug ID: 59578
Summary: Overuse of v prefix for SSE instructions
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: msharov at users dot sourceforge.net
typedef float v16sf __attribute__((vector_size(16)));
v16sf f (v16sf x)
{ return (__builtin_ia32_shufps (x, x, 0xff)); }
Compiled on a Haswell 4770 with -march=native -O emits:
vshufps $255, %xmm0, %xmm0, %xmm0
Even though all registers are the same and
shufps $255, %xmm0, %xmm0
would have worked just as well without the extra byte for the v prefix.
This happens with other __builtin instructions as well. For example:
typedef long long v16so __attribute__((vector_size(16)));
v16so k (v16so x)
{ return (__builtin_ia32_aeskeygenassist128 (x, 1)); }
Emits vaeskeygenassist even though no memory accesses are present.
[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59573 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- (In reply to Dennis.Yxun from comment #2) > 1) I still don't get why with this commit, it will lead to generate "cmeq" > instruction, is this really necessary? Well the register allocator changed which leads to a different alternative being selected here so most likely. > > 2) yes, I'd admit that the qemu I built did *not* support cmeq scalar mode, > but I do have a patch which implemented this insn. and it still result at an > un-usable system, very weird error.,, also I will ping qemu maintainer for > suggestion. Can you try using ARM's foundation model (or another simulator) which should be easier to compare against?
[Bug c++/59579] New: Defaulted copy constructor of template class is instantiated even when not called (probably bug 57153)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59579
Bug ID: 59579
Summary: Defaulted copy constructor of template class is
instantiated even when not called (probably bug 57153)
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Konstantin.Sadov at gmail dot com
The following code
struct A{A()=default;A(A&)=default;};
templatestruct C:B{C()=default;
#if 1
C(const C&)=default;//Fails
#else
C(const C&c):B(c){};//Works
#endif
};
C d;
int main(){}
produces the following error
$g++ -std=c++11 main.cpp
main.cpp: In instantiation of 'struct C':
main.cpp:9:6: required from here
main.cpp:4:1: error: 'C::C(const C&) [with B = A]' declared to take const
reference, but implicit declaration would take non-const
C(const C&)=default;//Fails
^
Looks like defaulted function is implicitly instantiated even if it's not used
(it's not so for user-defined functions).
GCC 4.4 worked well with this case.
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569 --- Comment #5 from David Binderman --- (In reply to Zhendong Su from comment #4) > Below is a very similar testcase that I've encountered: I have a third test case available on request.
[Bug bootstrap/59580] New: --with-arch=generic is allowed to configure GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59580 Bug ID: 59580 Summary: --with-arch=generic is allowed to configure GCC Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: ubizjak at gmail dot com Target: x86-64, x86 When GCC is configured with /export/gnu/import/git/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared i686-linux --prefix=/usr/gcc-4.9.0 --with-local-prefix=/usr/local --with-arch=generic --with-fpmath=sse bootstrap fails with /i686-linux/include -isystem /usr/gcc-4.9.0/i686-linux/sys-include checking for suffix of object files... configure: error: in `/export/build/gnu/gcc-test-32bit/build-i686-linux/i686-linux/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. configure:3602: /export/build/gnu/gcc-test-32bit/build-i686-linux/./gcc/xgcc -B/export/build/gnu/gcc-test-32bit/build-i686-linux/./gcc/ -B/usr/gcc-4.9.0/i686-linux/bin/ -B/usr/gcc-4.9.0/i686-linux/lib/ -isystem /usr/gcc-4.9.0/i686-linux/include -isystem /usr/gcc-4.9.0/i686-linux/sys-include-c -g -O2 conftest.c >&5conftest.c:1:0: error: generic CPU can be used only for -mtune= switch
[Bug target/59578] Overuse of v prefix for SSE instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59578 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- That is intentional, please read something about SSE to AVX transition penalties, e.g. http://software.intel.com/sites/default/files/m/d/4/1/d/8/11MC12_Avoiding_2BAVX-SSE_2BTransition_2BPenalties_2Brh_2Bfinal.pdf
[Bug fortran/59345] _gfortran_internal_pack on compiler generated temps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59345 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed at r206155.
[Bug c++/59579] Defaulted copy constructor of template class is instantiated even when not called (probably bug 57153)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59579
--- Comment #1 from Konstantin Sadov ---
Similar programs with defaulted default and move constructors work, so the
problem is for copy constructor only.
struct A{A()=delete;A(A&)=default;};
template
struct C:B{C()=default;C(C&)=default;};
C d(d);
int main(){}
struct A{A()=default;A(A&&)=delete;};
template
struct C:B{C()=default;C(C&&)=default;};
C d;
int main(){}
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569 --- Comment #6 from H.J. Lu --- (In reply to David Binderman from comment #5) > (In reply to Zhendong Su from comment #4) > > Below is a very similar testcase that I've encountered: > > I have a third test case available on request. Please upload it here. Thanks.
[Bug target/59581] New: [SH] insns that use r0...r7 are put into delay slot of rte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59581
Bug ID: 59581
Summary: [SH] insns that use r0...r7 are put into delay slot of
rte
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The following code:
extern int* ext_buf;
void __attribute__((interrupt_handler, nosave_low_regs)) my_handler (void)
{
ext_buf[0] = 4;
}
compiled with -m4 -O2 results in:
mov.l .L26,r1
mov #4,r2
mov.l @r1,r1
rte
mov.l r2,@r1
On SH3* and SH4* such ISRs are supposed to run with SR.RB = 1 (second set of
r0...r7 registers selected). The rte insn will then switch back to SR.RB = 0.
The insn in the rte delay slot refers to the restored SSR -> SR value, i.e. it
will use SR.RB = 0 and thus the code above is wrong.
If an ISR has the 'nosave_low_regs' attribute set and the target is SH3* or
SH4* there should be no insns allowed in the rte delay slot that refer to
r0...r7.
[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59573 --- Comment #4 from Dennis.Yxun --- (In reply to Andrew Pinski from comment #3) > Can you try using ARM's foundation model (or another simulator) which should > be easier to compare against? Yes, I've tried with foundation_v8, and not only it extremely slow, but also it fails here. compiling gcc in qemu takes 5hours, but takes one week (someone told me) in foudation model. for another simulator, do you have any suggestion?
[Bug lto/59582] New: LTO discards symbol that defined as weak elsewhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59582
Bug ID: 59582
Summary: LTO discards symbol that defined as weak elsewhere
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: joey.ye at arm dot com
~/work/lto_startup_s/3 $ cat Makefile
CC=gcc
CFLAGS=-flto
EXT_CFLAGS=
e : ext.o main.o
$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@
ext.o : ext.c
$(CC) $(EXT_CFLAGS) -c -o $@ $^
~/work/lto_startup_s/3 $ cat main.c
int callback() { return 0; }
int main() { return s_func(); }
~/work/lto_startup_s/3 $ cat ext.c
__attribute__((weak)) int callback() { return 1; }
int s_func() { return callback(); }
~/work/lto_startup_s/3 $ make -B
gcc -c -o ext.o ext.c
gcc -flto -c -o main.o main.c
gcc -flto ext.o main.o -o e
`callback' referenced in section `.text' of ext.o: defined in discarded section
`.text' of main.o (symbol from plugin)
collect2: error: ld returned 1 exit status
make: *** [e] Error 1
~/work/lto_startup_s/3 $ gcc -v
gcc version 4.9.0 20131223 (experimental)
Hints to reproduce:
1. ext.c is compiled without lto
2. main.o shows before ext.o in command line
[Bug rtl-optimization/57422] [4.9 Regression] ICE: SIGSEGV in dominated_by_p with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57422 --- Comment #4 from Andrey Belevantsev --- Author: abel Date: Mon Dec 23 06:41:22 2013 New Revision: 206173 URL: http://gcc.gnu.org/viewcvs?rev=206173&root=gcc&view=rev Log: PR rtl-optimization/57422 * sel-sched.c (mark_unavailable_hard_regs): Fix typo when calling add_to_hard_reg_set. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c
[Bug rtl-optimization/57422] [4.9 Regression] ICE: SIGSEGV in dominated_by_p with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57422 --- Comment #5 from Andrey Belevantsev --- Author: abel Date: Mon Dec 23 06:43:49 2013 New Revision: 206174 URL: http://gcc.gnu.org/viewcvs?rev=206174&root=gcc&view=rev Log: PR rtl-optimization/57422 * sel-sched.c (fill_vec_av_set): Assert that the fence insn can always be scheduled in its current form. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c
[Bug rtl-optimization/57422] [4.9 Regression] ICE: SIGSEGV in dominated_by_p with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57422 Andrey Belevantsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrey Belevantsev --- Fixed on trunk with rev. 206173, extra asserts added in rev. 206174. The 206173 hunk will also be put in 4.8.
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569 --- Comment #7 from David Binderman --- Created attachment 31501 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31501&action=edit C source code Source code from bug # 45948. Compiler flag -O3 required. Machine type x86_64.
