[Bug target/64785] [5 Regression][SH] and|or|xor #imm not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64785
--- Comment #7 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #6)
>
> I like your pre-RA pass even if it's a too big hammer for
> this specific problem. It should wait the next stage1, though.
It seems that this PR's issue is not a frequent use case (no hits in CSiBE at
all). So yes, stage1 is good.
> Also it would be better to look for another use cases of that
> pass as you suggested so as to justify the cost of scanning
> all insns.
Some use cases for the pre-RA pass:
- R0 pre-allocation
- reduction of number of pseudos and reg-reg copies
some passes leave pseudos and copies which can be removed
to make the RA task easier.
- 2 operand / commutative operands optimization
on SH the dest operand is always one of the source operands.
I've seen several times that the generic RA makes not-so-good
choices which results in more live regs and unnecessary reg-reg
copies. Very often output operands are put in different pseudos
than the input operands before RA and RA has to fix this somehow.
- the last time I played with the fipr insn (PR 55295) RA had trouble
allocating FV regs. For example:
void func (float a, float b, float c, float d)
would not allocate (a,b,c,d) to FV4, although the operands are already
in the appropriate FR regs. It resulted in many unnecessary reg-reg
copies. I haven't tried this with LRA though.
There are some more things which I'd do before RA:
- Forming SH2A movu.{b|w} insns (PR 64792)
- Various constant optimizations (PR 63390, PR 51708, PR 54682, PR 65069)
- 64 bit FP load/store fusion (PR 64305)
It would be possible to write one huge pre-RA RTL pass to do all of that.
However, I'd like to avoid accidents such as reload.c and rather keep things
separated as much as possible. I don't have evidence, but I don't think that
scanning all insns is too bad. It's being done multiple times during
compilation and there are other places which could be optimized. For example,
as far as I know, split4 and split5 passes are not needed on SH and could be
disabled. Or maybe the conditions in define_split such as "can_create_pseudo_p
()" should be evaluated *before* all insns are scanned/recog'ed.
[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #6 from Kai Tietz --- Well, the new ICE (with your patch applied) is a call off free on a damaged/wrong pointer for macro. For testing I disabled free for mc-pointer in question, but this leads to new issues about too big text-buffer containing random values. So I guess we have here an inconsistency about traditional whitespace-handling and none-traditional one.
[Bug middle-end/65346] New: [5 Regression] glibc make check failures since r214941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65346 Bug ID: 65346 Summary: [5 Regression] glibc make check failures since r214941 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Another borderline gcc/glibc issue. Since r214941 the following glibc checks fail: FAIL: debug/tst-chk3 FAIL: debug/tst-chk6 FAIL: debug/tst-lfschk3 FAIL: debug/tst-lfschk6 trippels@gcc2-power8 debug % gcc -w -std=gnu99 -fgnu89-inline -O2 tst-chk3.i && ./a.out /home/trippels/tmp/ccoLyHZS.o: In function `do_test': tst-chk3.c:(.text+0x2a84): warning: the `gets' function is dangerous and should not be used. Test checking routines at fortify level 2 Failure on line 353 Failure on line 357 Failure on line 361 Failure on line 366 Failure on line 370 Failure on line 587 Failure on line 591 Failure on line 595 Hello, World! Hello, World! World! Hello, World! Hello, World! World! trippels@gcc2-power8 debug % cat tst-chk3.c #define _FORTIFY_SOURCE 2 #include "tst-chk1.c" from tst-chk1.c: 345 # if __USE_FORTIFY_LEVEL >= 2 346 # define O 0 347 # else 348 # define O 1 349 # endif 350 351 CHK_FAIL_START 352 strcpy (a.buf1 + (O + 4), str1 + 5); 353 CHK_FAIL_END 354 355 CHK_FAIL_START 356 p = stpcpy (a.buf1 + (O + 8), str2); 357 CHK_FAIL_END 358 359 CHK_FAIL_START 360 strncpy (a.buf1 + (O + 6), "X", l0 + 4); 361 CHK_FAIL_END 362
[Bug middle-end/65346] [5 Regression] glibc make check failures since r214941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65346 --- Comment #1 from Markus Trippelsdorf --- Created attachment 34984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34984&action=edit unreduced testcase
[Bug fortran/60898] [4.8/4.9/5 Regression] model compile error with gfortran 4.7 and gcc 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #23 from Mikael Morin --- Author: mikael Date: Sun Mar 8 11:52:51 2015 New Revision: 221262 URL: https://gcc.gnu.org/viewcvs?rev=221262&root=gcc&view=rev Log: PR fortran/60898 fortran/ * resolve.c (resolve_symbol): Check that the symbol found by name lookup really is the current symbol being resolved. testsuite/ * gfortran.dg/entry_20.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/entry_20.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/65347] New: Final subroutine are not called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65347 Bug ID: 65347 Summary: Final subroutine are not called Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: eddyg_61-bugzilla at yahoo dot it In the following program the final subroutine are not called module testfin_mod implicit none type tfin integer :: t = -1 contains final :: del_tfin final :: del_tfinv end type contains function Ctfin(s) result(this) integer,intent(in) :: s type(tfin) :: this this % t = s end function subroutine del_tfin(this) type(tfin), intent(inout) :: this print *,"Finalized", this % t end subroutine subroutine del_tfinv(this) type(tfin), intent(inout) :: this(:) print *,"Finalized vector", this % t end subroutine subroutine printsomev(a) type(tfin) :: a(:) print *,'PRV:', a end subroutine subroutine printsomes(a) type(tfin) :: a print *,'PRS:', a%t end subroutine subroutine pluto type(tfin),save :: a(3) call printsomev([a(2), a(1), a(3)]) call printsomev([a(2), Ctfin(10), a(3)]) call printsomes(Ctfin(11)) end subroutine end module program test1 use testfin_mod implicit none call pluto end program The standard (as far as I know) requires the temporary variables corresponding to Ctfin(10) and Ctfin(11) to be finalized after the end of the subroutines printsomev and printsomev. But no finalization take places. The compiler ifort 13.0.1 correctly calls the final procedures.
[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341 --- Comment #12 from David Edelsohn --- The assembly file should start with .machine power4 which is the lowest level ISA supported on PPC64 Linux, GLIBC and mtfsf. If one invokes GCC with multiple -m options, it is complicated to calculate the correct assembler command line option, especially at the point that the assembler command is generated. With an assembler file, the compiler has no knowledge about the contents and should not guess the required ISA.
[Bug target/59828] Broken assembly on ppc* with two -mcpu= options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59828 --- Comment #1 from David Edelsohn --- Author: dje Date: Sun Mar 8 13:40:42 2015 New Revision: 221263 URL: https://gcc.gnu.org/viewcvs?rev=221263&root=gcc&view=rev Log: Add missing PR target/59828 to ChangeLog entry. Modified: trunk/gcc/ChangeLog
[Bug target/59828] Broken assembly on ppc* with two -mcpu= options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59828 David Edelsohn changed: What|Removed |Added Target||powerpc*-*-* Target Milestone|4.8.3 |5.0 --- Comment #2 from David Edelsohn --- Fixed.
[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341 --- Comment #13 from Markus Trippelsdorf --- It starts with: .machine "altivec" instead. But we are talking about powerpc64le-unknown-linux-gnu here. And -mpower8 is always right in this case, no?
[Bug libstdc++/65348] New: libstdc++ gdb pretty printer: Use relative imports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65348 Bug ID: 65348 Summary: libstdc++ gdb pretty printer: Use relative imports Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mustrumr97 at gmail dot com --- a/libstdc++v3/python/libstdcxx/v6/__init__.py +++ b/libstdc++v3/python/libstdcxx/v6/__init__.py @@ -16,7 +16,7 @@ import gdb # Load the pretty-printers. -from printers import register_libstdcxx_printers +from .printers import register_libstdcxx_printers register_libstdcxx_printers(gdb.current_objfile()) # Load the xmethods if GDB supports them. @@ -28,5 +28,5 @@ return False if gdb_has_xmethods(): -from xmethods import register_libstdcxx_xmethods +from .xmethods import register_libstdcxx_xmethods register_libstdcxx_xmethods(gdb.current_objfile())
[Bug libstdc++/65246] [5 Regression] libstdc++ pretty printers don't work anymore with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65246 Jonathan Wakely changed: What|Removed |Added CC||mustrumr97 at gmail dot com --- Comment #3 from Jonathan Wakely --- *** Bug 65348 has been marked as a duplicate of this bug. ***
[Bug libstdc++/65348] libstdc++ gdb pretty printer: Use relative imports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65348 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Already fixed. *** This bug has been marked as a duplicate of bug 65246 ***
[Bug go/65349] New: [5 Regression] go tool crashes, can't compile go code on 32bit linux systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65349 Bug ID: 65349 Summary: [5 Regression] go tool crashes, can't compile go code on 32bit linux systems Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at gcc dot gnu.org CC: cmang at google dot com The go command didn't ship with earlier GCC versions, so you may argue that it is not a regression, however a go command backported from 1.2.2 was able to build code with 4.9 on at least arm-linux-gnueabihf, powerpc-linux-gnu and i686-linux-gnu. Double-checked that the backported go command built with 5.0 shows the same failure. This seems to work on architectures like aarch64-linux-gnu, powerpc64le-linux-gnu and x86_64-linux-gnu. On these architectures I see for "go -v on powerpc-linux-gnu (not on armhf and i386) building go-md2man https://launchpad.net/ubuntu/+source/go-md2man/1-2ubuntu2 fatal error: freeing too small block goroutine 16 [running]: runtime_dopanic ../../../src/libgo/runtime/panic.c:131 runtime_throw ../../../src/libgo/runtime/panic.c:193 __go_free ../../../src/libgo/runtime/malloc.goc:354 __go_map_rehash ../../../src/libgo/runtime/go-map-index.c:66 __go_map_index ../../../src/libgo/runtime/go-map-index.c:120 main.$nested26 ../../src/gotools/../libgo/go/cmd/go/main.go:565 filepath.walk ../../../src/libgo/go/path/filepath/path.go:347 filepath.walk ../../../src/libgo/go/path/filepath/path.go:372 path_filepath.Walk ../../../src/libgo/go/path/filepath/path.go:394 main.matchPackages ../../src/gotools/../libgo/go/cmd/go/main.go:544 main.allPackages ../../src/gotools/../libgo/go/cmd/go/main.go:481 main.importPaths ../../src/gotools/../libgo/go/cmd/go/main.go:329 main.packagesAndErrors ../../src/gotools/../libgo/go/cmd/go/pkg.go:902 main.packages ../../src/gotools/../libgo/go/cmd/go/pkg.go:883 main.runList ../../src/gotools/../libgo/go/cmd/go/list.go:175 main.main ../../src/gotools/../libgo/go/cmd/go/main.go:163 runtime_main ../../../src/libgo/runtime/proc.c:550 panic during panic goroutine 16 [running]: runtime_dopanic ../../../src/libgo/runtime/panic.c:131 runtime_startpanic ../../../src/libgo/runtime/panic.c:100 runtime_throw ../../../src/libgo/runtime/panic.c:191 runtime_mallocgc ../../../src/libgo/runtime/malloc.goc:116 __go_alloc ../../../src/libgo/runtime/malloc.goc:321 callback ../../../src/libgo/runtime/go-caller.c:50 dwarf_lookup_pc ../../../src/libbacktrace/dwarf.c:2838 dwarf_fileline ../../../src/libbacktrace/dwarf.c:2877 backtrace_pcinfo ../../../src/libbacktrace/fileline.c:176 __go_file_line ../../../src/libgo/runtime/go-caller.c:137 runtime_printcreatedby ../../../src/libgo/runtime/proc.c:613 runtime_dopanic ../../../src/libgo/runtime/panic.c:132 runtime_throw ../../../src/libgo/runtime/panic.c:193 __go_free ../../../src/libgo/runtime/malloc.goc:354 __go_map_rehash ../../../src/libgo/runtime/go-map-index.c:66 __go_map_index ../../../src/libgo/runtime/go-map-index.c:120 main.$nested26 ../../src/gotools/../libgo/go/cmd/go/main.go:565 filepath.walk ../../../src/libgo/go/path/filepath/path.go:347 filepath.walk ../../../src/libgo/go/path/filepath/path.go:372 path_filepath.Walk ../../../src/libgo/go/path/filepath/path.go:394 main.matchPackages ../../src/gotools/../libgo/go/cmd/go/main.go:544 main.allPackages ../../src/gotools/../libgo/go/cmd/go/main.go:481 main.importPaths ../../src/gotools/../libgo/go/cmd/go/main.go:329 main.packagesAndErrors ../../src/gotools/../libgo/go/cmd/go/pkg.go:902 main.packages ../../src/gotools/../libgo/go/cmd/go/pkg.go:883 main.runList ../../src/gotools/../libgo/go/cmd/go/list.go:175 main.main ../../src/gotools/../libgo/go/cmd/go/main.go:163 runtime_main ../../../src/libgo/runtime/proc.c:550 stack trace unavailable on powerpc building nuntium: fatal error: freeing too small block goroutine 16 [running]: runtime_dopanic ../../../src/libgo/runtime/panic.c:131 runtime_throw ../../../src/libgo/runtime/panic.c:193 __go_free ../../../src/libgo/runtime/malloc.goc:354 __go_map_rehash ../../../src/libgo/runtime/go-map-index.c:66 __go_map_index ../../../src/libgo/runtime/go-map-index.c:120 main.$nested26 ../../src/gotools/../libgo/go/cmd/go/main.go:565 filepath.walk ../../../src/libgo/go/path/filepath/path.go:347 filepath.walk ../../../src/libgo/go/path/filepath/path.go:372 path_filepath.Walk ../../../src/libgo/go/path/filepath/path.go:394 main.matchPackages
[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341 --- Comment #14 from Martin Sebor --- I'm confused: I thought gcc defining the _ARCH_PWR6 macro in response to -mcpu=power6 or some such implied that the target was power6. Shouldn't gcc then also invoke the assembler with the -mpower6 option to make sure it's also in power6 mode? Incidentally, the background on the glibc code is here: http://sourceware.org/bugzilla/show_bug.cgi?id=10118
[Bug c/65350] New: [C++14] operator new[] should not be called if # of initializer elements exceeds # of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65350
Bug ID: 65350
Summary: [C++14] operator new[] should not be called if # of
initializer elements exceeds # of elements
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Please see the sample code below.
== sample code ==
#include
#include
void* operator new[](std::size_t size)
{
std::cout << "my operator new[](" << size << ")" << std::endl;
return ::operator new(size);
}
int main()
{
int i = 1;
try {
int* p = new int[i]{ 1, 2 };
delete[] p;
} catch (const std::bad_array_new_length& e) {
std::cout << e.what() << std::endl;
}
}
== sample code ==
== output ==
my operator new[](4)
std::bad_array_new_length
== output ==
cf. http://melpon.org/wandbox/permlink/tQFp5fpPXT5mZu34
The C++14 standard 5.3.4[expr.new]/p.7 says,
The expression in a noptr-new-declarator is erroneous if:
...
--- the new-initializer is a braced-init-list and the number of array
elements
for which initializers are provided (including the terminating '\0' in
a
string literal (2.13.5)) exceeds the number of elements to initialize.
... Otherwise, a new-expression with an erroneous expression **does not call
an allocation function** and terminates by throwing an exception of a type
that would match a handler (15.3) of type std::bad_array_new_length
(18.6.2.2).
...
(emphasis mine)
So, I think that the sample code above should output only
== output ==
std::bad_array_new_length
== output ==
[Bug c/65350] [C++14] operator new[] should not be called if # of initializer elements exceeds # of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65350 --- Comment #1 from Mitsuru Kariya --- Created attachment 34985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34985&action=edit g++ -v
[Bug target/65351] New: [5 Regression] ld: absolute addressing (perhaps -mdynamic-no-pic) used in _byte_common_op_match_null_string_p from ../libiberty/pic/libiberty.a(regex.o) not allowed ... on powe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351 Bug ID: 65351 Summary: [5 Regression] ld: absolute addressing (perhaps -mdynamic-no-pic) used in _byte_common_op_match_null_string_p from ../libiberty/pic/libiberty.a(regex.o) not allowed ... on powerpc-apple-darwin9 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 Boostrapping gcc on powerpc-apple-darwin9 fails with libtool: link: /opt/gcc/rel_build/./gcc/xg++ -B/opt/gcc/rel_build/./gcc/ -nostdinc++ -nostdinc++ -I/opt/gcc/rel_build/powerpc-apple-darwin9.8.0/libstdc++-v3/include/powerpc-apple-darwin9.8.0 -I/opt/gcc/rel_build/powerpc-apple-darwin9.8.0/libstdc++-v3/include -I/opt/gcc/rel_work/libstdc++-v3/libsupc++ -I/opt/gcc/rel_work/libstdc++-v3/include/backward -I/opt/gcc/rel_work/libstdc++-v3/testsuite/util -L/opt/gcc/rel_build/powerpc-apple-darwin9.8.0/libstdc++-v3/src -L/opt/gcc/rel_build/powerpc-apple-darwin9.8.0/libstdc++-v3/src/.libs -L/opt/gcc/rel_build/powerpc-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs -B/opt/gcc/rel_build/powerpc-apple-darwin9.8.0/libstdc++-v3/src/.libs -B/opt/gcc/rel_build/powerpc-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs -B/opt/gcc/gcc5.0r/powerpc-apple-darwin9.8.0/bin/ -B/opt/gcc/gcc5.0r/powerpc-apple-darwin9.8.0/lib/ -isystem /opt/gcc/gcc5.0r/powerpc-apple-darwin9.8.0/include -isystem /opt/gcc/gcc5.0r/powerpc-apple-darwin9.8.0/sys-include-Wl,-undefined -Wl,dynamic_lookup -o .libs/libcc1.0.so -bundle .libs/findcomp.o .libs/libcc1.o .libs/names.o .libs/callbacks.o .libs/connection.o .libs/marshall.o -L/opt/gcc/rel_build/powerpc-apple-darwin9.8.0/libstdc++-v3/src -L/opt/gcc/rel_build/powerpc-apple-darwin9.8.0/libstdc++-v3/src/.libs -L/opt/gcc/rel_build/powerpc-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs -static-libstdc++ -static-libgcc ../libiberty/pic/libiberty.a -Wl,-exported_symbols_list,.libs/libcc1-symbols.expsym ld: absolute addressing (perhaps -mdynamic-no-pic) used in _byte_common_op_match_null_string_p from ../libiberty/pic/libiberty.a(regex.o) not allowed in slidable image. Use '-read_only_relocs suppress' to enable text relocs collect2: error: ld returned 1 exit status
[Bug target/65351] [5 Regression] ld: absolute addressing (perhaps -mdynamic-no-pic) used in _byte_common_op_match_null_string_p from ../libiberty/pic/libiberty.a(regex.o) not allowed ... on powerpc-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351 Iain Sandoe changed: What|Removed |Added Target|powerpc-apple-darwin9 |m32 *-apple-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-08 CC||iains at gcc dot gnu.org Host|powerpc-apple-darwin9 |m32 *-apple-darwin* Ever confirmed|0 |1 Build|powerpc-apple-darwin9 |m32 *-apple-darwin* --- Comment #1 from Iain Sandoe --- this affects all m32 Darwin, and has been "broken" since the pic version of libiberty was added - but has only become noticed now this (pic libiberty) is linked into libcc1.
[Bug target/65351] [5 Regression] ld: absolute addressing (perhaps -mdynamic-no-pic) used in _byte_common_op_match_null_string_p from ../libiberty/pic/libiberty.a(regex.o) not allowed ... on powerpc-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351 --- Comment #2 from Dominique d'Humieres --- Patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00017.html.
[Bug libstdc++/65352] New: array::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352
Bug ID: 65352
Summary: array::begin()/end() etc. forms a null reference
and breaks on clang+ubsan
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Repro:
#include
int main(){
std::array foo;
foo.begin(); // or end(), etc.
}
Output (http://coliru.stacked-crooked.com/a/e1cbe7e73bcee449):
> clang++ --version
clang version 3.5.0 (tags/RELEASE_350/final 217394)
Target: x86_64-unknown-linux-gnu
Thread model: posix
> clang++ -std=c++11 -O0 -Wall -pedantic -pthread main.cpp -fsanitize=undefined
> ./a.out
==15356==WARNING: readlink("/proc/self/exe") failed with errno 2, some stack
frames may not be symbolized
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/array:63:15:
runtime error: reference binding to null pointer of type 'int'
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/array:222:33:
runtime error: reference binding to null pointer of type 'int'
begin()/end() are supposed to be well-defined even if N = 0. The implementation
in defers to data(), which in turn returns
std::__addressof(_AT_Type::_S_ref(_M_elems, 0)). The problem is that for the N
= 0 case, __array_traits::_S_ref forms and returns a null reference:
static constexpr _Tp&
_S_ref(const _Type&, std::size_t) noexcept
{ return *static_cast<_Tp*>(nullptr); }
An obvious possible fix is to provide a pointer-returning helper in addition to
or instead of _S_ref.
[Bug go/65353] New: [5 Regression] unknown ptrSize for $GOARCH "arm64" on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65353 Bug ID: 65353 Summary: [5 Regression] unknown ptrSize for $GOARCH "arm64" on aarch64-linux-gnu Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at gcc dot gnu.org CC: cmang at google dot com $ go tool cgo -godefs types.go unknown ptrSize for $GOARCH "arm64" with a separately built go tool (1.2), built using gccgo-4.9, this works as expected. filing this as a regression for now. $ cat types.go // +build ignore package pty import "C" type ( _C_int C.int _C_uint C.uint ) $ go tool cgo -godefs types.go // Created by cgo -godefs - DO NOT EDIT // cgo -godefs types.go package pty type ( _C_int int32 _C_uint uint32 )
[Bug libstdc++/65352] array::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-03-08
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Or just (untested):
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -58,9 +58,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{
struct _Type { };
- static constexpr _Tp&
+ static _Tp&
_S_ref(const _Type&, std::size_t) noexcept
- { return *static_cast<_Tp*>(nullptr); }
+ { return reinterpret_cast<_Tp&>(const_cast<_Type&>(t)); }
};
/**
It's undefined to refer to the element in the zero-size case, so casting to an
incompatible reference type shouldn't matter as noone will ever access anything
through that reference.
[Bug libstdc++/65352] array::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352
--- Comment #2 from Jonathan Wakely ---
Oops, that should be:
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -58,9 +58,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{
struct _Type { };
- static constexpr _Tp&
- _S_ref(const _Type&, std::size_t) noexcept
- { return *static_cast<_Tp*>(nullptr); }
+ static _Tp&
+ _S_ref(const _Type& __t, std::size_t) noexcept
+ { return reinterpret_cast<_Tp&>(const_cast<_Type&>(__t)); }
};
/**
I think it's OK to make it non-constexpr, because _S_ref only needs to be
constexpr for functions which access an element, which are also invalid for the
zero-size array.
[Bug go/65353] [5 Regression] unknown ptrSize for $GOARCH "arm64" on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65353 --- Comment #1 from Matthias Klose --- patch by Michael Hudson posted at https://launchpad.net/bugs/1361946 --- a/libgo/go/cmd/cgo/main.go +++ b/libgo/go/cmd/cgo/main.go @@ -133,6 +133,7 @@ "386": 4, "amd64": 8, "arm": 4, + "arm64": 8, "ppc64": 8, "ppc64le": 8, "s390x": 8, @@ -142,6 +143,7 @@ "386": 4, "amd64": 8, "arm": 4, + "arm64": 8, "ppc64": 8, "ppc64le": 8, "s390x": 8,
[Bug go/65353] [5 Regression] unknown ptrSize for $GOARCH "arm64" on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65353 --- Comment #2 from Andrew Pinski --- (In reply to Matthias Klose from comment #1) > patch by Michael Hudson posted at https://launchpad.net/bugs/1361946 > > --- a/libgo/go/cmd/cgo/main.go > +++ b/libgo/go/cmd/cgo/main.go > @@ -133,6 +133,7 @@ > "386": 4, > "amd64": 8, > "arm": 4, > + "arm64": 8, > "ppc64": 8, > "ppc64le": 8, > "s390x": 8, > @@ -142,6 +143,7 @@ > "386": 4, > "amd64": 8, > "arm": 4, > + "arm64": 8, > "ppc64": 8, > "ppc64le": 8, > "s390x": 8, Except hat is broken for ilp32.
[Bug ada/62205] GNAT does not accept class types for Default_Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62205 Victor Porton changed: What|Removed |Added Version|4.9.1 |4.9.2 --- Comment #2 from Victor Porton --- It does not work also with GNAT 4.9.2.
[Bug ada/62235] segmentation fault on Ada 2012 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62235 --- Comment #4 from Victor Porton --- Also does not work with GNAT 4.9.2.
[Bug ada/62236] : error: aggregate value used where an integer was expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62236 --- Comment #3 from Victor Porton --- It does not work also with GANT 4.9.2.
[Bug c++/65354] New: Converting lambda to pointer results in double destruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65354
Bug ID: 65354
Summary: Converting lambda to pointer results in double
destruction
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: charlie at charliedyson dot net
In the following, the unique_ptr is deleted twice if the lambda is converted to
a function pointer (#if 1) but runs without error if left as a lambda.
Compiled with g++-4.8 test.cpp -o test -std=c++1y on Linux Mint 17 x64.
I get the following output in the function pointer case:
Bye
Bye
*** Error in `./test': double free or corruption (fasttop): 0x01e5c010
***
Aborted
Here's the code:
#include
#include
struct X
{
~X () { std::cout << "Bye" << std::endl; }
};
struct Y
{
explicit Y (std::unique_ptr x)
: m_x (std::move (x))
{ }
std::unique_ptr m_x;
};
int main ()
{
using F = Y (*) (std::unique_ptr);
auto p = std::unique_ptr {new X};
#if 1
F f =
#else
auto f =
#endif
[] (std::unique_ptr x)
{
return Y (std::move (x));
};
f (std::move (p));
}
[Bug preprocessor/51776] fixincludes hacks around a C++ deficiency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51776 Bruce Korb changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Bruce Korb --- This hack is no longer in inclhack.def.
[Bug go/65353] [5 Regression] unknown ptrSize for $GOARCH "arm64" on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65353 Michael Hudson-Doyle changed: What|Removed |Added CC||michael.hudson at canonical dot co ||m --- Comment #3 from Michael Hudson-Doyle --- ilp32 will need to be a new GOARCH; "arm64p32" would fit with the existing GOARCH value of amd64p32 for intel.
[Bug middle-end/61207] [4.9 Regression] Win64 gcc 4.9.0: ICE in in expand_expr_addr_expr_1 at -Os compiling some C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207 Yvan Roux changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Yvan Roux --- This is a duplicate of PR64896 and was fixed on trunk at r220489. I've backported and tested on Linaro 4.9 branch and will prepare the backport on FSF 4.9. Yvan *** This bug has been marked as a duplicate of bug 64896 ***
[Bug ipa/64896] [5 Regression] ICE in get_address_mode, at rtlanal.c:5442
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64896 Yvan Roux changed: What|Removed |Added CC||mingw.android at gmail dot com --- Comment #10 from Yvan Roux --- *** Bug 61207 has been marked as a duplicate of this bug. ***
[Bug c++/65354] Converting lambda to pointer results in double destruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65354 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- The problem also occurs in all release versions of 4.9.x and in the current HEAD 5.0.0 20150306 (experimental).
[Bug target/62251] FAIL: gfortran.dg/quad_2.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62251 --- Comment #8 from John David Anglin --- Author: danglin Date: Sun Mar 8 22:58:52 2015 New Revision: 221267 URL: https://gcc.gnu.org/viewcvs?rev=221267&root=gcc&view=rev Log: PR target/62251 * gfortran.dg/quad_2.f90: xfail hppa*-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/quad_2.f90
[Bug target/62251] FAIL: gfortran.dg/quad_2.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62251 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from John David Anglin --- Resolved.
[Bug ipa/65334] [5 Regression] r221099 caused: FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution, -O2 -ftree-vectorize -msse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65334 --- Comment #4 from Jan Hubicka --- Author: hubicka Date: Sun Mar 8 23:12:25 2015 New Revision: 221268 URL: https://gcc.gnu.org/viewcvs?rev=221268&root=gcc&view=rev Log: PR ipa/65334 * cgraph.h (symtab_node): Add definition_alignment, can_increase_alignment_p and increase_alignment. * symtab.c (symtab_node::can_increase_alignment_p, increase_alignment_1, symtab_node::increase_alignment, symtab_node::definition_alignment): New. * tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Use can_increase_alignment_p. * tree-vectorizer.c (increase_alignment): Use increase_alignment. * tree-vect-stmts.c (ensure_base_align): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/symtab.c trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.c
[Bug ipa/65334] [5 Regression] r221099 caused: FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution, -O2 -ftree-vectorize -msse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65334 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan Hubicka --- Fixed.
[Bug tree-optimization/65355] New: [4.8/4.9 Regression] vectorizer increase alignment of symbols already placed in anchors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65355 Bug ID: 65355 Summary: [4.8/4.9 Regression] vectorizer increase alignment of symbols already placed in anchors Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Increasing alignment of symbol does not work once RTL containing anchor was produced. Index: symtab.c === --- symtab.c (revision 221268) +++ symtab.c (working copy) @@ -1924,6 +1924,13 @@ symtab_node::can_increase_alignment_p (v if (TREE_ASM_WRITTEN (target->decl)) return false; + /* If target is already placed in an anchor, we can not touch its + alignment. */ + if (DECL_RTL_SET_P (target->decl) + && MEM_P (DECL_RTL (target->decl)) + && SYMBOL_REF_HAS_BLOCK_INFO_P (XEXP (DECL_RTL (target->decl), 0))) +return false; + /* Constant pool entries may be shared. */ if (DECL_IN_CONSTANT_POOL (target->decl)) return false; sadly introduce quite few testsuite regressions for ppc-linux (checking that alignmnet was increased). This is because notice_global_symbol produces RTL early and thus blocks this. I suppose notice_global_symbol needs to be redone to work on tree only. For next stage1 we also probably want to drop the increase_alignmnets IPA pass and run all late tree passes prior RTL generation.
[Bug target/62247] [5 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62247 --- Comment #10 from John David Anglin --- Author: danglin Date: Sun Mar 8 23:46:34 2015 New Revision: 221271 URL: https://gcc.gnu.org/viewcvs?rev=221271&root=gcc&view=rev Log: PR target/62247 * g++.dg/abi/anon3.C: Skip failing scan-assembler checks on hppa*-*-hpux*. * g++.dg/abi/rtti3.C: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/anon3.C trunk/gcc/testsuite/g++.dg/abi/rtti3.C
[Bug lto/65316] [5 Regression] LTO: Uninitialized memory / ICE with -g -fno-lto-odr-type-merging: in types_same_for_odr, at ipa-devirt.c:465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316 --- Comment #12 from Jan Hubicka --- Author: hubicka Date: Mon Mar 9 00:29:14 2015 New Revision: 221275 URL: https://gcc.gnu.org/viewcvs?rev=221275&root=gcc&view=rev Log: PR lto/65316 * ipa-utils.h (types_odr_comparable): Add strict argument. * ipa-devirt.c: Fix whitespace; (odr_hasher): Remove. (odr_name_hasher, odr_vtable_hasher): New hashers. (can_be_name_hashed_p): New predicate. (hash_type_name): remove. (hash_odr_name): New. (odr_name_hasher::hash): new. (can_be_vtable_hashed_p): New. (hash_odr_vtable): New. (odr_vtable_hasher::hash): New. (types_same_for_odr): Add strict parameter. (types_odr_comparable): Likewise. (odr_name_hasher::equal): New. (odr_vtable_hasher::equal): New. (odr_name_hasher::remove): New. (odr_hash_type): Change to hash_table. (odr_vtable_hash_type): New. (odr_vtable_hash): New. (odr_subtypes_equivalent_p): Do strict comparsion. (add_type_duplicate): Merge type names; cleanup; avoid type duplicates. (register_odr_type): Initialize vtable hash. (build_type_inheritance_graph): Likewise (get_odr_type): Reorg to use two hashes. (dump_possible_polymorphic_call_targets): Move sanity check after debug output. (ipa_devirt): Dump type_inheritance_graph. (types_same_for_odr): Add strict mode. * g++.dg/lto/pr65316_0.C: New testcase. * g++.dg/lto/pr65316_1.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/pr65316_0.C trunk/gcc/testsuite/g++.dg/lto/pr65316_1.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c trunk/gcc/ipa-utils.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h
[Bug tree-optimization/63960] [meta-bug] Port tail-merge fixes to 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63960 --- Comment #1 from vries at gcc dot gnu.org --- - Fix PR64091 https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03397.html
[Bug tree-optimization/65356] New: [meta-bug] Port tail-merge fixes to 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65356 Bug ID: 65356 Summary: [meta-bug] Port tail-merge fixes to 4.9 Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org - Fix PR64091 https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03397.html
[Bug tree-optimization/63743] Thumb1: big regression for float operators by r216728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743 --- Comment #9 from Thomas Preud'homme --- Author: thopre01 Date: Mon Mar 9 01:31:42 2015 New Revision: 221276 URL: https://gcc.gnu.org/viewcvs?rev=221276&root=gcc&view=rev Log: 2015-03-09 Thomas Preud'homme gcc/ PR tree-optimization/63743 * cfgexpand.c (reorder_operands): Also reorder if only second operand had its definition forwarded by TER. gcc/testsuite/ PR tree-optimization/63743 * gcc.dg/pr63743.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr63743.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/28628] Not forcing alignment of arrays in structs with -fsection-anchors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28628 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #2 from Jan Hubicka --- This is something we can solve next stage1 by breaking up the pass queue and doing all RTL generation after tree optimization.
[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341 --- Comment #15 from David Edelsohn --- GCC is not magic black box for invoking every other part of the toolchain with the correct options. If the assembly code uses POWER6 (ISA 2.05) instructions, it should set the ISA level appropriately. The assembly code in question is using the pre-processor of GCC, which defines machine macros. The logic for setting command line options is too complicated and error-prone to recreate separate from the ISA target flags. GCC emits the correct ISA level when generating an assembly file, but utilizing GCC for the pre-processor capabilities does not emit any new assembly instructions for GCC to set directives at the start of the file. The change in GCC behavior is because it is too cumbersome for GCC to get this right in some corner cases.
[Bug tree-optimization/64091] [5 Regression] ICE in update_debug_stmt, at tree-ssa-tail-merge.c:1620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64091 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #6 from vries at gcc dot gnu.org --- Fix committed here: PR64088 comment 5
[Bug lto/65316] [5 Regression] LTO: Uninitialized memory / ICE with -g -fno-lto-odr-type-merging: in types_same_for_odr, at ipa-devirt.c:465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jan Hubicka --- Fixed.
[Bug ipa/64253] IPA inline analysis processes a code transform operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64253 Jan Hubicka changed: What|Removed |Added Summary|[5 Regression] IPA inline |IPA inline analysis |analysis processes a code |processes a code transform |transform operation |operation --- Comment #4 from Jan Hubicka --- Not a regression.
[Bug lto/65243] [5 Regression] lto1 ICE (segfault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65243 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Jan Hubicka --- I also occasionally see this dwarf2out ICE when buliding firefox with debug info.
[Bug c/65357] New: aggressive loop optimization not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65357
Bug ID: 65357
Summary: aggressive loop optimization not correct
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: weiming at ms1 dot url.com.tw
source:
#include
#include
voidaddlist(int n, int *list)
{
inti;
for (i=0; i
[Bug c/65357] aggressive loop optimization not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65357 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- Both, because you invoke undefined behavior. https://gcc.gnu.org/bugs/#nonbugs_c
[Bug c/65357] aggressive loop optimization not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65357 --- Comment #2 from Andrew Pinski --- That is addlist goes one past the end of the array tlist.
[Bug c/65357] aggressive loop optimization not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65357 --- Comment #3 from Weiming Shih --- I see. Thank you.
[Bug target/65358] New: parameter passing bug with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
Bug ID: 65358
Summary: parameter passing bug with tail call optimization on
arm
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hong.gyu.kim at lge dot com
struct pack
{
int fine;
int victim;
int killer;
};
int bar(int a, int b, struct pack p);
int foo(int arg1, int arg2, int arg3, struct pack p)
{
return bar(arg2, arg3, p);
}
When I cross compile the above code with "-O2" option for arm, one variable in
"struct pack" is lost.
The "vitcim" value is overwritten by "killer" value while passing arguments in
"struct pack" from "foo" to "bar".
Initially the arguments are passed this way right after foo invoked.
r0: arg1
r1: arg2
r2: arg3
r3: p.fine
MEM[sp]: p.victim
MEM[sp-4]: p.killer
Parameter setting for bar must be this way right before bar invoked.
r0: arg2
r1: arg3
r2: p.fine
r3: p.victim
MEM[sp]: p.killer
But parameter passing is structured as follows:
(p.victim is overwritten by p.killer)
r0: arg2
r1: arg3
r2: p.fine
r3: p.killer (*)
MEM[sp]: p.killer
The assembly code of "foo" generated is as follows:
foo:
@ args = 16, pretend = 8, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
sub sp, sp, #8
mov r0, r1
str lr, [sp, #-4]!
add ip, sp, #8
(1) ldr lr, [sp, #16]
mov r1, r2
str r3, [sp, #8]
(2) str lr, [sp, #12]
ldr lr, [sp], #4
ldmia ip, {r2, r3}
add sp, sp, #8
b bar
The point is that (1) loads "p.killer", then (2) overwrites "p.victim" value.
Until this point, "p.victim" is never copied anyway, which makes the value
disappear.
This bug is not shown when compiled with "-fno-optimize-sibling-calls".
This bug is shown in gcc-4.9.2 and also in gcc-5.0.0.
I also compiled the same program for x86 and x86_64 and those do not generate
this kind of buggy code. This bug is only shown in arm code.
I found that this bug is detected right after the RTL expand phase. (with
-fdump-rtl-expand)
[Bug target/65358] parameter passing bug with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 Honggyu Kim changed: What|Removed |Added Keywords||wrong-code Target||arm-unknown-linux-gnueabi Host||x86_64-build_unknown-linux- ||gnu Build||x86_64-build_unknown-linux- ||gnu --- Comment #1 from Honggyu Kim --- "gcc -v" is here: $ arm-unknown-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-unknown-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/x-tools/arm-unknown-linux-gnueabi/libexec/gcc/arm-unknown-linux-gnueabi/5.0.0/lto-wrapper Target: arm-unknown-linux-gnueabi Configured with: /home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/src/crosstool-ng/.build/src/gcc-custom/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=arm-unknown-linux-gnueabi --prefix=/home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/x-tools/arm-unknown-linux-gnueabi --with-sysroot=/home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot --enable-languages=c,c++,fortran --with-cpu=cortex-a9 --with-fpu=neon --with-float=softfp --with-pkgversion='crosstool-NG 1.20.0 - 5.0.0-x86_64' --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --enable-libquadmath --enable-libquadmath-support --enable-libsanitizer --with-gmp=/home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/src/crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-mpfr=/home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/src/crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-mpc=/home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/src/crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-isl=/home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/src/crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-cloog=/home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/src/crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-libelf=/home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/src/crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix --enable-target-optspace --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-gold --disable-nls --disable-multilib --with-local-prefix=/home/hong.gyu.kim/work.hard/kasan/toolchain/kasan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot --enable-c99 --enable-long-long Thread model: posix gcc version 5.0.0 20150306 (experimental) (crosstool-NG 1.20.0 - 5.0.0-x86_64)
[Bug c/65357] aggressive loop optimization not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65357 --- Comment #4 from Weiming Shih --- How can I get a warning for such an undefined behavior?
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 --- Comment #2 from Honggyu Kim --- Sorry, I miss typed the initial argument status for "foo" I will modified "MEM[sp-4]: p.killer" to "MEM[sp+4]: p.killer" as follows: r0: arg1 r1: arg2 r2: arg3 r3: p.fine MEM[sp]: p.victim MEM[sp+4]: p.killer
[Bug libstdc++/64303] The regex_token_iterator's copy constructor creates an incorrect iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64303 Tim Shen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tim Shen --- Resolved.
[Bug libstdc++/64239] regex_iterator::operator= should copy match_results::position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64239 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Tim Shen --- Resolved.
[Bug libstdc++/64302] The match_results::cbegin()/cend() return incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64302 Tim Shen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tim Shen --- Resolved.
[Bug libstdc++/64140] match_results.prefix() returns an incorrect result if regex_iterator holds a zero-length match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64140 Tim Shen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tim Shen --- Resolved.
[Bug libstdc++/63776] [C++11] Regex collate matching not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63776 --- Comment #9 from Tim Shen --- Ping.
[Bug c++/35167] problem with function address constant non-type template parameter in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35167 Václav Zeman changed: What|Removed |Added Target|i386-portbld-freebsd6.3 | Host|i386-portbld-freebsd6.3 | Version|4.3.0 |4.9.1 Known to fail||4.9.1 Build|i386-portbld-freebsd6.3 | --- Comment #10 from Václav Zeman --- This still fails in 4.9.1.
[Bug libstdc++/63990] regex_search increments a past-the-end iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63990 Tim Shen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tim Shen --- Resolved.
[Bug libstdc++/64584] basic_regex::assign breaks *this if it throws regex_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64584 Tim Shen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||timshen at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Tim Shen --- Resolved.
[Bug libstdc++/64680] basic_regex::operator= does not reset flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64680 Tim Shen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||timshen at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Tim Shen --- Resolved.
[Bug libstdc++/64585] The basic_regex object should not match any character sequence after a call to basic_regex::imbue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64585 Tim Shen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||timshen at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Tim Shen --- Resolved.
[Bug libstdc++/64649] regex_traits::lookup_classname() only works with random access iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64649 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED CC||timshen at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Tim Shen --- Resolved.
