[Bug libstdc++/66055] hash containers missing required reserving constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66055 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Jun 22 15:53:14 2015 New Revision: 224740 URL: https://gcc.gnu.org/viewcvs?rev=224740root=gccview=rev Log: Backport from mainline 2015-05-14 Nathan Myers n...@cantrip.org Jonathan Wakely jwak...@redhat.com PR libstdc++/66055 * include/std/unordered_map (unordered_map, unordered_multimap): Add missing constructors. * include/std/unordered_set (unordered_set, unordered_multiset): Likewise. * testsuite/23_containers/unordered_map/cons/66055.cc: New. * testsuite/23_containers/unordered_multimap/cons/66055.cc: New. * testsuite/23_containers/unordered_multiset/cons/66055.cc: New. * testsuite/23_containers/unordered_set/cons/66055.cc: New. Added: branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/unordered_map/cons/66055.cc branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/cons/66055.cc branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/cons/66055.cc branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/unordered_set/cons/66055.cc Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/unordered_map.h branches/gcc-5-branch/libstdc++-v3/include/bits/unordered_set.h
[Bug debug/66629] New: eee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66629 Bug ID: 66629 Summary: eee Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: netfuzzer at yandex dot com Target Milestone: --- eeedfff
[Bug ipa/66616] fipa-cp-clone ignores thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616 --- Comment #3 from vries at gcc dot gnu.org --- fails on gcc-4_9-branch
[Bug middle-end/66630] Missing ubsan/ftrapv error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66630 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- That's one thing. But there also something else going on. I hope it's just missing TYPE_OVERFLOW_SANITIZED in some match.pd patterns.
[Bug c++/65843] [5/6 Regression] multiple use of const variable in lamba in template function causes compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 5.2.
[Bug middle-end/66630] Missing ubsan/ftrapv error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66630 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This might be because we convert -i - 1 to be ~i.
[Bug libstdc++/65393] std::thread shared_ptr inefficiency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65393 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Jun 22 15:53:27 2015 New Revision: 224742 URL: https://gcc.gnu.org/viewcvs?rev=224742root=gccview=rev Log: Backport from mainline 2015-06-16 Jonathan Wakely jwak...@redhat.com PR libstdc++/65393 * src/c++11/thread.cc (thread::_M_make_thread): Replace shared_ptr copies with moves. Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/src/c++11/thread.cc
[Bug libstdc++/66055] hash containers missing required reserving constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66055 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 5.2
[Bug c++/66515] [5/6 Regression] g++ segfaults when creating an std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66515 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jun 22 17:24:25 2015 New Revision: 224748 URL: https://gcc.gnu.org/viewcvs?rev=224748root=gccview=rev Log: PR c++/66515 * call.c (implicit_conversion): Only reshape for classes. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug testsuite/66621] [4.9/5/6 Regression] Mistakenly unsupported tests in g++.dg/torture/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66621 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jun 22 17:24:37 2015 New Revision: 224749 URL: https://gcc.gnu.org/viewcvs?rev=224749root=gccview=rev Log: PR testsuite/66621 * g++.dg/debug, g++.dg/torture: Use dg-options rather than target requirements for C++11 tests. Modified: trunk/gcc/testsuite/g++.dg/debug/localclass1.C trunk/gcc/testsuite/g++.dg/debug/nullptr01.C trunk/gcc/testsuite/g++.dg/torture/pr40991.C trunk/gcc/testsuite/g++.dg/torture/pr47559.C trunk/gcc/testsuite/g++.dg/torture/pr49770.C trunk/gcc/testsuite/g++.dg/torture/pr51198.C trunk/gcc/testsuite/g++.dg/torture/pr53161.C trunk/gcc/testsuite/g++.dg/torture/pr53602.C trunk/gcc/testsuite/g++.dg/torture/pr55260-1.C trunk/gcc/testsuite/g++.dg/torture/pr56768.C trunk/gcc/testsuite/g++.dg/torture/pr59265.C trunk/gcc/testsuite/g++.dg/torture/vshuf-main.inc trunk/gcc/testsuite/g++.dg/torture/vshuf-v16hi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v16qi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2df.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2di.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2sf.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v2si.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4df.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4di.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4sf.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v4si.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v8hi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v8qi.C trunk/gcc/testsuite/g++.dg/torture/vshuf-v8si.C
[Bug middle-end/66630] New: Missing ubsan/ftrapv error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66630
Bug ID: 66630
Summary: Missing ubsan/ftrapv error
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
int
main (void)
{
int i = -__INT_MAX__ - 1;
int j = -i - 1;
return j;
}
$ xgcc -fsanitize=undefined a.c; ./a.out
says nothing :(. We should report the overflow when computing -i.
[Bug jit/66627] Tracker bug for jit bugs affecting ravi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627 --- Comment #1 from David Malcolm dmalcolm at gcc dot gnu.org --- Note to self: not all of the jit fixes on trunk had a bug attached; should review jit/ChangeLog.
[Bug c++/65880] [5/6 Regression] Member function issue with argument pointer to const array of member function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65880 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |5.2 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug libstdc++/55977] [C++11] vector range construction imposes unnecessary conversion constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55977 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.1 Known to fail||4.8.0 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- This was fixed for 4.8.1
[Bug ipa/66616] fipa-cp-clone ignores thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616 --- Comment #4 from vries at gcc dot gnu.org --- passes for gcc-4_8-branch
[Bug jit/66627] New: Tracker bug for jit bugs affecting ravi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627 Bug ID: 66627 Summary: Tracker bug for jit bugs affecting ravi Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Depends on: 66539, 66546, 66594, 66610 Target Milestone: --- Ravi (https://github.com/dibyendumajumdar/ravi) is a JIT-compiler for Lua which has an experimental libgccjit backend. This is a tracker bug to help me keep track of libgccjit issues affecting Ravi. Ideally all of them would be fixed in gcc 5.2. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66539 [Bug 66539] Missing parentheses in jit dumps https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66546 [Bug 66546] No way to disable check for unreachable blocks https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594 [Bug 66594] jitted code should use -mtune=native https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66610 [Bug 66610] Aggregate assignment prevents store-motion
[Bug c/66397] sanitize=undefined triggers extra -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66397 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Closing.
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- Fixed for 6.0.
[Bug jit/66628] New: jit: Provide a way to add arbitrary options to the toplev command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66628 Bug ID: 66628 Summary: jit: Provide a way to add arbitrary options to the toplev command line Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Blocks: 66627 Target Milestone: --- Experimenting with adding arbitrary command-line options to toplev::main from libgccjit requires recompiling libgccjit each time; we should expose an API for doing this, perhaps with a big caveat that only some options can ever be supported. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627 [Bug 66627] Tracker bug for jit bugs affecting ravi
[Bug libstdc++/64657] Support iterators with overloaded operator-comma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64657 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Jun 22 15:09:14 2015 New Revision: 224736 URL: https://gcc.gnu.org/viewcvs?rev=224736root=gccview=rev Log: PR libstdc++/64657 * include/bits/stl_uninitialized.h (__uninitialized_copy::__uninit_copy): Cast expression to void. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_uninitialized.h
[Bug c/66373] gcc downloaded from Fedora 21 repository produces defective executable. Same source code with gcc from Fedora 19 and Fedora 20 works fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66373 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-06-22 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug driver/36312] should refuse to overwrite input file with output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||yongjin.ohn at lge dot com --- Comment #19 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 66531 has been marked as a duplicate of this bug. ***
[Bug target/66560] Fails to generate ADDSUBPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66560 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-22 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 35827 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35827action=edit Patch to imtroduce combiner splitters to allow all possible permutations This patch introduces combiner splitters to allow all possible permutations of operators and operands in the addsub pattern. The splitters canonicalize all patterns to (vec_merge (minus ...) (plus...) sel) operation.
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 --- Comment #18 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Mon Jun 22 20:48:05 2015 New Revision: 224761 URL: https://gcc.gnu.org/viewcvs?rev=224761root=gccview=rev Log: 2015-06-22 Vladimir Makarov vmaka...@redhat.com PR bootstrap/63740 * lra-lives.c (process_bb_lives): Check insn copying the same reload pseudo and don't create a copy for it. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/lra-lives.c
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Stas Sergeev from comment #3) The signal handler needs to do the following things: 1. Restore segment registers (init_handler() func) Why are you doing this, that is the question I am trying to understand here. What signal handler is happening? Because you can't do this under Linux at all. I am also trying to understand if you are writing a kernel/userspace why you can't write this part in pure assembly function instead of using GCC here to do this work.
[Bug fortran/66366] ICE on invalid with non-allocatable CLASS variable [OOP]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366 --- Comment #3 from Andrew Benson abensonca at gmail dot com --- Note the name conflict between: type :: spsf and type(h5) :: spsf in the previous comment. Changing the name of either to make them distinct removes the ICE.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Stas Sergeev from comment #5) (In reply to Andrew Pinski from comment #4) (In reply to Stas Sergeev from comment #3) The signal handler needs to do the following things: 1. Restore segment registers (init_handler() func) Why are you doing this, that is the question I am trying to understand here. What signal handler is happening? Ah, OK. This is a jit compiler. It uses segment registers at will, and it uses a memory protection too, so the signal is SIGSEGV. That seems bogus usage really. And very unportable. Don't use segment registers at all. Because you can't do this under Linux at all. What exactly do you mean? I am also trying to understand if you are writing a kernel/userspace why you can't write this part in pure assembly function instead of using GCC here to do this work. How am I supposed to access TLS in asm? init_handler() itself is mostly in asm though, yes. But the main sighandler is a huge convoluted func.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Stas Sergeev from comment #7) (In reply to Andrew Pinski from comment #6) (In reply to Stas Sergeev from comment #5) (In reply to Andrew Pinski from comment #4) (In reply to Stas Sergeev from comment #3) The signal handler needs to do the following things: 1. Restore segment registers (init_handler() func) Why are you doing this, that is the question I am trying to understand here. What signal handler is happening? Ah, OK. This is a jit compiler. It uses segment registers at will, and it uses a memory protection too, so the signal is SIGSEGV. That seems bogus usage really. And very unportable. Don't use segment registers at all. Well, I can't, sorry. :) Please note that clang is getting this fixed already it seems: Clang is not GCC. Really you should not be using the fs segment register for your own use as it is part of the ABI that is the TLS segment. Any other use it of it is outside of the ABI and will break everything else. Why can't you not use fs segment?
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #8 from Stas Sergeev stsp at users dot sourceforge.net --- Note that O0 and O1 are fine. Only O2 gives the problem. So there might be a simple solution somewhere!
[Bug c++/66632] Incorrect use of default constructor to initialize isolated rvalue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66632 --- Comment #1 from jasonxbell at gmail dot com --- Correction: In the sentence The lvalue q1 is then init'd via copy of the (incorrectly init'd) rvalue from the previous statement., replace q1 with q2.
[Bug inline-asm/66631] New: inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
Bug ID: 66631
Summary: inability to clobber segment regs makes tls
problematic
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Hello.
On x86 (32/64) gcc uses FS register for TLS.
When writing a signal handler, a special care
must be taken: FS register must be restored by
hands, together with all other segment registers,
because linux unfortunately does not do that
(except cs and ds).
Then signal handler can access the thread-local
data safely... except that it can't.
After calling the function that restores the
segment registers, I need to specify that FS was
clobbered, which is currently not possible with
the inline asm.
As a result, the following code is generated:
0x004438c0 +0: push %r14
0x004438c2 +2: mov%edi,%r14d
0x004438c5 +5: push %r13
0x004438c7 +7: mov%rdx,%r13
0x004438ca +10:push %r12
0x004438cc +12:lea0x28(%rdx),%r12
0x004438d0 +16:push %rbp
0x004438d1 +17:mov%r12,%rdi
0x004438d4 +20:mov%fs:0x0,%rbp
0x004438dd +29:push %rbx
0x004438de +30:add$0xff80,%rsp
0x004438e2 +34:callq 0x4441b0 init_handler
0x004438e7 +39:mov0x35070a(%rip),%rbx# 0x793ff8
0x004438ee +46:mov0x0(%rbp,%rbx,1),%eax -- STACK FAULT
init_handler() is a function that restore the segregs -
it is called first in a function:
---
{
init_handler(scp);
// asm volatile(:::fs);
fault_cnt++;
---
fault_cnt is a thread-local var:
extern volatile __thread int fault_cnt;
As you can see, gcc doesn't move the access to
fault_cnt below init_handler(), but, unfortunately,
it moved the address calculation. To prevent this,
I need to clobber the FS, but it doesn't seem to be
possible.
Please let me know if there are any work-arounds to that.
It seems to be a bug that gcc does not allow clobbering
the segregs that it use.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #7 from Stas Sergeev stsp at users dot sourceforge.net --- (In reply to Andrew Pinski from comment #6) (In reply to Stas Sergeev from comment #5) (In reply to Andrew Pinski from comment #4) (In reply to Stas Sergeev from comment #3) The signal handler needs to do the following things: 1. Restore segment registers (init_handler() func) Why are you doing this, that is the question I am trying to understand here. What signal handler is happening? Ah, OK. This is a jit compiler. It uses segment registers at will, and it uses a memory protection too, so the signal is SIGSEGV. That seems bogus usage really. And very unportable. Don't use segment registers at all. Well, I can't, sorry. :) Please note that clang is getting this fixed already it seems: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140714/110476.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140714/110481.html (not sure, just googled) Really, no even a -mno-xxx option to disable this optimization?
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #3 from Stas Sergeev stsp at users dot sourceforge.net --- The signal handler needs to do the following things: 1. Restore segment registers (init_handler() func) 2. Increment thread-local var (fault_cnt) 3. Do stuff including reads of fault_cnt var Being thread-local, fault_cnt var is being accessed with the help of FS, but FS is only valid after the call to init_handler(). Since fault_cnt is marked as volatile, gcc does not move the access to it above the init_handler() call, so that part is fine. What is NOT fine is this: 0x004438d4 +20:mov%fs:0x0,%rbp -- (bad) TLS access 0x004438dd +29:push %rbx 0x004438de +30:add$0xff80,%rsp 0x004438e2 +34:callq 0x4441b0 init_handler -- FS now valid 0x004438e7 +39:mov0x35070a(%rip),%rbx# 0x793ff8 0x004438ee +46:mov0x0(%rbp,%rbx,1),%eax -- STACK FAULT As you can see, gcc moved some TLS access above init_handler(), which results in a stack fault later when trying to read from fault_cnt. To prevent moving any TLS access around init_handler(), I need to do the following: asm volatile(:::fs); but this gives a compilation error. Is the explanation clear?
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #11 from Stas Sergeev stsp at users dot sourceforge.net --- (In reply to Andrew Pinski from comment #9) Clang is not GCC. Really you should not be using the fs segment register for your own use as it is part of the ABI that is the TLS segment. Any other use it of it is outside of the ABI and will break everything else. Why can't you not use fs segment? Alien code in place (think of wine/dosemu). Also why can't you write your segfault handler in assembly when you fixup the fs segment and then call the C functions? In principle - yes, but in practice - looking into a source - too much work. It is large, and it also uses a syscalls: sys_prctl(ARCH_SET_FS, eflags_fs_gs.fsbase); Do syscalls in asm too? :( Of course this all is possible, but... Should I really resort to always using -O1 till that also break? :( Let me ask you from the other side: why not simply to allow clobber also segregs? Improvement for everyone IMHO. clang did that for chromium it seems - likely a jit either. IMHO gcc should allow writing the specific things like signal handlers, interrupt handlers in embedded systems, etc - they all have suprises and deviations from ABI, yet gcc usually has an extensions to cover all these needs. Why to suddenly change that good practice?
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #1 from Stas Sergeev stsp at users dot sourceforge.net --- Please note that the shown code was generated with gcc-4.8.2, but inability to clobber segreg with inline asm was tested with gcc-5.1.1. A bit of dissonance here, I can't do both tests with similar gcc. Is there some magic -mno-xxx option that will prevent gcc from moving the addr caclulus too far away from the access to the volatile var?
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Can you better describe your use case because this is not obvious what you are trying to achieve here.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- Also why can't you write your segfault handler in assembly when you fixup the fs segment and then call the C functions?
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #12 from Stas Sergeev stsp at users dot sourceforge.net --- Note that on x86_64 you can't set FS without a syscall. I would really hate doing that in asm it seems.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #15 from Stas Sergeev stsp at users dot sourceforge.net --- (In reply to Andrew Pinski from comment #13) Those all have pure assembly code to handle this case. No, they actually simply don't use TLS in a handler. That's something I'll be looking into too to save me from all that pain, but its not like they write a part of sighandler in asm and do the syscalls in asm. That is they have wrapper code which handles the first part in pure C Guess you meant pure asm here. and then pass it on to the other code. If you have such an evidence - the URL would be nice. From what I see they avoid the troubles simply by not using TLS. I don't see why you need to do the first part in assembly code and then pass it on to C code. Do you suggest syscalls in asm? int80h? sysenter? Or why do you need to use the fs segment when it is part of the x86 Linux ABI? It seems like you are outside of C/ABI at this stage and need pure assembly to fix up your code. Again this is outside of the x86 Linux ABI and GCC should not handle this at all. gcc handles many many things that are outside the ABI imho. It has many function attributes for all the weird cases... except this one of course. :) Yes because you are setting the TLS segment. Again why are you abusing the fs segment here not to be the TLS segment? IMHO linux itself should have been restoring FS. It doesn't, and as such, the signal handlers are violating the ABI. gcc can kindly fulfill the gap with just a small patch, as clang did, or even just by telling me the magic -mno-xxx option, or force the users to suffer.
[Bug fortran/66633] New: ICE on valid verify_gimple failed with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633 Bug ID: 66633 Summary: ICE on valid verify_gimple failed with OpenMP Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following causes an ICE in gfortran 6.0.0 (r224761): module spls type :: spc contains procedure :: l = spcL end type spc contains function spl() class(spc), pointer :: spc_ !$omp parallel write (0,*) igrt(fli) !$omp end parallel contains double precision function fli() fli=spc_%l() end function fli end function spl double precision function spcL(s) implicit none class(spc), intent(inout) :: s return end function spcL end module spls $ gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc-trunk/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 6.0.0 20150622 (experimental) (GCC) gfortran -c tmp.F90 -o tmp.o -fopenmp tmp.F90:11:0: write (0,*) igrt(fli) ^ Error: invalid argument to gimple call error .fli D.3429 = __builtin_adjust_trampoline ( error .fli); tmp.F90:11:0: internal compiler error: verify_gimple failed 0xbaf19d verify_gimple_in_seq(gimple_statement_base*) ../../gcc-trunk/gcc/tree-cfg.c:4790 0xab14b0 execute_function_todo ../../gcc-trunk/gcc/passes.c:1987 0xab1c63 execute_todo ../../gcc-trunk/gcc/passes.c:2042 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.
[Bug fortran/66366] ICE on invalid with non-allocatable CLASS variable [OOP]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366 --- Comment #2 from Andrew Benson abensonca at gmail dot com --- This reduced test case produces an ICE with similar backtrace, although it doesn't share the problem of having a non-allocatable/pointer CLASS variable (as far as I can tell): module sps type :: spsf end type spsf type :: h5 contains procedure :: c = hC end type h5 contains subroutine frf() type(h5) :: spsf call spsf%c() end subroutine frf subroutine hC(s) class(h5), intent(inout) :: s end subroutine hC end module sps
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #5 from Stas Sergeev stsp at users dot sourceforge.net --- (In reply to Andrew Pinski from comment #4) (In reply to Stas Sergeev from comment #3) The signal handler needs to do the following things: 1. Restore segment registers (init_handler() func) Why are you doing this, that is the question I am trying to understand here. What signal handler is happening? Ah, OK. This is a jit compiler. It uses segment registers at will, and it uses a memory protection too, so the signal is SIGSEGV. Because you can't do this under Linux at all. What exactly do you mean? I am also trying to understand if you are writing a kernel/userspace why you can't write this part in pure assembly function instead of using GCC here to do this work. How am I supposed to access TLS in asm? init_handler() itself is mostly in asm though, yes. But the main sighandler is a huge convoluted func.
[Bug c++/66632] New: Incorrect use of default constructor to initialize isolated rvalue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66632
Bug ID: 66632
Summary: Incorrect use of default constructor to initialize
isolated rvalue.
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jasonxbell at gmail dot com
Target Milestone: ---
Created attachment 35828
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35828action=edit
Preprocessed source file
In the following code, the first statement in main() -- 'Q(S1v1)' -- creates an
isolated rvalue; g++ uses the default constructor to initialize it instead of
'Q::Q(S1 x)'. The lvalue q1 is then init'd via copy of the (incorrectly init'd)
rvalue from the previous statement.
bug2.c:
#include iostream
using std::cout;
using std::ostream;
enum S1 { S1v0 = 0, S1v1= 10, S1v2, S1v3 };
class Q
{
public:
Q() : mySN(nextSN++), s1val(S1v0) { cout +Q
# mySN Default\n; }
Q(const Q src ) : mySN(nextSN++), s1val(src.s1val) { cout +Q
# mySN Copy from # src.mySN '\n'; }
explicit Q(S1 x) : mySN(nextSN++), s1val(x) { cout +Q
# mySN from S1\n; }
private:
int mySN;
S1 s1val;
static int nextSN;
friend ostream operator( ostream out, const Q obj );
};
int Q::nextSN = 1;
ostream operator( ostream out, const Q obj )
{
out Q # obj.mySN == obj.s1val '\n';
return out;
}
int main( void )
{
Q(S1v1);
Q q2{S1v1};
cout '\n';
cout q2;
return 0;
}
Compile and run:
$ g++ -std=c++11 -pedantic -Wall -Wextra bug2.cpp; ./a.exe
+Q #1 Default
+Q #2 Copy from #1
Q #2 == 0
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-3.x86_64/src/gcc-4.9.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-3.x86_64/src/gcc-4.9.2
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread model: posix
gcc version 4.9.2 (GCC)
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Stas Sergeev from comment #11) (In reply to Andrew Pinski from comment #9) Clang is not GCC. Really you should not be using the fs segment register for your own use as it is part of the ABI that is the TLS segment. Any other use it of it is outside of the ABI and will break everything else. Why can't you not use fs segment? Alien code in place (think of wine/dosemu). Those all have pure assembly code to handle this case. That is they have wrapper code which handles the first part in pure C and then pass it on to the other code. Also why can't you write your segfault handler in assembly when you fixup the fs segment and then call the C functions? In principle - yes, but in practice - looking into a source - too much work. It is large, and it also uses a syscalls: sys_prctl(ARCH_SET_FS, eflags_fs_gs.fsbase); Do syscalls in asm too? :( Of course this all is possible, but... I don't see why you need to do the first part in assembly code and then pass it on to C code. Should I really resort to always using -O1 till that also break? :( Let me ask you from the other side: why not simply to allow clobber also segregs? Improvement for everyone IMHO. clang did that for chromium it seems - likely a jit either. IMHO gcc should allow writing the specific things like signal handlers, interrupt handlers in embedded systems, etc - they all have suprises and deviations from ABI, yet gcc usually has an extensions to cover all these needs. Why to suddenly change that good practice? Or why do you need to use the fs segment when it is part of the x86 Linux ABI? It seems like you are outside of C/ABI at this stage and need pure assembly to fix up your code. Again this is outside of the x86 Linux ABI and GCC should not handle this at all.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #14 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Stas Sergeev from comment #12) Note that on x86_64 you can't set FS without a syscall. I would really hate doing that in asm it seems. Yes because you are setting the TLS segment. Again why are you abusing the fs segment here not to be the TLS segment?
[Bug rtl-optimization/66351] [6 regression] r223883 miscompiles stage2 compiler on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66351 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Mon Jun 22 07:02:50 2015 New Revision: 224719 URL: https://gcc.gnu.org/viewcvs?rev=224719root=gccview=rev Log: PR ipa/66351 * ipa-polymorphic-call.c (ipa_polymorphic_call_context::get_dynamic_type): Fix thinko when initializing alias oracle; fix formating; set base_alias_set if it is known. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-polymorphic-call.c
[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Mon Jun 22 07:12:22 2015 New Revision: 224720 URL: https://gcc.gnu.org/viewcvs?rev=224720root=gccview=rev Log: PR ipa/65908 * ipa-icf.c (sem_item::target_supports_symbol_aliases): Remove construction of arg_types. (sem_function::sem_function): Likewise. (sem_function::~sem_function): Remove destruction of arg_types. (sem_function::compatible_parm_types_p): New function. (sem_function::equals_wpa): Reorg matching of return values and parameter types. (sem_function::equals_private): Reorg mathcing of argument types. (sem_function::parse_tree_args): Remove. * ipa-icf.h (init_wpa): Do not call it. (parse_tree_args): Remove. (compatible_parm_types_p): Declare. (result_type): Remove. (arg_types): Remove. * testsuite/g++.dg/ipa/pr65908.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/ipa/pr65908.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c trunk/gcc/ipa-icf.h trunk/gcc/testsuite/ChangeLog
[Bug c/66622] -Wsign-conversion does not take advantage of data flow analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66622 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- It would be great if someone tried to implement this someday, it doesn't seem trivial though. (In reply to Mikhail Maltsev from comment #1) Clang also gives false positive. EDG does not warn for such conversions (even unconditional). As far as I can tell, if the warning is given in the FE by using some kind of limited VRP (which is what Clang does), the number of false positives can only decrease, since the worst that can happen is that the analysis is not powerful enough. The main objection to this has been the extra compilation time that this analysis may require just for a warning (with GCC being already too slow). Implementing it in the middle-end seems to me worse, since, as you point out, then you may increase the number of false positives and strange things may happen once other optimizations transform the code (also, optimization may hide valid warnings). A third proposal that has been floated around is to somehow mark the statement with the warning but not emit it until after optimization. If the warning survives after the middle-end analysis, then it will be given. This approach seems even more complex to me. *** This bug has been marked as a duplicate of bug 38470 ***
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||john.marshall at sanger dot ac.uk --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 66622 has been marked as a duplicate of this bug. ***
[Bug testsuite/66621] [4.9/5/6 Regression] Mistakenly unsupported tests in g++.dg/torture/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66621 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.3
[Bug debug/66503] [4.9/5/6 Regression] missing DW_AT_abstract_origin for cross-unit call sites
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66503 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug fortran/66549] [5 Regression] ICE on valid in OMP parallel region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66549 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Summary|[5/6 Regression] ICE on |[5 Regression] ICE on valid |valid in OMP parallel |in OMP parallel region |region |
[Bug c++/66515] [5/6 Regression] g++ segfaults when creating an std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66515 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- FIxed.
[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug c/66622] -Wsign-conversion does not take advantage of data flow analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66622
Mikhail Maltsev miyuki at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
CC||miyuki at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org ---
That is possible to implement, but not easy. The compiler transforms code in
such a way that lots of information is lost and it's hard to tell which code
was written by user, and which was generated by the compiler. Very few warnings
are actually emitted at the stage when data flow (use-def chains and value
ranges) is known (for example -Wmaybe-uninitialized, but it has rather frequent
false positives:
https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=Wmaybe-uninitialized).
In your case the program will look like this at very early stage:
unsigned foo(int i)
{
unsigned result;
if (i 0)
goto bb1;
else
goto bb2;
bb1:
result = 0;
return result;
bb2:
result = (unsigned)i;
return result;
}
Later it will be impossible to say, whether the conversion was introduced
explicitly by user, or by the compiler.
Clang also gives false positive. EDG does not warn for such conversions (even
unconditional).
[Bug c/66613] error in evaluationg cexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66613 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-06-22 Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- The issue could also be in gmp/mpfr/mpc or in the C library. How did you compile (with what flags) anyway?
[Bug lto/65982] [5/6 Regression] ICE: in lto_output_varpool_node, at lto-cgraph.c:623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65982 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/66076] [5 Regression] ICE: in vec_safe_grow, at vec.h:618 with -funroll-loops -mno-prefer-avx128 -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66076 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66623
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
It's supposed to handle cases like (vect-outer-fir-big-array.c):
for (k = 0; k 4; k++) {
for (i = 0; i N; i++) {
diff = 0;
for (j = k; j M; j+=4) {
diff += in[j+i]*coeff[j];
}
out[i] += diff;
}
}
where indeed there is no association in the outer loop. So it indeed _is_
about double-reductions only. The current code setup isn't prepared to
detect the situation in question easily (and the patch is too strict).
[Bug libstdc++/66624] libstdc++ iostream uninitialized data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66624 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- It's initialized by the ios_base constructor in src/c++11/ios.cc
[Bug ipa/66424] [5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.9.3
[Bug tree-optimization/66413] [4.8/4.9/5 Regression] ICE at -Os and above with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66413 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #34 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/66186] [4.9/5/6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66186 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 Thomas Preud'homme thopre01 at gcc dot gnu.org changed: What|Removed |Added Assignee|thopre01 at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #11 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- Thinking about this, there cannot be a regression by removing an assert so having the bug not fully reproducible should not be an issue. I'll continue looking for the cause of such variance but the backport of r212178 can be made right now.
[Bug c/66622] New: -Wsign-conversion does not take advantage of data flow analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66622
Bug ID: 66622
Summary: -Wsign-conversion does not take advantage of data flow
analysis
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: john.marshall at sanger dot ac.uk
Target Milestone: ---
With GCC 5.1 built from gcc-5.1.0.tar.bz2 on OS X:
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc-5.1.0/configure --prefix=...
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 5.1.0 (GCC)
The following C program compiled with -Wsign-conversion produces a warning:
unsigned foo(int i) {
if (i 0) return 0;
else return i;
}
$ gcc-5.1 -c -Wsign-conversion valueconv.c
valueconv.c: In function ‘foo’:
valueconv.c:3:15: warning: conversion to ‘unsigned int’ from ‘int’ may change
the sign of the result [-Wsign-conversion]
else return i;
However if the compiler took advantage of the fact that i=0 within the else,
it would realise the warning was a false positive.
[Bug libstdc++/66624] New: libstdc++ iostream uninitialized data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66624
Bug ID: 66624
Summary: libstdc++ iostream uninitialized data
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
[forwarded from https://bugs.debian.org/789369]
richard@deodand:~/junk$ cat t.cc
#include iostream
int main() {
std::cout std::hex;
return 0;
}
richard@deodand:~/junk$ clang++-3.6 -fsanitize=undefined -O0
-fno-optimize-sibling-calls -fno-omit-frame-pointer -g -o t t.cc
richard@deodand:~/junk$ ./t
/usr/bin/../lib/gcc/i586-linux-gnu/5.1.1/../../../../include/c++/5.1.1/bits/ios_base.h:102:24:
runtime error: load of value 4294967221, which is not a valid value for
type 'std::_Ios_Fmtflags'
/usr/bin/../lib/gcc/i586-linux-gnu/5.1.1/../../../../include/c++/5.1.1/bits/ios_base.h:82:67:
runtime error: load of value 4294967221, which is not a valid value for
type 'std::_Ios_Fmtflags'
As far as I can see the problem here is that ios_base::_M_flags is never
initialized.
[Bug tree-optimization/66610] Aggregate assignment prevents store-motion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66610 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-22 CC||rguenth at gcc dot gnu.org Summary|Compound assignments|Aggregate assignment |prevent value-numbering |prevents store-motion |optimization with unions| Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- This isn't about value-numbering but about sinking the stores out of the loop (so it becomes empty). For the field case it is loop store motion that performs this conditional(!?) movement. For the non-field cases it determines a dependence: Memory reference 1: arr_5(D)-union_field.int_field Unanalyzed memory reference 0: MEM[(struct s *)arr_5(D) + 4B].union_field = arr_5(D)-union_field; Querying dependencies of ref 1 in loop 1: dependent because it doesn't handle aggregate assignments (simple_mem_ref_in_stmt fails). Confirmed.
[Bug tree-optimization/66598] With -O3 gcc incorrectly assumes aligned SSE instructions (e.g. movapd) can be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-22 Component|c |tree-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I believe I fixed this on trunk for PR66510. Confirmed with GCC 5 though. GCC 6 now generates .L2: movupd 16(%rax), %xmm0 addq$40, %rax addq$32, %rdx movupd -40(%rax), %xmm1 movaps %xmm0, -16(%rdx) movaps %xmm1, -32(%rdx) cmpq$P+1240, %rax jne .L2 movupd P+1256(%rip), %xmm0 xorl%eax, %eax movupd P+1240(%rip), %xmm1 movaps %xmm0, Q+1008(%rip) movaps %xmm1, Q+992(%rip) ret might be a bit hard to backport the changes though. Mine nevertheless.
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 --- Comment #16 from vehre at gcc dot gnu.org --- I am getting a regression in char_length_5.f90. Anyone else?
[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66623
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-06-22
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
So this boils down to the vectorizer disabling the associative math test if
it does outer-loop vectorization:
nested_cycle = (loop != LOOP_VINFO_LOOP (loop_vinfo));
reduc_stmt = vect_force_simple_reduction (loop_vinfo, phi, !nested_cycle,
double_reduc);
but I agree with your assessment that even with outer loop vectorization
it is not safe. A patch as simple as
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 224723)
+++ gcc/tree-vect-loop.c(working copy)
@@ -2610,14 +2610,14 @@ vect_is_simple_reduction_1 (loop_vec_inf
/* Check that it's ok to change the order of the computation.
Generally, when vectorizing a reduction we change the order of the
computation. This may change the behavior of the program in some
- cases, so we need to check that this is ok. One exception is when
- vectorizing an outer-loop: the inner-loop is executed sequentially,
- and therefore vectorizing reductions in the inner-loop during
- outer-loop vectorization is safe. */
+ cases, so we need to check that this is ok. Even when
+ vectorizing an outer-loop and the inner-loop is executed sequentially,
+ vectorizing reductions in the inner-loop during outer-loop vectorization
+ is _not_ safe as the final reduction in the outer loop associates
+ the inner loop results. */
/* CHECKME: check for !flag_finite_math_only too? */
- if (SCALAR_FLOAT_TYPE_P (type) !flag_associative_math
- check_reduction)
+ if (SCALAR_FLOAT_TYPE_P (type) !flag_associative_math)
{
/* Changing the order of operations changes the semantics. */
if (dump_enabled_p ())
@@ -2625,8 +2625,7 @@ vect_is_simple_reduction_1 (loop_vec_inf
reduction: unsafe fp math optimization: );
return NULL;
}
- else if (INTEGRAL_TYPE_P (type) TYPE_OVERFLOW_TRAPS (type)
- check_reduction)
+ else if (INTEGRAL_TYPE_P (type) TYPE_OVERFLOW_TRAPS (type))
{
/* Changing the order of operations changes the semantics. */
if (dump_enabled_p ())
@@ -2634,7 +2633,7 @@ vect_is_simple_reduction_1 (loop_vec_inf
reduction: unsafe int math optimization: );
return NULL;
}
- else if (SAT_FIXED_POINT_TYPE_P (type) check_reduction)
+ else if (SAT_FIXED_POINT_TYPE_P (type))
{
/* Changing the order of operations changes the semantics. */
if (dump_enabled_p ())
Might have some testsuite fallout though.
[Bug testsuite/66621] [4.9/5/6 Regression] Mistakenly unsupported tests in g++.dg/torture/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66621 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug lto/66394] [4.9/5/6 Regression] ICE in -flto -fmerge-all-constants -fno-use-linker-plugin targetting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66394 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug go/66368] [5 Regression] go tool crashes on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66412 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- James, can you please address this regression for 5.2.0?
[Bug go/66147] [5/6 Regression] go fails to cross build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66147 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 --- Comment #8 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon Jun 22 07:32:15 2015 New Revision: 224721 URL: https://gcc.gnu.org/viewcvs?rev=224721root=gccview=rev Log: Add -mflip-thumb for testing. PR target/52144n * config/arm/arm.c (add_attribute, arm_insert_attributes): New functions (TARGET_INSERT_ATTRIBUTES): Define. (thumb_flipper): New var. * config/arm/arm.opt (-mflip-thumb): New switch. PR target/52144 * gcc.target/arm/flip-thumb.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/flip-thumb.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.opt trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/65806] NetBSD's stdint.h expects __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65806 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Hmm, why doesn't GCC's own stdint.h solve this? It does: # if defined __cplusplus __cplusplus = 201103L # undef __STDC_LIMIT_MACROS # define __STDC_LIMIT_MACROS # undef __STDC_CONSTANT_MACROS # define __STDC_CONSTANT_MACROS # endif # include_next stdint.h
[Bug lto/45729] -flto conflicts with -mthumb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45729 chrbr at gcc dot gnu.org changed: What|Removed |Added CC||chrbr at gcc dot gnu.org Depends on||52144 --- Comment #4 from chrbr at gcc dot gnu.org --- need to add __attribute__((noinline)) for f(void) to make sure it is compiled in arm mode, otherwise it takes the mode of the caller Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 [Bug 52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
[Bug tree-optimization/66623] New: Unsafe FP math reduction used in strict math mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66623
Bug ID: 66623
Summary: Unsafe FP math reduction used in strict math mode
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.sherwood at arm dot com
Target Milestone: ---
Created attachment 35825
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35825action=edit
Unsafe FP math reduction example
I've found a bug with reductions for Neon whereby we change the ordering
of FP computation in strict math mode. The example looks like this:
float foo (float *__restrict__ i)
{
float l = 0;
for (int a = 0; a 4; a++)
for (int b = 0; b 4; b++)
l += i[b];
return l;
}
when compiled with the flags
-O2 -ftree-vectorize -fno-inline -march=armv8-a
we generate the asm:
moviv0.4s, 0
mov x1, x0
mov w0, 0
.L2:
ldr s1, [x1, w0, sxtw 2]
add w0, w0, 1
cmp w0, 4
dup v1.4s, v1.s[0]
faddv0.4s, v0.4s, v1.4s
bne .L2
faddp v0.4s, v0.4s, v0.4s
faddp v0.4s, v0.4s, v0.4s
which is (i[0] + i[1] + ...) + (i[0] + i[1] + ...) + ... We know that in
general
(a + b) + (a + b) is not guaranteed to be the same as ((a + b) + a) + b.
[Bug testsuite/66621] [4.9/5/6 Regression] Mistakenly unsupported tests in g++.dg/torture/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66621
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
I believe debug/localclass1.C debug/nullptr01.C tests also suffer from this
problem. Tried to grep for tests in other g++.dg/ subdirectories that have
their own *.exp and it seems if the tests there match target c..1 regexp then
their *.exp file seems to cycle through the -std=c++{98,11,14} or at least
-std=c++{98,11} options.
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target||blackfin Last reconfirmed||2015-6-22 CC||miyuki at gcc dot gnu.org --- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org --- Started with r208165.
[Bug libstdc++/66624] libstdc++ iostream uninitialized data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66624 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- the runtime warnings are not shown when building with g++-5.
[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from chrbr at gcc dot gnu.org --- attribute ((thumb,arm)) should be fine for 6.0.0 r224722
[Bug target/59884] Unexpected warning pragma GCC target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884 Bug 59884 depends on bug 52144, which changed state. Bug 52144 Summary: ARM should support arm/thumb function attribute to permit different instruction sets in the same source https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug lto/45729] -flto conflicts with -mthumb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45729 Bug 45729 depends on bug 52144, which changed state. Bug 52144 Summary: ARM should support arm/thumb function attribute to permit different instruction sets in the same source https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 Bug 65837 depends on bug 52144, which changed state. Bug 52144 Summary: ARM should support arm/thumb function attribute to permit different instruction sets in the same source https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/66090] Wrong loop code generation with -O2 on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org --- Seems like the conclusion is that this is just UB in the code. Closing thus.
[Bug c++/66542] [4.9/5/6 Regression] [C++11] Can create static variable of type that has deleted destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66542 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
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #27 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Alright, I have tracked it down now! It's definitely a bug in mpfr4 and *not* gcc. I rebuilt both mpfr4_3.1.2-1 and mpfr4_3.1.2-3 with the latest compiler we have in Debian which is gcc-4.9_4.9.2-21 (r224436). This is the result with the compile test of wmfire with mpfr4_3.1.2-1: glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0) wmfire.c: In function ‘do_help’: wmfire.c:770:62: error: ‘VERSION’ undeclared (first use in this function) fprintf(stderr, \nWmfire - Flaming Monitor Dock V %s\n\n, VERSION); ^ wmfire.c:770:62: note: each undeclared identifier is reported only once for each function it appears in glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ This is the result with mpfr4_3.1.2-3: glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0) wmfire.c: In function ‘draw_fire’: wmfire.c:559:6: internal compiler error: Segmentation fault psi = i * 3.14 / 20.0; ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions. Preprocessed source stored into /tmp/cc4xNN4u.out file, please attach this to your bugreport. glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src Again, *both* compiled fresh with the *same* compiler. Adrian
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740
--- Comment #15 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
The insn in question is
(insn 3598 3597 6907 395 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 307 [ ls$2 ])
(const_int 0 [0])))
(set (reg:SI 192 [ D.62648 ])
(reg:SI 307 [ ls$2 ]))
]) ../../gcc-4.9.2/gcc/haifa-sched.c:6368 204 {*movsi_compare0}
(expr_list:REG_DEAD (reg:SI 307 [ ls$2 ])
(expr_list:REG_UNUSED (reg:CC 100 cc)
(nil
The insn definition is
(define_insn *movsi_compare0
[(set (reg:CC CC_REGNUM)
(compare:CC (match_operand:SI 1 s_register_operand 0,r)
(const_int 0)))
(set (match_operand:SI 0 s_register_operand =r,r)
(match_dup 1))]
LRA choosing the first alternative where the 0 and 1 operand should be the same
and generates
(insn 3598 7755 7756 395 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 3686 [orig:192 D.62648 ] [192])
(const_int 0 [0])))
(set (reg:SI 3686 [orig:192 D.62648 ] [192])
(reg:SI 3686 [orig:192 D.62648 ] [192]))
]) ../../gcc-4.9.2/gcc/haifa-sched.c:6368 204 {*movsi_compare0}
(expr_list:REG_DEAD (reg:SI 307 [ ls$2 ])
(expr_list:REG_UNUSED (reg:CC 100 cc)
(nil
The generated ins is ok. The code in lra_lives.c::process_bb_lives is
if (dst_regno = lra_constraint_new_regno_start
src_regno = lra_constraint_new_regno_start)
lra_create_copy (dst_regno, src_regno, freq);
The code was written to process reload insns only but insn 3598 looks like
reload because it is a single_set insn (reg 100 is unused).
lra_create_copy has an assertion that dst_regno and src_regno are different
which fails.
The fix should be trivial. I'll commit it soon.
[Bug c/66322] Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66322 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Patch posted some time ago: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00790.html
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 --- Comment #16 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Mon Jun 22 18:17:28 2015 New Revision: 224752 URL: https://gcc.gnu.org/viewcvs?rev=224752root=gccview=rev Log: 2015-06-22 Vladimir Makarov vmaka...@redhat.com PR bootstrap/63740 * lra-lives.c (process_bb_lives): Check insn copying the same reload pseudo and don't create a copy for it. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/lra-lives.c
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #28 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Addendum: mpfr4_3.1.3-1 seems to be affected as well but I need to perform more testing. But it's definitely the jump from 3.1.2-1 to 3.1.2-3 that caused the bug!
[Bug c++/65879] [4.8/4.9/5/6 Regression] Bogus linkage errors for member class of anonymous class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65879 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.9.3
[Bug c/66531] New: Source file deleted when we use gcc compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66531 Bug ID: 66531 Summary: Source file deleted when we use gcc compile Product: gcc Version: unknown Status: RESOLVED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yongjin.ohn at lge dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- Status: RESOLVED CC: mpolacek at gcc dot gnu.org Resolution: DUPLICATE Hello guys. I'm newbie about the GCC compiler. Also, my english skill is poor, please understand it. Actually, When I compile using below command, my source are deleted. gcc -o mysource.c mysource I know this command is wrong. but I think that this is a problem. because user can make a mistake. Also user can't recover his source code everything. So, I think that If user input the like upper commend, we can change the parameter order or backup the source file. If you agree this situation, I'll try upload the patch. --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Probably can be closed as a dup of PR36312 (which added input file is the same as output file). *** This bug has been marked as a duplicate of bug 36312 ***
[Bug c++/66501] [4.9/5/6 Regression] Default move assignment does not move array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66501 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.9.3
[Bug c/66222] gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up pass at noopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Feedback not coming; closing.
