[Bug target/56165] Missed optimization for 'noreturn' functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56165 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-03 09:07:57 UTC --- (In reply to comment #9) 1) I agree for push rbx seves reg. But sub rsp,8 is completely trash, because stack frame do not used at all, not for save reg, nor anything other. You're wrong. That is to maintain the ABI, which for x86_64 says that the stack is 16-byte aligned. Consider e.g. the noreturn function using SSE instructions, without that subq $8, %rsp the stack in the noreturn function would be not properly aligned to 16-bytes and any movdqa and similar insns on stack slots would crash.
[Bug c/56180] Strange behaviour with optimization (using KR C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56180 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-03 09:22:05 UTC --- When you were calling ungetc with uninitialized char, that is invoking undefined behavior, anything can happen at that point.
[Bug middle-end/56188] New: [4.8 regression] FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { (ESCAPED )?(NONLOCAL )?}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56188
Bug #: 56188
Summary: [4.8 regression] FAIL: gcc.dg/ipa/ipa-pta-10.c
scan-ipa-dump pta ESCAPED = { (ESCAPED )?(NONLOCAL
)?}
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sch...@linux-m68k.org
Target: powerpc-*-*
Only fails with -m32.
Executing on host: /daten/gcc/gcc-20130202/Build/gcc/xgcc
-B/daten/gcc/gcc-20130202/Build/gcc/
/daten/gcc/gcc-20130202/gcc/testsuite/gcc.dg/ipa/ipa-pta-10.c
-fno-diagnostics-show-caret -O2 -fipa-pta -fdump-ipa-pta-details -lm -m32
-o ./ipa-pta-10.exe(timeout = 300)
spawn /daten/gcc/gcc-20130202/Build/gcc/xgcc
-B/daten/gcc/gcc-20130202/Build/gcc/
/daten/gcc/gcc-20130202/gcc/testsuite/gcc.dg/ipa/ipa-pta-10.c
-fno-diagnostics-show-caret -O2 -fipa-pta -fdump-ipa-pta-details -lm -m32 -o
./ipa-pta-10.exe
PASS: gcc.dg/ipa/ipa-pta-10.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/daten/gcc/gcc-20130202/Build/gcc:/daten/gcc/gcc-20130202/Build/gcc/64:/daten/gcc/gcc-20130202/Build/powerpc64-linux/./libsanitizer/asan/.libs::/daten/gcc/gcc-20130202/Build/gcc:/daten/gcc/gcc-20130202/Build/gcc/64:/daten/gcc/gcc-20130202/Build/powerpc64-linux/./libsanitizer/asan/.libs:/daten/gcc/gcc-20130202/Build/powerpc64-linux/libstdc++-v3/src/.libs:/daten/gcc/gcc-20130202/Build/powerpc64-linux/libmudflap/.libs:/daten/gcc/gcc-20130202/Build/powerpc64-linux/libsanitizer/.libs:/daten/gcc/gcc-20130202/Build/powerpc64-linux/libssp/.libs:/daten/gcc/gcc-20130202/Build/powerpc64-linux/libgomp/.libs:/daten/gcc/gcc-20130202/Build/powerpc64-linux/libitm/.libs:/daten/gcc/gcc-20130202/Build/powerpc64-linux/libatomic/.libs:/daten/gcc/gcc-20130202/Build/./gcc:/daten/gcc/gcc-20130202/Build/./prev-gcc
spawn [open ...]
PASS: gcc.dg/ipa/ipa-pta-10.c execution test
FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { (ESCAPED
)?(NONLOCAL )?}
$ grep ^ESCAPED ipa-pta-10.c.053i.pta
ESCAPED = *ESCAPED
ESCAPED = ESCAPED + UNKNOWN
ESCAPED = { NULL ESCAPED NONLOCAL foo.varargs i }
[Bug middle-end/56188] [4.8 regression] FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { (ESCAPED )?(NONLOCAL )?}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56188 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2013-02-03 11:52:12 UTC --- Created attachment 29341 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29341 ipa-pta-10.c.053i.pta
[Bug c++/56189] New: Infinite recursion with noexcept when instantiating function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56189
Bug #: 56189
Summary: Infinite recursion with noexcept when instantiating
function template
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@kolumbus.fi
The following code:
namespace test {
templatetypename T
void tt(T, T);
}
templatetypename T
void tt(T a, T b) noexcept(noexcept(::test::tt(a,b)));
templatetypename T
void foo(T x, T y) noexcept(noexcept(tt(x, y)));
int main()
{
int i;
foo(i,i);
}
fails to compile with error:
Compilation finished with errors:
source.cpp:11:47: error: template instantiation depth exceeds maximum of 900
(use -ftemplate-depth= to increase the maximum) substituting 'templateclass T
void tt(T, T) [with T = missing]'
void foo(T x, T y) noexcept(noexcept(tt(x, y)));
^
source.cpp:11:47: recursively required from 'void tt(T, T) [with T = int]'
source.cpp:11:47: required from 'void foo(T, T) [with T = int]'
source.cpp:16:12: required from here
source.cpp:11:47: error: no matching function for call to 'tt(int, int)'
source.cpp:11:47: note: candidate is:
source.cpp:8:6: note: templateclass T void tt(T, T)
void tt(T a, T b) noexcept(noexcept(::test::tt(a,b)));
^
source.cpp:8:6: note: substitution of deduced template arguments resulted in
errors seen above
[Bug target/56165] Missed optimization for 'noreturn' functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56165 --- Comment #11 from Alexander Kobets akobets at mail dot ru 2013-02-03 12:39:00 UTC --- (In reply to comment #10) You're wrong. That is to maintain the ABI, which for x86_64 says that the stack is 16-byte aligned. Consider e.g. the noreturn function using SSE instructions, without that subq $8, %rsp the stack in the noreturn function would be not properly aligned to 16-bytes and any movdqa and similar insns on stack slots would crash. See carefully my compile keys (from first message): x86_64-linux-gnu-gcc -c -Wall -Wno-attributes -save-temps -fverbose-asm -masm=intel -march=core2 -mcmodel=large -mno-mmx -mno-sse -O1 -fno-rtti -fno-default-inline -fomit-frame-pointer -falign-functions=16 -foptimize-sibling-calls -ffreestanding -fno-stack-protector --no-exceptions There is: -mno-mmx -mno-sse and in the long run -fomit-frame-pointer I do not need your charge with your injected code at all. Please understand me.
[Bug target/56165] Missed optimization for 'noreturn' functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56165 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-03 13:07:35 UTC --- (In reply to comment #11) (In reply to comment #10) You're wrong. That is to maintain the ABI, which for x86_64 says that the stack is 16-byte aligned. Consider e.g. the noreturn function using SSE instructions, without that subq $8, %rsp the stack in the noreturn function would be not properly aligned to 16-bytes and any movdqa and similar insns on stack slots would crash. See carefully my compile keys (from first message): x86_64-linux-gnu-gcc -c -Wall -Wno-attributes -save-temps -fverbose-asm -masm=intel -march=core2 -mcmodel=large -mno-mmx -mno-sse -O1 -fno-rtti -fno-default-inline -fomit-frame-pointer -falign-functions=16 -foptimize-sibling-calls -ffreestanding -fno-stack-protector --no-exceptions There is: -mno-mmx -mno-sse and in the long run -fomit-frame-pointer I do not need your charge with your injected code at all. Please understand me. That is completely irrelevant. The noreturn function is usually defined in some other CU, so you don't know what compiler flags it will be compiled with, and -mpreferred-stack-boundary=4 (i.e. 16 bytes alignment) is for x86_64 the smallest supported alignment. Even if you don't use SSE etc., the compiler is allowed and does assume the 16-byte alignment of stack pointer in many places. Note -mcmodel=large in your flags is much bigger slowdown than what you are complaining about here.
[Bug fortran/50627] [4.6/4.7 Regression] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 --- Comment #10 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-03 13:15:24 UTC --- Author: tkoenig Date: Sun Feb 3 13:15:18 2013 New Revision: 195695 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195695 Log: 2013-02-03 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * decl.c (gfc_match_end): Remove half-ready namespace from parent if the end of a block is missing. * parse.c (parse_module): Do not put namespace into gsymbol on error. 2013-02-03 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * gfortran.dg/block_12.f90: New test. * gfortran.dg/module_error_1.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/block_12.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/module_error_1.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/decl.c branches/gcc-4_6-branch/gcc/fortran/parse.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/56054] [4.6/4.7/4.8 Regression] f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-03 13:15:24 UTC --- Author: tkoenig Date: Sun Feb 3 13:15:18 2013 New Revision: 195695 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195695 Log: 2013-02-03 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * decl.c (gfc_match_end): Remove half-ready namespace from parent if the end of a block is missing. * parse.c (parse_module): Do not put namespace into gsymbol on error. 2013-02-03 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * gfortran.dg/block_12.f90: New test. * gfortran.dg/module_error_1.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/block_12.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/module_error_1.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/decl.c branches/gcc-4_6-branch/gcc/fortran/parse.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/50627] [4.6/4.7 Regression] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-03 13:16:30 UTC --- Fixed on all affected and supported branches, closing.
[Bug target/56165] Missed optimization for 'noreturn' functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56165 --- Comment #13 from Alexander Kobets akobets at mail dot ru 2013-02-03 13:48:15 UTC --- (In reply to comment #12) That is completely irrelevant. The noreturn function is usually defined in some other CU, so you don't know what compiler flags it will be compiled with, and -mpreferred-stack-boundary=4 (i.e. 16 bytes alignment) is for x86_64 the smallest supported alignment. Now I tested with -mpreferred-stack-boundary=4 it has no effect. -mpreferred-stack-boundary=4 do not worked, it is fake. Even if you don't use SSE etc., the compiler is allowed and does assume the 16-byte alignment of stack pointer in many places. I try to use some options for explain to compolers what I want. Note -mcmodel=large in your flags is much bigger slowdown than what you are complaining about here. I will take it in account. But I need mainly the unchanged stack pointer at function run.
[Bug c++/56190] New: GCC fails deducing a void(*)(int, float, double) to a void(*)(T..., float, double) with T={int}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56190
Bug #: 56190
Summary: GCC fails deducing a void(*)(int, float, double) to
a void(*)(T..., float, double) with T={int}
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
From
http://stackoverflow.com/questions/14664589/variadic-template-code-compiles-on-gcc-4-6-but-not-on-clang-or-gcc-4-7
:
class Test {
public:
template class... A2 void print (void(*function)(A2..., float, double)) {
}
};
void test_print (int a, float b, double c) { }
int main () {
Test test;
test.printint (test_print);
}
Fails with
source.cpp:14:33: note: candidate is:
source.cpp:3:33: note: templateclass ... A2 void Test::print(void (*)(A2 ...,
float, double))
source.cpp:3:33: note: template argument deduction/substitution failed:
source.cpp:14:33: note: mismatched types 'float' and 'int'
GCC does apparently not substitute the explicitly specified arguments of A2
before attempting the argument deduction.
[Bug c++/56191] New: Destructor affects noexcept detection
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56191
Bug #: 56191
Summary: Destructor affects noexcept detection
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antosh...@gmail.com
GCC 4.7.2 incorrectly detects noexcept specification in case of move
constructor.
Here is an example:
struct descriptor_owner_movable {
descriptor_owner_movable(descriptor_owner_movable ) noexcept {}
// Without destructor it compiles correctly
~descriptor_owner_movable() {}
};
descriptor_owner_movable declval() noexcept;
int main() {
static_assert(
noexcept(descriptor_owner_movable(declval()))
, But it is nothrow!);
return 0;
}
[Bug target/56165] Missed optimization for 'noreturn' functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56165 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-03 14:57:19 UTC --- Not fake, but the default and smallest value, i.e. for x86_64 ABI we don't allow lowering the value to smaller than ABI required alignments. Only for 32-bit i?86 code it is allowed to lower it from 16 down to 4 bytes (the argument to -mpreferred-stack-boundary is N where (1 N) is the alignment).
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #47 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-03 15:16:50 UTC --- posted proposed patch and regression testresults at... http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00055.html http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00251.html
[Bug c++/56192] New: global operator new() vs member operator new()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56192
Bug #: 56192
Summary: global operator new() vs member operator new()
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ts...@mail.ru
g++ 4.8.0 20130127 fails to compile the following code
#include cstddef
template class
struct A {};
template class T
Adecltype(new T) f(int);
template class T
Adecltype(::new T) g(int);
struct X
{
void *operator new(std::size_t n, void *);
};
int main()
{
using type = decltype(gX(0));
}
=
Using built-in specs.
COLLECT_GCC=bin/g++
COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-4.8-20130127/configure
--prefix=/mnt/compiles/toolchains/cpp/4.8.0 --disable-nls
--enable-languages=c,c++,go,fortran --enable-shared --enable-linker-build-id
--with-system-zlib --without-included-gettext --enable-threads=posix
--enable-clocale=gnu --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --disable-bootstrap --disable-multilib
--disable-shared --enable-static
Thread model: posix
gcc version 4.8.0 20130127 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-o' 'program' '-mtune=generic'
'-march=x86-64'
libexec/gcc/x86_64-linux-gnu/4.8.0/cc1plus -quiet -v -imultilib . -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE source.cpp -quiet -dumpbase source.cpp
-mtune=generic -march=x86-64 -auxbase source -std=c++11 -version -o
/tmp/ccKToF0B.s
GNU C++ (GCC) version 4.8.0 20130127 (experimental) (x86_64-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
lib/gcc/x86_64-linux-gnu/4.8.0/../../../../x86_64-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
lib/gcc/x86_64-linux-gnu/4.8.0/../../../../include/c++/4.8.0
lib/gcc/x86_64-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-linux-gnu/.
lib/gcc/x86_64-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward
lib/gcc/x86_64-linux-gnu/4.8.0/include
/usr/local/include
include
lib/gcc/x86_64-linux-gnu/4.8.0/include-fixed
x86_64-linux-gnu
/usr/include
End of search list.
GNU C++ (GCC) version 4.8.0 20130127 (experimental) (x86_64-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c50b4a9e751f2a9ab933b25f6962a9bf
source.cpp: In function 'int main()':
source.cpp:19:33: error: no matching function for call to 'g(int)'
using type = decltype(gX(0));
^
source.cpp:19:33: note: candidate is:
source.cpp:10:26: note: templateclass T Adecltype (new T) g(int)
Adecltype(::new T) g(int);
^
source.cpp:10:26: note: template argument deduction/substitution failed:
source.cpp: In substitution of 'templateclass T Adecltype (new T) g(int)
[with T = missing]':
source.cpp:19:33: required from here
source.cpp:10:26: error: no matching function for call to 'X::operator
new(sizetype)'
source.cpp:10:26: note: candidate is:
source.cpp:14:11: note: static void* X::operator new(std::size_t, void*)
void *operator new(std::size_t n, void *);
^
source.cpp:14:11: note: candidate expects 2 arguments, 1 provided
source.cpp:19:33: error: no matching function for call to 'g(int)'
using type = decltype(gX(0));
^
source.cpp:19:33: note: candidate is:
source.cpp:10:26: note: templateclass T Adecltype (new T) g(int)
Adecltype(::new T) g(int);
^
source.cpp:10:26: note: template argument deduction/substitution failed:
source.cpp: In substitution of 'templateclass T Adecltype (new T) g(int)
[with T = missing]':
source.cpp:19:33: required from here
source.cpp:10:26: error: no matching function for call to 'X::operator
new(sizetype)'
source.cpp:10:26: note: candidate is:
source.cpp:14:11: note: static void* X::operator new(std::size_t, void*)
void *operator new(std::size_t n, void *);
^
source.cpp:14:11: note: candidate expects 2 arguments, 1 provided
=
The
[Bug middle-end/56185] [4.7 Regression] ICE for Arithmetic exception with -O2 and -fgraphite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56185 --- Comment #1 from Daniel Starke daniel.f.starke at freenet dot de 2013-02-03 16:24:56 UTC --- This issue does not appear with isl backend as in the configuration below. However, I still need ppl to build gcc. Using built-in specs. COLLECT_GCC=D:\Programme\msys\mingw64\bin\x86_64-w64-mingw32-gcc.exe COLLECT_LTO_WRAPPER=d:/programme/msys/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.2/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../src/gcc-4.7.2/configure --enable-languages=c,c++ --disable-nls --disable-shared --enable-static --enable-lto --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw64 --with-sysroot=/mingw64 --target=x86_64-w64-mingw32 --enable-targets=all --with-gmp=/usr/new-cross-gcc/lib/gmp-5.0.2 --with-mpfr=/usr/new-cross-gcc/lib/mpfr-2.4.2 --with-mpc=/usr/new-cross-gcc/lib/mpc-0.9 --with-ppl=/usr/new-cross-gcc/lib/ppl-0.11.2 --with-cloog=/usr/new-cross-gcc/lib/cloog-0.18.0 --with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl Thread model: win32 gcc version 4.7.2 (GCC)
[Bug libstdc++/56193] New: ios_base should replace operator void* with explicit operator bool in C++11 onwards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193 Bug #: 56193 Summary: ios_base should replace operator void* with explicit operator bool in C++11 onwards. Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: 3dw...@verizon.net As pointed out on SO, g++ still compiles: std::cout std::cout In C++11 the stream testing operator was changed from: operator void*() const; to: explicit operator bool() const; A quick patch is being tested now. The target is 4.9 even though it is simple.
[Bug testsuite/56194] New: FAIL: g++.dg/init/const9.C -std=c++98 scan-assembler-not rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56194 Bug #: 56194 Summary: FAIL: g++.dg/init/const9.C -std=c++98 scan-assembler-not rodata Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Assembler output contains: .section.rodata .align 4 .LC0: .word P%_ZN3fooD1Ev This is a function descriptor. Think test needs to be xfailed on this target.
[Bug tree-optimization/56195] New: Error: incorrect register `%rdi' used with `l' suffix (at -O2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195
Bug #: 56195
Summary: Error: incorrect register `%rdi' used with `l' suffix
(at -O2)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Using GCC 4.8.0 as of 20130203 :
$ xgcc -v
Using built-in specs.
COLLECT_GCC=/home/merkil/gcc/dist/bin/gcc
COLLECT_LTO_WRAPPER=/home/merkil/gcc/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../srcdir/configure CFLAGS='-O2 -pipe' CXXFLAGS='-O2 -pipe'
--enable-languages=c --prefix=/home/merkil/gcc/dist
Thread model: posix
gcc version 4.8.0 20130203 (experimental) (GCC)
$ cat reg.c
int i, a, t, b, c, d, e, f, j, *h;
void fn(void)
{
if(b)
{
int *p, *q;
char g;
if(f++)
for(;; e++);
lbl:
for(b = 0; b 2; b++)
t /= d + 1 ? : i || a c (d = f) ? : 1 | (j = 2);
*p = g = *q ^ c != a ^ *p;
if(!e)
{
q = p;
goto lbl;
}
}
if(h++)
goto lbl;
}
$ xgcc -O2 reg.c
{standard input}: Assembler messages:
{standard input}:112: Error: incorrect register `%rdi' used with `l' suffix
[Bug ada/56196] New: Assertion failure on aspect clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56196 Bug #: 56196 Summary: Assertion failure on aspect clause Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: si...@pushface.org Created attachment 29342 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29342 Reproducer Compiling the attached union.ads results in the bug box below. The code compiles with GNAT GPL 2012, though I think it shouldn't because this is a non-confirming representation aspect following freeze (ARM 13.1(10)). gcc -c -gnatwa -gnat12 -gnatd.n union.ads /opt/gcc-4.8-195682/lib/gcc/x86_64-apple-darwin12/4.8.0/adainclude/system.ads union.ads +===GNAT BUG DETECTED==+ | 4.8.0 20130202 (experimental) [trunk revision 195682] (x86_64-apple-darwin12) | | Assert_Failure atree.adb:903 | | Error detected at union.ads:1:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). union.ads compilation abandoned gnatmake: union.ads compilation error
[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-03 Target Milestone|--- |4.9.0 Ever Confirmed|0 |1
[Bug c++/56191] Destructor affects noexcept detection
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56191 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-02-03 17:02:59 UTC --- It's the correct behaviour that the destructor affects noexcept detection, because the operand expression creates *and* destroys temporary objects. G++ 4.7 does not apply the rule that destructors are noexcept, so you need to add an explicit noexcept specification on the destructor. GCC 4.8 correctly makes the destructor noexcept as required by C++11.
[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193 --- Comment #1 from Ed Smith-Rowland 3dw4rd at verizon dot net 2013-02-03 17:40:16 UTC --- Created attachment 29343 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29343 Patch including testcase. Here is a small patch. I'm not ure the bast place to put the testcase. Testing is underway. The change builds and fails to compile the testcase as expected on x86_64-unknown-linux.
[Bug tree-optimization/56195] [4.8 Regression] Error: incorrect register `%rdi' used with `l' suffix (at -O2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Target Milestone|--- |4.8.0
Summary|Error: incorrect register |[4.8 Regression] Error:
|`%rdi' used with `l' suffix |incorrect register `%rdi'
|(at -O2)|used with `l' suffix (at
||-O2)
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-03
21:01:59 UTC ---
Started with LRA merge (
http://gcc.gnu.org/viewcvs?root=gccview=revrev=192719 ).
(define_insn *cmpmode_1
[(set (reg FLAGS_REG)
(compare (match_operand:SWI 0 nonimmediate_operand rm,r)
(match_operand:SWI 1 general_operand ri,rm)))]
ix86_match_ccmode (insn, CCmode)
cmp{imodesuffix}\t{%1, %0|%0, %1}
[(set_attr type icmp)
(set_attr mode MODE)])
In *.ira dump the insn looks still correct:
(insn 90 87 91 22 (set (reg:CCGC 17 flags)
(compare:CCGC (reg:SI 118 [ D.1797 ])
(mem:SI (reg/v/f:DI 59 [ q ]) [2 *q_1+0 S4 A32]))) pr56195.c:17 7
{*cmpsi_1}
(nil))
but in *.reload dump:
(insn 90 256 91 22 (set (reg:CCGC 17 flags)
(compare:CCGC (reg:DI 5 di [137])
(mem:SI (reg:DI 5 di [137]) [2 *q_1+0 S4 A32]))) pr56195.c:17 7
{*cmpsi_1}
(expr_list:REG_DEAD (reg:DI 5 di [137])
(nil)))
so I wonder how could it match that way and survive till end of compilation.
[Bug c++/56191] Destructor affects noexcept detection
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56191 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-02-03 21:05:17 UTC --- N.B. you don't need to CC yourself on bugs, the reporter always gets sent changes to the bug
[Bug target/56165] Missed optimization for 'noreturn' functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56165 --- Comment #15 from Alexander Kobets akobets at mail dot ru 2013-02-03 21:56:41 UTC --- (In reply to comment #14) Not fake, but the default and smallest value, i.e. for x86_64 ABI we don't allow lowering the value to smaller than ABI required alignments. Only for 32-bit i?86 code it is allowed to lower it from 16 down to 4 bytes (the argument to -mpreferred-stack-boundary is N where (1 N) is the alignment). But no error is printed when I use -mpreferred-stack-boundary=4 on 64-bit CPU. Only when defined 0, then printed: error: -mpreferred-stack-boundary=0 is not between 4 and 12 while 4 is realy not worked.
[Bug target/56197] New: [SH] Use calculated jump address instead of using a jump table
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56197
Bug #: 56197
Summary: [SH] Use calculated jump address instead of using a
jump table
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
I ran across this one while checking out PR 55146.
If there are a lot of cases in a switch and the length of the case blocks is
more or less constant, it can be beneficial to calculate the jump address and
eliminate the jump table. For example, code such as
int
test (int arg)
{
int rc;
switch (arg)
{
case 0:
asm (nop\n\tnop\n\t
mov r4,%0
: =r (rc)
: r (arg));
break;
case 1:
asm (nop\n\tnop\n\t
mov r5,%0
: =r (rc)
: r (arg));
break;
case 2:
asm (nop\n\tnop\n\t
mov r6,%0
: =r (rc)
: r (arg));
[...]
case 9:
asm (nop\n\tnop\n\t
mov r7,%0
: =r (rc)
: r (arg));
break;
}
return rc;
}
Compiled with -O2 results in:
_test:
mov #9,r1
cmp/hi r1,r4
bt .L2
mova.L4,r0
mov.b @(r0,r4),r4
add r0,r4
jmp @r4
nop
.align 2
.L4:
.byte .L3-.L4
.byte .L5-.L4
.byte .L6-.L4
.byte .L7-.L4
.byte .L8-.L4
.byte .L9-.L4
.byte .L10-.L4
.byte .L11-.L4
.byte .L12-.L4
.byte .L13-.L4
.align 1
.L13:
mov #9,r0
nop
nop
mov r7,r0
.align 2
.L2:
rts
nop
.align 1
.L12:
mov #8,r0
[...]
For a lot of cases, the jump table might become large and is likely to cause
data cache misses. The following might be better in that case (assuming that
the length of each case block is 16 bytes):
mov #9,r1
cmp/hi r1,r4
bt .L2
shll2 r4
shll2 r4
add #.Lcase_0 - .Lcase_default,r4
braf@r4
nop
.Lcase_default:
rts
nop
.align 4
.Lcase_0:
mov #0,r0
nop
nop
mov r4,r0
rts
nop
.align 4
.Lcase_1:
[...]
.align 4
.Lcase_9:
mov #0,r0
nop
nop
mov r7,r0
rts
nop
However, this requires the jump table to be sorted in ascending order and the
length of the case blocks should not vary too much.
Maybe this optimization could also be beneficial on other targets than SH. At
least PR 43462 looks somewhat related to it.
[Bug target/56165] Missed optimization for 'noreturn' functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56165 --- Comment #16 from Alexander Kobets akobets at mail dot ru 2013-02-03 22:02:06 UTC --- (In reply to comment #15) But no error is printed when I use -mpreferred-stack-boundary=4 on 64-bit CPU. Only when defined 0, then printed: error: -mpreferred-stack-boundary=0 is not between 4 and 12 while 4 is realy not worked. Sorry, I cont this parameter in bytes, while it is power of 2. Now all clear to me.
[Bug target/52480] SH Target: SH4A movua.l does not work for big endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52480 --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org 2013-02-03 22:29:46 UTC --- (In reply to comment #7) (In reply to comment #6) As of rev 195493 the test case for this PR is failing again. In fact, now it doesn't work for little and big endian. This is because the standard name patterns insv, extv, extzv got deprecated. The new replacements are: extvm, extvmisalignm, extzvm, extzvmisalignm
[Bug treelang/55269] Rename tree_node complex field to avoid conflict with C99 complex type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55269 peter at colberg dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from peter at colberg dot org 2013-02-03 22:51:29 UTC --- Closing this bug since it no longer applies to GCC ≥ 4.8.
[Bug target/55108] bad compile-time evaluation of members of initialized union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55108 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-02-03 23:24:37 UTC --- On armv5tel-linux-gnueabi this bug is reproducible with gcc-4.6 but not with gcc-4.7 or 4.8. The wrong-code was made latent for 4.7.0 by r179556 aka PR38885, a missed-optimization fix. Bisecting with that fix disabled (a simple #if 0 / #endif wrapper around the new code) showed that the wrong-code was fixed properly for 4.8 by r187648 aka PR53352, a fix for incorrect CSE of unions on ARM. Backporting r187648 to 4.6 fixes this PR's test case with 4.6 on armv5tel. Anyone backporting r187648 to 4.7 or 4.6 should also backport the test case fixup in r187654.
[Bug target/55108] bad compile-time evaluation of members of initialized union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55108 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2013-02-04 00:05:48 UTC --- dup then . *** This bug has been marked as a duplicate of bug 53352 ***
[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||acn1 at cam dot ac.uk --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org 2013-02-04 00:05:48 UTC --- *** Bug 55108 has been marked as a duplicate of this bug. ***
[Bug ada/51483] [4.7/4.8 regression] cstand.adb:Register_Float_Type makes invalid assumptions about FP representation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483 cynt6007 at vandals dot uidaho.edu changed: What|Removed |Added CC||cynt6007 at vandals dot ||uidaho.edu --- Comment #14 from cynt6007 at vandals dot uidaho.edu 2013-02-04 00:07:31 UTC --- Can't build Ada/gnat-4.7 on Ubuntu 12.10 because of SPARK issue, although there are long and complicated directions for how to build Ada/gnat-4.7 on Ubuntu, some work and some don't. Per GNU standards, the build system should be changed so that it's possible to build gnat-4.7 with gnat-4.6. Also, if a native compiler of the same version number must be built to build gnat, then the build system should (but fails to) automatically build the native version first, then use that to build the cross compiler.
[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932 --- Comment #13 from Jan Hubicka hubicka at ucw dot cz 2013-02-04 00:16:44 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-02-01 13:59:11 UTC --- (In reply to comment #11) Thus, I close the bug as INVALID. ... in wich case could you, please, update the testcase to be valid and remove the XFAIL I introduced? We jump through some hoops in or DO loop code generation to execute a loop until HUGE(i) in a way that somebody who did not read the standard well might expect, but which is actually invalid. If we do not do this any more, then we can probably simplify our DO loops considerably. This is probably too late for 4.8.0. The following patch takes advantage of the new option -fno-aggressive-loop-optimizations to remove the xfail (and the two XPASS at -O0 and -O1): This seems like good idea even fo 4.8. Please also split the testcase - it contains several tests and only one has invalid overflow. Honza
[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148 Sérgio Basto sergio at serjux dot com changed: What|Removed |Added CC||sergio at serjux dot com --- Comment #1 from Sérgio Basto sergio at serjux dot com 2013-02-04 03:06:45 UTC --- hi, This happens when compile VirtualBox-4.2.6 with gcc-4.8 the code of in question is include/iprt/asm.h line 4167
[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148 --- Comment #2 from Sérgio Basto sergio at serjux dot com 2013-02-04 03:12:35 UTC --- Hi again, this is not a duplicated bug of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55512 ?
[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04 07:02:05 UTC --- Of course not, the other PR was an ICE (and got fixed already months ago), this one is rejection of (questionable) code, the compiler doesn't crash on it and it is still present on the turnk.
[Bug ada/51483] [4.7/4.8 regression] cstand.adb:Register_Float_Type makes invalid assumptions about FP representation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483 --- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-02-04 07:15:31 UTC --- Can't build Ada/gnat-4.7 on Ubuntu 12.10 because of SPARK issue, although there are long and complicated directions for how to build Ada/gnat-4.7 on Ubuntu, some work and some don't. Per GNU standards, the build system should be changed so that it's possible to build gnat-4.7 with gnat-4.6. Also, if a native compiler of the same version number must be built to build gnat, then the build system should (but fails to) automatically build the native version first, then use that to build the cross compiler. This PR has nothing to do with the build system though.
[Bug c++/56191] Destructor affects noexcept detection
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56191 Antony Polukhin antoshkka at gmail dot com changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Antony Polukhin antoshkka at gmail dot com 2013-02-04 07:27:33 UTC --- Oh, thanks for clarification! Initially I was confused by the fact that std::is_nothrow_constructible checks for destructor, but I thought that it is a 'noexcept()' bug. Now I see that this issue is a duplicate for #51452. (In reply to comment #2) N.B. you don't need to CC yourself on bugs, the reporter always gets sent changes to the bug Thanks, next time I won't be so paranoid about mail notifications! *** This bug has been marked as a duplicate of bug 5142 ***
[Bug spam/5142] Bug#123687: Info received and FILED only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5142 Antony Polukhin antoshkka at gmail dot com changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #2 from Antony Polukhin antoshkka at gmail dot com 2013-02-04 07:27:33 UTC --- *** Bug 56191 has been marked as a duplicate of this bug. ***
[Bug c++/56191] Destructor affects noexcept detection
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56191 --- Comment #4 from Antony Polukhin antoshkka at gmail dot com 2013-02-04 07:28:04 UTC --- Oh, thanks for clarification! Initially I was confused by the fact that std::is_nothrow_constructible checks for destructor, but I thought that it is a 'noexcept()' bug. Now I see that this issue is a duplicate for #51452. (In reply to comment #2) N.B. you don't need to CC yourself on bugs, the reporter always gets sent changes to the bug Thanks, next time I won't be so paranoid about mail notifications!
[Bug c++/56191] Destructor affects noexcept detection
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56191 --- Comment #5 from Antony Polukhin antoshkka at gmail dot com 2013-02-04 07:29:16 UTC --- *** This bug has been marked as a duplicate of bug 51452 ***
[Bug libstdc++/51452] [DR 2116] has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 --- Comment #16 from Antony Polukhin antoshkka at gmail dot com 2013-02-04 07:29:16 UTC --- *** Bug 56191 has been marked as a duplicate of this bug. ***
[Bug ada/56178] [4.8 Regression] Conversion of Long_Float to Integer triggers CONSTRAINT_ERROR overflow check failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56178 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-04 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04 07:32:46 UTC --- This only seems to occur in profiledbootstrap, e.g. x86_64-linux --enable-checking=release profiledbootstrap, stagefeedback gnat1 fails, while stageprofile and stage1 gnat1 work (and in normal bootstrap all of stage[123] work). The issue is somewhere in the Ada FE, already in the *.original dump the difference is between if (0) vs. if (1) for the overflow check call. Compared to normal bootstrap (also --enable-checking=yes,rtl) with profiledbootstrap (--enable-checking=release) also shows: +FAIL: c34002a +FAIL: c460007 +FAIL: c490001 +FAIL: cc1221d +FAIL: cxa5a04 +FAIL: cxg2001 +FAIL: cxg2015 regressions, not sure if that is in any way relased to this issue.
[Bug bootstrap/56198] New: [4.8 Regression] Go profiledbootstrap error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56198
Bug #: 56198
Summary: [4.8 Regression] Go profiledbootstrap error
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: i...@gcc.gnu.org
My --enable-checking=release profiledbootstrap failed on an maybe uninitialized
warning turned into -Werror in go/gofrontend/import-archive.cc.
Archive_file::read_header has:
off_t local_nested_off;
if (!this-interpret_header(hdr, off, pname, size, local_nested_off))
return false;
if (nested_off != NULL)
*nested_off = local_nested_off;
and the warning was complaining that local_nested_off might be uninitialized.
If Archive_file::interpret_header is what is called here, then *nested_off
might be indeed uninitialized even when the function returns true, in
particular for:
else if (hdr-ar_name[1] == ' ')
{
// This is the symbol table.
pname-clear();
}
else if (hdr-ar_name[1] == '/')
{
// This is the extended name table.
pname-assign(1, '/');
}
BTW, there seems to be also an inconsistency in that method, the first write
to
*nested_off in that method is not guarded by nested_off != NULL:
*nested_off = 0;
while the second one is:
if (nested_off != NULL)
*nested_off = y;
[Bug bootstrap/56198] [4.8 Regression] Go profiledbootstrap error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56198 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
