[Bug tree-optimization/77697] suspicious code in tree-ssa-forwprop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77697 --- Comment #1 from Richard Biener --- No, the code doesn't make any sense at all. The following should fix most of the obvious errors. Index: gcc/tree-ssa-forwprop.c === --- gcc/tree-ssa-forwprop.c (revision 240386) +++ gcc/tree-ssa-forwprop.c (working copy) @@ -1458,6 +1458,7 @@ defcodefor_name (tree name, enum tree_co code1 = TREE_CODE (name); arg11 = name; arg21 = NULL_TREE; + arg31 = NULL_TREE; grhs_class = get_gimple_rhs_class (code1); if (code1 == SSA_NAME) @@ -1470,20 +1471,18 @@ defcodefor_name (tree name, enum tree_co code1 = gimple_assign_rhs_code (def); arg11 = gimple_assign_rhs1 (def); arg21 = gimple_assign_rhs2 (def); - arg31 = gimple_assign_rhs2 (def); + arg31 = gimple_assign_rhs3 (def); } } - else if (grhs_class == GIMPLE_TERNARY_RHS - || GIMPLE_BINARY_RHS - || GIMPLE_UNARY_RHS - || GIMPLE_SINGLE_RHS) -extract_ops_from_tree (name, &code1, &arg11, &arg21, &arg31); + else if (grhs_class != GIMPLE_SINGLE_RHS) +code1 = ERROR_MARK; *code = code1; *arg1 = arg11; if (arg2) *arg2 = arg21; - /* Ignore arg3 currently. */ + if (arg31) +*code = ERROR_MARK; }
[Bug tree-optimization/77697] suspicious code in tree-ssa-forwprop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77697 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-23 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug bootstrap/77695] [7 Regression] bootstrap failure due to undeclared hook_uint_uintp_false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77695 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug fortran/77703] New: ICE on assignment to pointer function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77703 Bug ID: 77703 Summary: ICE on assignment to pointer function Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Although related to PR68226, this code ICEs in a different place module m implicit none private integer, parameter, public :: n = 2 integer, parameter :: ell = 6 character(len=n*ell), target, public :: s public :: t contains function t( idx ) result( substr ) integer, intent(in) :: idx !.. Function result character(len=ell), pointer :: substr if ( (idx < 0).or.(idx > n) ) then error stop end if substr => s((idx-1)*ell+1:idx*ell) return end function t end module m program p use m, only : s, t, n integer :: i ! Some sections of code define 's' s = "123456789012" ! Then perform operations involving 't' do i = 1, n print *, t(i) end do ! Other sections of code define 't' t(1) = "Hello" ! t(2) = "World!" ! Then perform operations involving 's' print *, s stop end program p internal compiler error: in gfc_trans_auto_character_variable, at fortran/trans-decl.c:3763 0x6dec56 gfc_trans_auto_character_variable ../../trunk/gcc/fortran/trans-decl.c:3763 0x6dec56 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*) ../../trunk/gcc/fortran/trans-decl.c:4512 0x6e0bf3 gfc_generate_function_code(gfc_namespace*) ../../trunk/gcc/fortran/trans-decl.c:6362 0x66aea6 translate_all_program_units ../../trunk/gcc/fortran/parse.c:5936 0x66aea6 gfc_parse_file() ../../trunk/gcc/fortran/parse.c:6142 0x6ad472 gfc_be_parse_file ../../trunk/gcc/fortran/f95-lang.c:198 Please submit a full bug report, The current version of ifort comes up with an error message to the effect that this is an unimplemented feature. Paul
[Bug bootstrap/77695] [7 Regression] bootstrap failure due to undeclared hook_uint_uintp_false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77695 avieira at gcc dot gnu.org changed: What|Removed |Added CC||avieira at gcc dot gnu.org --- Comment #4 from avieira at gcc dot gnu.org --- Sorry about that and thank you for the fix. I'm curious as to why my aarch64 bootstrap didnt pick this up, it was with an earlier version (2 months ago) but I dont see why that would make a difference in this case. Anyhow, again sorry for breaking the world. Cheers, Andre
[Bug target/71652] [5/6/7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71652 --- Comment #8 from Martin Liška --- Author: marxin Date: Fri Sep 23 07:55:57 2016 New Revision: 240392 URL: https://gcc.gnu.org/viewcvs?rev=240392&root=gcc&view=rev Log: Fix PR target/71652 PR target/71652 * config/i386/i386.c (ix86_option_override_internal): Change signature and return false when there's an error related to arch string. (release_options_strings): New function. (ix86_valid_target_attribute_tree): Call the function. * gcc.target/i386/pr71652.c: New test. * gcc.target/i386/pr71652-2.c: New test. * gcc.target/i386/pr71652-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr71652-2.c trunk/gcc/testsuite/gcc.target/i386/pr71652-3.c trunk/gcc/testsuite/gcc.target/i386/pr71652.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/71652] [5/6/7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71652 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška --- Fixed on trunk.
[Bug fortran/77703] [6/7 Regression] ICE on assignment to pointer function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77703 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||5.4.0 Keywords||ice-on-invalid-code Last reconfirmed||2016-09-23 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE on assignment to|[6/7 Regression] ICE on |pointer function|assignment to pointer ||function Target Milestone|--- |6.3 --- Comment #1 from Martin Liška --- Started with r228222.
[Bug debug/77692] [7 regression] gcc.dg/debug/dwarf2/const-2b.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77692
--- Comment #3 from Richard Biener ---
Ok, so tree_add_const_value_attribute_for_decl gives up because the decl is not
readonly. But via add_location_or_const_value_attribute rtl_for_decl_location
would get us
(const_vector:V4SF [
(const_double:SF 2.5e+8 [0x0.ee6b28p+28])
(const_double:SF 0.0 [0x0.0p+0])
(const_double:SF 0.0 [0x0.0p+0])
(const_double:SF 0.0 [0x0.0p+0])
])
which looks inconsistent. That simply does
/* A variable with no DECL_RTL but a DECL_INITIAL is a compile-time constant,
and will have been substituted directly into all expressions that use it.
C does not have such a concept, but C++ and other languages do. */
if (!rtl && TREE_CODE (decl) == VAR_DECL && DECL_INITIAL (decl))
rtl = rtl_for_decl_init (DECL_INITIAL (decl), TREE_TYPE (decl));
which may be true if called late enough.
We're invoking dwarf2out_late_global_decl for removed globals only at a very
specific point so it doesn't get called for
typedef float FloatVect __attribute__((__vector_size__(16)));
static FloatVect Foo = { 25000.0, 0.0, 0.0, 0.0 };
int main()
{
Foo = (FloatVect) { 1., 1., 1., 1. };
}
where we also remove Foo (as write-only). For this case it would be definitely
bogus to add a DW_AT_const_value attribute. We do call it for
typedef float FloatVect __attribute__((__vector_size__(16)));
static FloatVect Foo = { 25000.0, 0.0, 0.0, 0.0 };
static void bar ()
{
Foo = (FloatVect) { 1., 1., 1., 1. };
}
int main()
{
}
which means this case did get a DW_AT_const_value attached to Foo.
Note that on the original testcase IPA would have found Foo to be readonly,
likewise on the last.
I believe rtl_for_decl_location is bogus doing
/* A variable with no DECL_RTL but a DECL_INITIAL is a compile-time constant,
and will have been substituted directly into all expressions that use it.
C does not have such a concept, but C++ and other languages do. */
if (!rtl && TREE_CODE (decl) == VAR_DECL && DECL_INITIAL (decl))
rtl = rtl_for_decl_init (DECL_INITIAL (decl), TREE_TYPE (decl));
when it is called early before decl got a chance to even create RTL.
So -- is it worth trying to handle this special case where we know a variable
is readonly by means of nothing referencing it? Then the following fixes it:
Index: gcc/cgraphunit.c
===
--- gcc/cgraphunit.c(revision 240388)
+++ gcc/cgraphunit.c(working copy)
@@ -1194,8 +1194,15 @@ analyze_functions (bool first_time)
at looking at optimized away DECLs, since
late_global_decl will subsequently be called from the
contents of the now pruned symbol table. */
- if (!decl_function_context (node->decl))
- (*debug_hooks->late_global_decl) (node->decl);
+ if (TREE_CODE (node->decl) == VAR_DECL
+ && !decl_function_context (node->decl))
+ {
+ /* We are reclaiming totally unreachable code and variables
+so they effectively appear as readonly. Show that to
+the debug machinery. */
+ TREE_READONLY (node->decl) = 1;
+ (*debug_hooks->late_global_decl) (node->decl);
+ }
node->remove ();
continue;
[Bug fortran/77693] ICE in rtl_for_decl_init, at dwarf2out.c:17378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77693
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #3 from Richard Biener ---
(gdb) p debug_rtx (rtl)
(mem/u/c:SC (symbol_ref/f:DI ("*.LC1") [flags 0x2] ) [0 S8 A32])
(gdb) p init
$3 =
and we see a comment:
/* Other aggregates, and complex values, could be represented using
CONCAT: FIXME! */
but, of course
(gdb) p type
$6 =
so the issue is really that we have
asm_written SC
size
unit size
align 32 symtab -156936400 alias set 2 canonical type
0x768a21f8
pointer_to_this >
asm_written public unsigned DI size
unit size
align 64 symtab -156936480 alias set 1 canonical type 0x76a4d000
pointer_to_this >
readonly static unsigned DI file t.f90 line 2 col 0 size unit size
align 64 context initial chain >
thus a pointer variable with a complex_cst initializer.
-> FE issue.
And if the code is valid then it's wrong-code as well. The FE needs to
output a CONST_DECL for the complex constant and the initializer for A
needs to be the address of that.
[Bug tree-optimization/77689] Missing vectorization lead to huge performance loss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689 --- Comment #10 from Markus Trippelsdorf --- (In reply to Richard Biener from comment #5) > we can't remove the stores because we still can't grok C++ new/delete. Is there a PR that tracks this issue?
[Bug tree-optimization/77689] Missing vectorization lead to huge performance loss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689 --- Comment #11 from Andrew Pinski --- (In reply to Markus Trippelsdorf from comment #10) > (In reply to Richard Biener from comment #5) > > we can't remove the stores because we still can't grok C++ new/delete. > > Is there a PR that tracks this issue? Yes but I don't know the number off hand I know there are a few. In fact one where Chris Latern was on and said it was an invalid treatment to do.
[Bug libstdc++/77704] New: Data race on std::regex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
Bug ID: 77704
Summary: Data race on std::regex
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: morandidodo at gmail dot com
Target Milestone: ---
The thread sanitizer says that there is a data race during regex construction.
Here a simple test:
#include
#include
#include
static const std::string test_string =
"aiusndougbafiudboihvboauvhbadnofhdbvouahvebfdocsahkbnavoiekrhfdsbvjqon";
static constexpr unsigned n_threads = 30;
void test()
{
std::regex re = std::regex("[abg][jtd]");
std::regex_match(test_string, re);
}
int main()
{
std::vector threads;
threads.reserve(n_threads);
for(unsigned i = 0; i < n_threads; ++i)
threads.emplace_back(test);
for(unsigned i = 0; i < n_threads; ++i)
threads[i].join();
}
Compiled with GCC 6.2.1, using
g++ -Wall -Wextra -O3 test.cpp -o test -g -pthread -fsanitize=thread
Running the test gives these "results":
==
WARNING: ThreadSanitizer: data race (pid=14501)
Read of size 1 at 0x7fc2e581b1f4 by thread T2:
#0 std::ctype::narrow(char, char) const
/usr/include/c++/6.2.1/bits/locale_facets.h:932 (test+0x004064f4)
#1 std::__detail::_Scanner::_M_scan_normal()
/usr/include/c++/6.2.1/bits/regex_scanner.tcc:101 (test+0x004064f4)
#2 std::__detail::_Scanner::_M_advance()
/usr/include/c++/6.2.1/bits/regex_scanner.tcc:80 (test+0x004083af)
#3 std::__detail::_Scanner::_Scanner(char const*, char const*,
std::regex_constants::syntax_option_type, std::locale)
/usr/include/c++/6.2.1/bits/regex_scanner.tcc:66 (test+0x004083af)
#4 std::__detail::_Compiler
>::_Compiler(char const*, char const*, std::locale const&,
std::regex_constants::syntax_option_type)
/usr/include/c++/6.2.1/bits/regex_compiler.tcc:78 (test+0x00422b8a)
#5 std::enable_if::value,
std::shared_ptr > const>
>::type std::__detail::__compile_nfa >(char const*, char const*,
std::__cxx11::regex_traits::locale_type const&,
std::regex_constants::syntax_option_type)
/usr/include/c++/6.2.1/bits/regex_compiler.h:194 (test+0x0042379f)
#6 std::__cxx11::basic_regex
>::basic_regex(char const*, char const*, std::locale,
std::regex_constants::syntax_option_type)
/usr/include/c++/6.2.1/bits/regex.h:767 (test+0x004034df)
#7 std::__cxx11::basic_regex
>::basic_regex(char const*, char const*,
std::regex_constants::syntax_option_type)
/usr/include/c++/6.2.1/bits/regex.h:512 (test+0x004034df)
#8 std::__cxx11::basic_regex
>::basic_regex(char const*, std::regex_constants::syntax_option_type)
/usr/include/c++/6.2.1/bits/regex.h:445 (test+0x004034df)
#9 test() /tmp/test3.cpp:10 (test+0x004034df)
#10 void std::_Bind_simple::_M_invoke<>(std::_Index_tuple<>)
/usr/include/c++/6.2.1/functional:1400 (test+0x00403fc9)
#11 std::_Bind_simple::operator()()
/usr/include/c++/6.2.1/functional:1389 (test+0x00403fc9)
#12 std::thread::_State_impl >::_M_run()
/usr/include/c++/6.2.1/thread:196 (test+0x00403fc9)
#13 execute_native_thread_routine
/build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/thread.cc:83
(libstdc++.so.6+0x000bb31e)
Previous write of size 1 at 0x7fc2e581b1f4 by thread T1:
#0 std::ctype::narrow(char, char) const
/usr/include/c++/6.2.1/bits/locale_facets.h:936 (test+0x0040665d)
#1 std::__detail::_Scanner::_M_scan_normal()
/usr/include/c++/6.2.1/bits/regex_scanner.tcc:101 (test+0x0040665d)
#2 std::__detail::_Scanner::_M_advance()
/usr/include/c++/6.2.1/bits/regex_scanner.tcc:80 (test+0x004083af)
#3 std::__detail::_Scanner::_Scanner(char const*, char const*,
std::regex_constants::syntax_option_type, std::locale)
/usr/include/c++/6.2.1/bits/regex_scanner.tcc:66 (test+0x004083af)
#4 std::__detail::_Compiler
>::_Compiler(char const*, char const*, std::locale const&,
std::regex_constants::syntax_option_type)
/usr/include/c++/6.2.1/bits/regex_compiler.tcc:78 (test+0x00422b8a)
#5 std::enable_if::value,
std::shared_ptr > const>
>::type std::__detail::__compile_nfa >(char const*, char const*,
std::__cxx11::regex_traits::locale_type const&,
std::regex_constants::syntax_option_type)
/usr/include/c++/6.2.1/bits/regex_compiler.h:194 (test+0x0042379f)
#6 std::__cxx11::basic_regex
>::basic_regex(char const*, char const*, std::locale,
std::regex_constants::syntax_option_type)
/usr/include/c++/6.2.1/bits/regex.h:767 (test+0x004034df)
#7 std::__cxx11::basic_regex
>::basic_regex(char const*, char const*,
std::regex_constants::syntax_option_type)
/usr/include/c++/6.2.1/bits/regex.h:512 (test+0x004034df)
#8 std::__cxx11::basic_regex
>::basic_regex(char const*, std::regex_constants::syntax_option_type)
/usr/include/c++/6.2.1/bits/regex.h:445 (test+0x004034df)
#9 test() /t
[Bug libstdc++/77704] Data race on std::cype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-09-23
Summary|Data race on std::regex |Data race on std::cype
Ever confirmed|0 |1
Severity|major |normal
--- Comment #1 from Jonathan Wakely ---
Ugh, we have mutable members in std::ctype
#include
#include
int main()
{
auto& ctype = std::use_facet>(std::locale::classic());
auto f = [&]{ for (int i = 0; i < 64; ++i) ctype.narrow(i, 'a'); };
std::thread t1{f};
std::thread t2{f};
t1.join();
t2.join();
}
[Bug tree-optimization/77705] New: Optimize away some static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77705
Bug ID: 77705
Summary: Optimize away some static constructors
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
struct S { int a; };
void baz (S *);
#if __cpp_constexpr >= 200704
constexpr
#endif
inline S foo () { return (S) { 2 }; }
S s = foo ();
for -std=c++98 -O2 we have the runtime initializer. If we had some pass that
would analyze the ctor functions after they were inlined into and if they only
write constants into file-scope vars defined in the current TU (except for
comdat vars?) turn the ctor function into static initializers for the
file-scope vars.
Not sure if we can do it generally for any (non-comdat?) vars, or if e.g. the
C++ FE wouldn't have to mark such vars some way for us, or if we wouldn't need
to analyze if there aren't some ctors in the same TU that would run earlier
(higher (or is that lower?) priority) and could access those vars, or for vars
visible outside of the TU if some other TU's ctor couldn't access them.
An argument for some guidance from the C++ FE would be that say in C:
int a __attribute__((nocommon));
static __attribute__((constructor)) void
foo (void)
{
a = 6;
}
some other TU could say in heither priority ctor expect to see a == 0.
[Bug tree-optimization/77706] New: Optimize away some local static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77706
Bug ID: 77706
Summary: Optimize away some local static constructors
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Similar to PR77705, but even harder:
struct S { int a; };
void baz (S *);
#if __cpp_constexpr >= 200704
constexpr
#endif
inline S foo () { return (S) { 2 }; }
void
bar ()
{
static S t = foo ();
baz (&t);
}
inline void
bar2 ()
{
static S t = foo ();
baz (&t);
}
void
bar3 ()
{
bar2 ();
}
Here we have:
static struct S t;
unsigned char _1;
int _2;
:
_1 = __atomic_load_1 (&_ZGVZ3barvE1t, 2);
if (_1 == 0)
goto ;
else
goto ;
:
goto ;
:
_2 = __cxa_guard_acquire (&_ZGVZ3barvE1t);
if (_2 != 0)
goto ;
else
goto ;
:
MEM[(struct S *)&t] = 2;
__cxa_guard_release (&_ZGVZ3barvE1t);
:
it would be nice to turn that into static struct S t = { 2 }; and get rid of
the guard var and atomics/__cxa_guard*, but we need to consider ABI issues if
the guard var is visible outside of the TU.
[Bug tree-optimization/77705] Optimize away some static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77705 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-23 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. I would like to see us moving towards keeping the individual static ctor functions separate and registered in the varpool (and leave building of the actual CTOR function wrapping them eventually to IPA). This would allow to run early opts over them and then eventually turn them into static initialization.
[Bug tree-optimization/77706] Optimize away some local static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77706 --- Comment #1 from Andrew Pinski --- There might be a duplicate of this bug already.
[Bug tree-optimization/77706] Optimize away some local static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77706 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-23 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Same as PR77705 but in this case the constructor functions should include the locking/ref-counting dance (so we can optimize that as well). Gets interesting if we optimize multiple adjacent static inits with a single lock (do we?) though then we'd just make a wrapper that just contains the locking.
[Bug fortran/77707] New: [4.5-7.0 Regression] formatted direct access: nextrec off by one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77707 Bug ID: 77707 Summary: [4.5-7.0 Regression] formatted direct access: nextrec off by one Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- program directaccess_formatted integer nextrec open(10, file='directaccess_formatted.dat', form='formatted', access='direct', recl=10*4) write(10,'(10i4)',rec=9) 1,2,3,4,5,6,7,8,9,10 inquire(unit=10,nextrec=nextrec) print*,"Next rec: ",nextrec close(10) end prints the following: 4.3: Next rec: 10 4.5-7.0: Next rec:9 As I have no working gfortran 4.4 any more, I can't tell whether 4.4 is OK or not. nextrec is "last record read or written, plus one". In contrast, unformatted direct access is OK and prints "10". Possibly related bugs: Bug 14836, Bug 14904
[Bug tree-optimization/77677] [7 Regression] ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77677 --- Comment #8 from kugan at gcc dot gnu.org --- Author: kugan Date: Fri Sep 23 10:25:09 2016 New Revision: 240420 URL: https://gcc.gnu.org/viewcvs?rev=240420&root=gcc&view=rev Log: Drop TREE_OVERFLOW gcc/ChangeLog: 2016-09-23 Kugan Vivekanandarajah PR ipa/77677 * ipa-cp.c (propagate_vr_accross_jump_function): Drop TREE_OVERFLOW from constant while creating value range. gcc/testsuite/ChangeLog: 2016-09-23 Kugan Vivekanandarajah PR ipa/77677 * gcc.dg/torture/pr77677.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr77677.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug c/77690] -Wformat-length %s false positive after strlen check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690 --- Comment #2 from nsz at gcc dot gnu.org --- (In reply to Martin Sebor from comment #1) > sprintf(foo, "zz%.4s", s.buf); > > Please let me know if this isn't sufficient to resolve the problem report. in my case truncation is fatal error so using precision is not useful (other than suppressing the warning) and has a runtime cost (extra arg passing for %.*s).
[Bug fortran/77707] [5/6/7 Regression] formatted direct access: nextrec off by one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77707 Richard Biener changed: What|Removed |Added Keywords||wrong-code Known to work||4.3.5 Target Milestone|--- |5.5 Summary|[4.5-7.0 Regression]|[5/6/7 Regression] |formatted direct access:|formatted direct access: |nextrec off by one |nextrec off by one
[Bug tree-optimization/77697] suspicious code in tree-ssa-forwprop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77697 --- Comment #2 from Richard Biener --- Author: rguenth Date: Fri Sep 23 12:37:22 2016 New Revision: 240430 URL: https://gcc.gnu.org/viewcvs?rev=240430&root=gcc&view=rev Log: 2016-09-23 Richard Biener PR tree-optimization/77697 * tree-ssa-forwprop.c (defcodefor_name): Remove bogus code, signal error if we have sth ternary or unhandled. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug tree-optimization/77697] suspicious code in tree-ssa-forwprop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77697 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug c/77690] -Wformat-length %s false positive after strlen check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690 nsz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from nsz at gcc dot gnu.org --- (In reply to nsz from comment #2) > in my case truncation is fatal error so using precision is not useful (other > than suppressing the warning) and has a runtime cost (extra arg passing for > %.*s). nevermind, i'll just use snprintf.
[Bug c/77708] New: -Wformat-length %s warns for snprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77708
Bug ID: 77708
Summary: -Wformat-length %s warns for snprintf
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
snprintf does not do oob memory access, so if the return value is checked then,
there should be no buffer overflow warning.
$ cat a.c
int snprintf (char*, __SIZE_TYPE__, const char*, ...);
struct { char buf[12]; } s;
int f(void)
{
char foo[7];
return snprintf(foo, sizeof foo, "zz%s", s.buf) >= sizeof foo;
}
$ gcc -c -Wall a.c
a.c: In function 'f':
a.c:8:10: warning: '%s' directive output may be truncated writing between 0 and
11 bytes into a region of size 5 [-Wformat-length=]
return snprintf(foo, sizeof foo, "zz%s", s.buf) >= sizeof foo;
^~~~
a.c:8:10: note: format output between 3 and 14 bytes into a destination of size
7
[Bug preprocessor/77672] wrong rich location in warning: writing a terminating nul past the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77672 --- Comment #3 from David Malcolm --- Author: dmalcolm Date: Fri Sep 23 14:14:52 2016 New Revision: 240434 URL: https://gcc.gnu.org/viewcvs?rev=240434&root=gcc&view=rev Log: Provide location information for terminator characters (PR preprocessor/77672) substring_loc::get_location currently fails for the final terminator character in a STRING_CST from the C frontend, so that format_warning_va falls back to using the location of the string as a whole. This patch tweaks things [1] so that we use the final closing quote as the location of the terminator character, as requested in PR preprocessor/77672. [1] specifically, cpp_interpret_string_1. gcc/ChangeLog: PR preprocessor/77672 * input.c (selftest::test_lexer_string_locations_simple): Update test to expect location information of the terminator character at the location of the final closing quote. (selftest::test_lexer_string_locations_hex): Likewise. (selftest::test_lexer_string_locations_oct): Likewise. (selftest::test_lexer_string_locations_letter_escape_1): Likewise. (selftest::test_lexer_string_locations_letter_escape_2): Likewise. (selftest::test_lexer_string_locations_ucn4): Likewise. (selftest::test_lexer_string_locations_ucn8): Likewise. (selftest::test_lexer_string_locations_u8): Likewise. (selftest::test_lexer_string_locations_utf8_source): Likewise. (selftest::test_lexer_string_locations_concatenation_1): Likewise. (selftest::test_lexer_string_locations_concatenation_2): Likewise. (selftest::test_lexer_string_locations_concatenation_3): Likewise. (selftest::test_lexer_string_locations_macro): Likewise. (selftest::test_lexer_string_locations_long_line): Likewise. gcc/testsuite/ChangeLog: PR preprocessor/77672 * gcc.dg/plugin/diagnostic-test-string-literals-1.c (test_terminator_location): New function. libcpp/ChangeLog: PR preprocessor/77672 * charset.c (cpp_interpret_string_1): Add a source_range for the NUL-terminator, using the location of the trailing quote of the final string. Modified: trunk/gcc/ChangeLog trunk/gcc/input.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c trunk/libcpp/ChangeLog trunk/libcpp/charset.c
[Bug preprocessor/77672] wrong rich location in warning: writing a terminating nul past the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77672
--- Comment #4 from David Malcolm ---
(In reply to Martin Sebor from comment #2)
> I think the general improvement I'm suggesting is to be able to put the
> tilde(s) under or point the caret at any character of the format string,
> including either of the two quotes.
If desired, you can use make_location to construct a location_t for such
situations... though I'm not sure that it makes sense to do so for all of the
different combinations. I've tried to make class substring_loc provide the API
needed for the common case.
> It's already possible to underscore the whole format string and point the
> caret at any character within in, including the first quote, so it seems
> natural to also point the caret at the last quote.
r240434 updates things so that substring_loc::get_location uses the final quote
for the location of the NUL-terminator character for STRING_CSTs from the C
frontend, so that if that character's index is passed as one of the indices to
substring_loc's constructor, it will handle that (previously, doing so would
lead to substring_loc::get_location, leading to format_warning using the whole
string range, with both start and end quotes).
The output for the test case is now:
$ ./xgcc -B. -c v.c -Wall
v.c: In function ‘f’:
v.c:6:19: warning: writing format character ‘!’ at offset 3 past the end of the
destination [-Wformat-length=]
sprintf (d, "%-s!", "abc");
^
v.c:6:3: note: format output 5 bytes into a destination of size 3
sprintf (d, "%-s!", "abc");
^~
v.c: In function ‘g’:
v.c:10:18: warning: writing a terminating nul past the end of the destination
[-Wformat-length=]
sprintf (d, "%-s", "abc");
~~^~
v.c:10:3: note: format output 4 bytes into a destination of size 3
sprintf (d, "%-s", "abc");
^
Note how in the warning for g it has underlined from the first char through to
the close-quote, with the caret on the s. This is with:
(gdb) p fmt_loc
$1 = (const substring_loc &) @0x7fffda90: {m_fmt_string_loc = 2147483655,
m_string_type = ,
m_caret_idx = 2, m_start_idx = 0, m_end_idx = 3}
so it is faithfully printing the idx values it's been provided with by the
diagnostic code.
[Bug middle-end/77709] New: specified destination size warning does not work when cross-compiling from 64 host to 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77709 Bug ID: 77709 Summary: specified destination size warning does not work when cross-compiling from 64 host to 32bit target Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: arm-none-eabi Hi, gcc.dg/tree-ssa/builtin-sprintf-warn-1.c is failing on an arm-none-eabi GCC cross-compiler on x86_64-linux-gnu machine because the following warning are missing: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 1222) FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 1272) FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 1383) I believe the reason is that -1 would create a MAX_UINT on a 32bit target which would be smaller than an HOST_WIDE_INT_MAX of the 64bit host so the following test would fail: if (dstsize >= HOST_WIDE_INT_MAX) warning_at (gimple_location (info.callstmt), OPT_Wformat_length_, "specified destination size %wu too large", dstsize); I'm not sure if the fault lies in the gimple code or the testsuite though.
[Bug testsuite/77411] object-size-9.c -fpic -m32 failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77411 --- Comment #3 from Bernd Edlinger --- Author: edlinger Date: Fri Sep 23 14:43:45 2016 New Revision: 240437 URL: https://gcc.gnu.org/viewcvs?rev=240437&root=gcc&view=rev Log: 2016-09-23 Bernd Edlinger Tom de Vries PR testsuite/77411 * c-c++-common/ubsan/object-size-9.c: Call __builtin_exit in C++. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/ubsan/object-size-9.c
[Bug preprocessor/77672] wrong rich location in warning: writing a terminating nul past the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77672 --- Comment #5 from David Malcolm --- BTW, if you do have a need to send a "print the whole string" request via class substring_loc, that could be handled by passing in INT_MAX as the idx values, which will lead to a failure. (we could make it handle -1 similarly, but input.c:get_source_location_for_substring currently only checks the upper bound; it doesn't yet check > 0, but that would be trivial).
[Bug testsuite/77710] New: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77710 Bug ID: 77710 Summary: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: arm-none-eabi Hi, gcc.dg/tree-ssa/builtin-sprintf-warn-4.c fails on arm-none-eabi targets for excess errors because it does not seem to see the dg-warning and dg-message directive. This seems to be related to the multiline checks because when removing those the warnings are catched. Here is the output I get: gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: In function 'test':^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:10:21: warning: writing a terminating nul past the end of the destination [-Wformat-length=]^M sprintf (dst + 7, "%-s", "1");^M ^^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:10:3: note: format output 2 bytes into a destination of size 1^M sprintf (dst + 7, "%-s", "1");^M ^^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:22:22: warning: '%-s' directive writing 4 bytes into a region of size 1 [-Wformat-length=]^M sprintf (dst + 7, "%-s", "abcd");^M ^~~ ~~^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:22:3: note: format output 5 bytes into a destination of size 1^M sprintf (dst + 7, "%-s", "abcd");^M ^~~~^M PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c expected multiline pattern lines 14-15 was found: "\s*sprintf \(dst \+ 7, "%-s", "1"\);.*\n \^\n" PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c expected multiline pattern lines 18-19 was found: " sprintf \(dst \+ 7, "%-s", "1"\);.*\n \^\n" PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c expected multiline pattern lines 26-27 was found: " sprintf \(dst \+ 7, "%-s", "abcd"\);.*\n \^~~ ~~\n" PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c expected multiline pattern lines 30-31 was found: " sprintf \(dst \+ 7, "%-s", "abcd"\);.*\n \^~~~\n" FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c (test for excess errors) Excess errors: gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:10:21: warning: writing a terminating nul past the end of the destination [-Wformat-length=]gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:22:22: warning: '%-s' directive writing 4 bytes into a region of size 1 [-Wformat-length=]
[Bug c++/77711] New: Add fix-it hints for missing parentheses in member function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77711
Bug ID: 77711
Summary: Add fix-it hints for missing parentheses in member
function call
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
struct A {
int foo() { return 0; }
};
void bar(int);
int main()
{
A a;
bar( a.foo );
}
This gives:
foo.cc: In function ‘int main()’:
foo.cc:10:14: error: invalid use of non-static member function ‘int A::foo()’
bar( a.foo );
^
foo.cc:2:7: note: declared here
int foo() { return 0; }
^~~
It should suggest changing it to a.foo()
[Bug c++/77712] New: int() is incorrectly treated as a null pointer constant in C++11 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77712 Bug ID: 77712 Summary: int() is incorrectly treated as a null pointer constant in C++11 and later Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- GCC accepts int *p = int(); even though per DR 903, only integer literals with the value zero are null pointer constants. This causes http://stackoverflow.com/q/39662995/2756719.
[Bug c/77690] -Wformat-length %s false positive after strlen check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690 Martin Sebor changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Martin Sebor --- Note that with snprintf GCC issues warning: ‘%s’ directive output may be truncated writing between 1 and 11 bytes into a region of size 5 This is also by design though I'm on the fence about warning at the same level or under the same option as for sprintf. FWIW, I wouldn't expect the parsing of the precision within the format string to have a noticeable performance impact on the overall cost of the call to the function. If you prefer to avoid it, you can specify via an argument to the '*': sprintf(foo, "zz%.*s", 4, s.buf); I'm changing the resolution of this bug to invalid since we haven't actually fixed anything, but if none of the solutions above is sufficient please feel free to reopen the bug and let us know what would be (keeping in mind that the ideal solution of tracking the actual string length or its range or determining it from the strlen call may not be feasible in the near term).
[Bug c++/77711] Add fix-it hints for missing parentheses in member function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77711
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-09-23
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
If the function is overloaded we get a different, equally unhelpful error:
struct A {
int foo();
int foo() const;
};
void bar(int);
int main()
{
A a;
bar( a.foo );
}
foo.cc: In function ‘int main()’:
foo.cc:11:14: error: cannot resolve overloaded function ‘foo’ based on
conversion to type ‘int’
bar( a.foo );
^
It's irrelevant that we can't resolve which overload to use, once name lookup
finds that 'foo' is a function then a.foo is not a valid expression under any
circumstances.
This should also suggest a.foo()
[Bug c/77690] -Wformat-length %s false positive after strlen check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690 nsz at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #5 from nsz at gcc dot gnu.org --- (In reply to Martin Sebor from comment #4) > Note that with snprintf GCC issues > > warning: ‘%s’ directive output may be truncated writing between 1 and 11 > bytes into a region of size 5 > > This is also by design though I'm on the fence about warning at the same > level or under the same option as for sprintf. > i opened another bug about snprintf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77708 i think warning for snprintf is almost surely a false positive, that is hard to suppress (and the suppression code is not idiomatic).
[Bug c++/77711] Add fix-it hints for missing parentheses in member function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77711
--- Comment #2 from Jonathan Wakely ---
And then if the function we're calling is a member function we get another
variation:
struct A {
int foo();
int foo() const;
void bar(int);
};
int main()
{
A a;
a.bar( a.foo );
}
foo.cc: In function ‘int main()’:
foo.cc:11:16: error: no matching function for call to ‘A::bar()’
a.bar( a.foo );
^
foo.cc:4:8: note: candidate: void A::bar(int)
void bar(int);
^~~
foo.cc:4:8: note: no known conversion for argument 1 from ‘’ to ‘int’
Again, we shouldn't even be trying to find a matching A::bar, because a.foo is
nonsense.
In all three examples we should notice that a.foo is invalid and give an error,
suggesting either a.foo() (to call it) or &A::foo (to form a pointer to the
member function).
[Bug c++/77712] int() is incorrectly treated as a null pointer constant in C++11 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77712 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-23 Ever confirmed|0 |1
[Bug tree-optimization/77654] restrict pointer attribute not preserved with -fprefetch-loop-arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77654 --- Comment #4 from mpf at gcc dot gnu.org --- Author: mpf Date: Fri Sep 23 15:48:01 2016 New Revision: 240439 URL: https://gcc.gnu.org/viewcvs?rev=240439&root=gcc&view=rev Log: Ensure points-to information is maintained for prefetch. gcc/ PR tree-optimization/77654 * tree-ssa-alias.c (issue_prefetch_ref): Add call to duplicate_ssa_name_ptr_info. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-prefetch.c
[Bug tree-optimization/77677] [7 Regression] ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77677
--- Comment #9 from Pat Haugen ---
(In reply to kugan from comment #8)
> Author: kugan
> Date: Fri Sep 23 10:25:09 2016
> New Revision: 240420
>
> URL: https://gcc.gnu.org/viewcvs?rev=240420&root=gcc&view=rev
> Log:
> Drop TREE_OVERFLOW
>
> gcc/ChangeLog:
>
> 2016-09-23 Kugan Vivekanandarajah
>
> PR ipa/77677
> * ipa-cp.c (propagate_vr_accross_jump_function): Drop TREE_OVERFLOW
> from constant while creating value range.
Unfortunately this does not fix the problem building 176.gcc on powerpc.
Following is reduced testcase. Failure occurs with 'gcc -O2'.
enum machine_mode { MAX_MACHINE_MODE };
struct {
int mode : 8
} a;
b;
static fn1();
fn2() { fn1(a, a.mode); }
fn1(x, mode) enum machine_mode mode;
{ int c = b = c; }
[Bug tree-optimization/77654] restrict pointer attribute not preserved with -fprefetch-loop-arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77654 mrs at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mrs at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from mrs at gcc dot gnu.org --- Fixed.
[Bug libstdc++/58938] std::exception_ptr is missing on architectures with incomplete atomic int support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 --- Comment #19 from Jonathan Wakely --- A prototype implementation that doesn't rely on atomics: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01526.html https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01546.html (both patches are needed).
[Bug middle-end/77708] -Wformat-length %s warns for snprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77708 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-23 CC||msebor at gcc dot gnu.org Component|c |middle-end Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- The warning is by design here but I will confirm the report as a request for change. I agree that, especially when the snprintf return value is used, warning at the default level may not be helpful. I'm not sure if a warning should be issued at a higher level, not at all, or under a separate option. I'd like to get the input from others before making a change. I'm not sure that suppressing the warning at level 1 when the snprintf return value isn't used is a good idea. Such calls typically assume that the output will not be truncated and subsequent code isn't prepared to handle it. I fixed a few such cases in GCC when testing the warning.
[Bug preprocessor/77672] wrong rich location in warning: writing a terminating nul past the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77672 --- Comment #6 from David Malcolm --- Author: dmalcolm Date: Fri Sep 23 16:55:27 2016 New Revision: 240442 URL: https://gcc.gnu.org/viewcvs?rev=240442&root=gcc&view=rev Log: Fix gcc.dg/tree-ssa/builtin-sprintf-warn-4.c gcc/testsuite/ChangeLog PR preprocessor/77672 * gcc.dg/tree-ssa/builtin-sprintf-warn-4.c (test): Update expected multiline output from first warning to reflect change in r240434. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c
[Bug middle-end/77713] New: gcc.dg/tree-ssa/builtin-sprintf.c compilation failed to produce executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77713 Bug ID: 77713 Summary: gcc.dg/tree-ssa/builtin-sprintf.c compilation failed to produce executable Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: arm-none-eabi Hi, gcc.dg/tree-ssa/builtin-sprintf.c fails to build on arm-none-eabi target with the following error: gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c: In function 'test_e_long_double':^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:423:16: warning: may write a terminating nul past the end of the destination [-Wformat-length=]^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:111:44: note: in definition of macro 'EQL'^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:111:11: note: format output between 13 and 14 bytes into a destination of size 13^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:423:3: note: in expansion of macro 'EQL'^M /tmp/ccCIniJQ.o: In function `test_e_long_double':^M builtin-sprintf.c:(.text+0x16fc): undefined reference to `failure_on_line_423'^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 output is: gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c: In function 'test_e_long_double':^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:423:16: warning: may write a terminating nul past the end of the destination [-Wformat-length=]^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:111:44: note: in definition of macro 'EQL'^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:111:11: note: format output between 13 and 14 bytes into a destination of size 13^M gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:423:3: note: in expansion of macro 'EQL'^M /tmp/ccCIniJQ.o: In function `test_e_long_double':^M builtin-sprintf.c:(.text+0x16fc): undefined reference to `failure_on_line_423'^M collect2: error: ld returned 1 exit status^M Please let me know of any other information you would need to reproduce this problem. Best regards.
[Bug libstdc++/77582] Improve std::string::clear performace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77582 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri Sep 23 17:25:34 2016 New Revision: 240447 URL: https://gcc.gnu.org/viewcvs?rev=240447&root=gcc&view=rev Log: Avoid reallocation for basic_string::clear() PR libstdc++/56166 PR libstdc++/77582 * include/bits/basic_string.h (basic_string::clear()): Drop reference and use empty rep. * include/ext/rc_string_base.h (__rc_string_base::_M_clear()): Likewise. * testsuite/21_strings/basic_string/56166.cc: New. * testsuite/ext/vstring/modifiers/clear/56166.cc: New. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string/56166.cc trunk/libstdc++-v3/testsuite/ext/vstring/modifiers/clear/ trunk/libstdc++-v3/testsuite/ext/vstring/modifiers/clear/56166.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/ext/rc_string_base.h
[Bug libstdc++/56166] std::string::clear() can throw despite being marked noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166 --- Comment #14 from Jonathan Wakely --- Author: redi Date: Fri Sep 23 17:25:34 2016 New Revision: 240447 URL: https://gcc.gnu.org/viewcvs?rev=240447&root=gcc&view=rev Log: Avoid reallocation for basic_string::clear() PR libstdc++/56166 PR libstdc++/77582 * include/bits/basic_string.h (basic_string::clear()): Drop reference and use empty rep. * include/ext/rc_string_base.h (__rc_string_base::_M_clear()): Likewise. * testsuite/21_strings/basic_string/56166.cc: New. * testsuite/ext/vstring/modifiers/clear/56166.cc: New. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string/56166.cc trunk/libstdc++-v3/testsuite/ext/vstring/modifiers/clear/ trunk/libstdc++-v3/testsuite/ext/vstring/modifiers/clear/56166.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/ext/rc_string_base.h
[Bug libstdc++/77582] Improve std::string::clear performace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77582 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > This would be fixed by the patch I wrote for PR 56166 Committed to trunk.
[Bug libstdc++/56166] std::string::clear() can throw despite being marked noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #15 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #12) > I think __gnu_cxx::__rc_string has the same problem > > There's a patch at https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00278.html I've committed that patch, so this is fixed for the COW strings too (except for the fully-dynamic string case, where it can still throw, but at least won't terminate now).
[Bug middle-end/77713] gcc.dg/tree-ssa/builtin-sprintf.c compilation failed to produce executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77713 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-09-23 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.0
[Bug rtl-optimization/77714] New: Wrong code generation for gcc.c-torture/execute/pr51447.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77714 Bug ID: 77714 Summary: Wrong code generation for gcc.c-torture/execute/pr51447.c Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: bergner at vnet dot ibm.com Target Milestone: --- Host: x86_64-linux-gnu Target: arm-none-eabi Hi, GCC started to generate wrong coed for gcc.c-torture/execute/pr51447.c from r240065 on arm-none-eabi Cortex-M0 targets (no problem on other Cortex-M targets). The problem is that the stack is no longer properly adjusted after jumping from bar to nonlocal_lab. Dumps are identical until reload. Before this commit, reload will do the adjustment of the stack in r7 and then pro_and_epilogue will add a mov sp, r7. After the commit, the stack is adjusted in ip but pro_and_epilogue still generates a mov sp, r7. Please find attached the assembly output before and after as well as the dumps for ira, reload and pro_and_epilogue. Best regards.
[Bug middle-end/77713] gcc.dg/tree-ssa/builtin-sprintf.c compilation failed to produce executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77713 --- Comment #1 from Martin Sebor --- Author: msebor Date: Fri Sep 23 17:55:29 2016 New Revision: 240450 URL: https://gcc.gnu.org/viewcvs?rev=240450&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: PR testsuite/77713 * gcc.dg/tree-ssa/builtin-sprintf.c (test_e_long_double): Avoid assuming long double is bigger than double. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
[Bug go/77701] suspicious code in go/go-gcc.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77701 --- Comment #2 from ian at gcc dot gnu.org --- Author: ian Date: Fri Sep 23 17:55:53 2016 New Revision: 240451 URL: https://gcc.gnu.org/viewcvs?rev=240451&root=gcc&view=rev Log: PR go/77701 * go-gcc.cc (Gcc_backend::Gcc_backend): Fix calls to integer_type to pass arguments in the correct order. Modified: trunk/gcc/go/ChangeLog trunk/gcc/go/go-gcc.cc
[Bug testsuite/77713] gcc.dg/tree-ssa/builtin-sprintf.c compilation failed to produce executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77713 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|middle-end |testsuite Resolution|--- |FIXED --- Comment #2 from Martin Sebor --- The test case has been fixed via r240450. Please reopen the bug if the failure persists.
[Bug fortran/77707] [5/6/7 Regression] formatted direct access: nextrec off by one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77707 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- I will look into this.
[Bug testsuite/77710] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77710 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Sebor --- I think this failure may have been inadvertently introduced in r240434. The failure should be gone now that r240442 has been checked in to adjust the test.
[Bug go/77715] New: go-system.h includes C++ header files before GCC system.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77715 Bug ID: 77715 Summary: go-system.h includes C++ header files before GCC system.h Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dje at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- go-system.h includes C++ headers before system.h to work-around poisoned declarations // These must be included before the #poison declarations in system.h. #include #include #include #include #include #include #if defined(HAVE_UNORDERED_MAP) # include # include // We don't really need iostream, but some versions of gmp.h include // it when compiled with C++, which means that we need to include it // before the macro magic of safe-ctype.h, which is included by // system.h. #include #include "system.h" GCC development specifies that "system.h" should be included first. Inclusion of C++ headers potentially pulls in OS system headers that cause conflicts or that adversely influence the behavior of system.h. This prevent the compilation of gofrontend on AIX due to PRIx64 and PRIu64 definition conflicts. The preferred solution is #define INCLUDE_MAP #define INCLUDE_SET #include "system.h" as used in auto-profile.c. go-system.h should arrange for system.h to include the necessary C++ header files.
[Bug middle-end/77709] specified destination size warning does not work when cross-compiling from 64 host to 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77709 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-09-23 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.0 --- Comment #1 from Martin Sebor --- Confirmed. This is a bug in the gimple-ssa-sprintf.c code. As you noted, dstsize will have the value of UINT_MAX on the target (or more precisely, SIZE_MAX on the target), which is less than HOST_WIDE_INT_MAX on the host. The code needs to use the value of (SIZE_MAX / 2) on the target for this test.
[Bug rtl-optimization/77714] Wrong code generation for gcc.c-torture/execute/pr51447.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77714 Peter Bergner changed: What|Removed |Added CC|bergner at vnet dot ibm.com|bergner at gcc dot gnu.org, ||edlinger at gcc dot gnu.org --- Comment #1 from Peter Bergner --- There was a follow on patch from Bernd (r240124) that fixed a problem on ARM. Do you have that in your tree? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289#c9
[Bug go/77701] suspicious code in go/go-gcc.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77701 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ian at airs dot com Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor --- Fixed. Thanks for noticing.
[Bug lto/77716] New: [7 regression] test case gcc.dg/debug/dwarf2/const-2.c fails starting with r240228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77716 Bug ID: 77716 Summary: [7 regression] test case gcc.dg/debug/dwarf2/const-2.c fails starting with r240228 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- This fails on powerpc64 both BE and LE. Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/debug/dwarf2/const-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O -gdwarf -dA -maltivec -ffat-lto-objects -S -o const-2.s(timeout = 300) spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/debug/dwarf2/const-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O -gdwarf -dA -maltivec -ffat-lto-objects -S -o const-2.s PASS: gcc.dg/debug/dwarf2/const-2.c (test for excess errors) FAIL: gcc.dg/debug/dwarf2/const-2.c scan-assembler DW_AT_const_value 16c16 < .4byte .LASF0 # DW_AT_producer: "GNU C11 7.0.0 20160919 (experimental) [trunk revision 240227] -Asystem=linux -Asystem=unix -Asystem=posix -maltivec -gdwarf -O -ffat-lto-objects" --- > .4byte .LASF0 # DW_AT_producer: "GNU C11 7.0.0 20160919 > (experimental) [trunk revision 240228] -Asystem=linux -Asystem=unix > -Asystem=posix -maltivec -gdwarf -O -ffat-lto-objects" 41,45d40 < .byte 0x10 # DW_AT_const_value < .4byte 0x4d6e6b28 # fp or vector constant word 0 < .4byte 0# fp or vector constant word 1 < .4byte 0# fp or vector constant word 2 < .4byte 0# fp or vector constant word 3 115,116d109 < .uleb128 0x1c# (DW_AT_const_value) < .uleb128 0xa # (DW_FORM_block1) This block is missing in the assembler output after the revision. Hmmm. Perhaps it is related to this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77692
[Bug libstdc++/77717] New: testsuite/21_strings/basic_string_view/operations/compare/char/1.cc makes undefined memcmp call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77717
Bug ID: 77717
Summary: testsuite/21_strings/basic_string_view/operations/comp
are/char/1.cc makes undefined memcmp call
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
CC: ville.voutilainen at gmail dot com
Target Milestone: ---
This test case makes an undefined call to memcmp because the string constant is
shorter than the length given. "costa rica" is 11 bytes including the '\0' but
length of 14 is given. The last two lines of code quoted below both do it.
int
test01()
{
using std::string_view;
string_view str_0("costa rica");
string_view str_1("costa marbella");
string_view str_2;
//sanity check
test_value(strcmp("costa marbella", "costa rica"), lt);
test_value(strcmp("costa rica", "costa rica"), z);
test_value(strcmp(str_1.data(), str_0.data()), lt);
test_value(strcmp(str_0.data(), str_1.data()), gt);
test_value(strncmp(str_1.data(), str_0.data(), 6), z);
test_value(strncmp(str_1.data(), str_0.data(), 14), lt);
test_value(memcmp(str_1.data(), str_0.data(), 6), z);
test_value(memcmp(str_1.data(), str_0.data(), 14), lt);
test_value(memcmp("costa marbella", "costa rica", 14), lt);
[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416 Bill Seurer changed: What|Removed |Added CC||seurer at linux dot vnet.ibm.com --- Comment #11 from Bill Seurer --- The new test case works on BE but fails on LE. Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr77416.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power7 -O2 -m32 -ffat-lto-objects -S -o pr77416.s(timeout = 300) spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr77416.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power7 -O2 -m32 -ffat-lto-objects -S -o pr77416.s cc1: error: -m32 not supported in this configuration compiler exited with status 1 output is: cc1: error: -m32 not supported in this configuration FAIL: gcc.target/powerpc/pr77416.c (test for excess errors) Excess errors: cc1: error: -m32 not supported in this configuration
[Bug target/77685] rs6000 target has builtin expansion for memcpy but not memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77685 --- Comment #1 from acsawdey at gcc dot gnu.org --- fixed in 240455: 2016-09-23 Aaron Sawdey * config/rs6000/rs6000.md (cmpmemsi): New define_expand. * config/rs6000/rs6000.c (expand_block_compare): New function used by cmpmemsi pattern to do builtin expansion of memcmp (). (compute_current_alignment): Add helper function for expand_block_compare used to compute alignment as the compare proceeds. (select_block_compare_mode): Used by expand_block_compare to select the mode used for reading the next chunk of bytes in the compare. (do_load_for_compare): Used by expand_block_compare to emit the load insns for the compare. (rs6000_emit_dot_insn): Moved this function to avoid a forward reference from expand_block_compare (). * config/rs6000/rs6000-protos.h (expand_block_compare): Add a prototype for this function. * config/rs6000/rs6000.opt (mblock-compare-inline-limit): Add a new target option for controlling how much code inline expansion of memcmp() will be allowed to generate.
[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 --- Comment #24 from Jerry DeLisle --- Author: jvdelisle Date: Fri Sep 23 20:36:21 2016 New Revision: 240456 URL: https://gcc.gnu.org/viewcvs?rev=240456&root=gcc&view=rev Log: 2016-09-23 Jerry DeLisle PR libgfortran/48298 * io/inquire.c (inquire_via_unit): Adjust error check for the two possible internal unit KINDs. * io/io.h: Adjust defines for is_internal_unit and is_char4_unit. (gfc_unit): Add internal unit data to structure. (get_internal_unit): Change declaration to set_internal_unit. (free_internal_unit): Change name to stash_internal_unit_number. (get_unique_unit_number): Adjust parameter argument. Define IOPARM_DT_HAS_UDTIO. (gfc_saved_unit): New structure. * io/list_read.c (next_char_internal): Use is_char4_unit. * io/open.c (st_open): Adjust call to get_unique_unit_number. * io/transfer.c (write_block): Use is_char4_unit. (data_transfer_init): Update check for unit numbers. (st_read_done): Free the various allocated memories used for the internal units and stash the negative unit number and pointer to unit structure to allow reuse. (st_write_done): Likewise stash the freed unit. * io/unit.c: Create a fixed size buffer of 16 gfc_saved_unit's to use as a stack to save newunit unit numbers and unit structure for reuse. (get_external_unit): Change name to get_gfc_unit to better reflect what it does. (find_unit): Change call to get_gfc_unit. (find_or_create_unit): Likewise. (get_internal_unit): Change name to set_internal_unit. Move internal unit from the dtp structure to the gfc_unit structure so that it can be passed to child I/O statements through the UNIT. (free_internal_unit): Change name to stash_internal_unit_number. Push the common.unit number onto the newunit stack, saving it for possible reuse later. (get_unit): Set the internal unit KIND. Use get_unique_unit_number to get a negative unit number for the internal unit. Use get_gfc_unit to get the unit structure and use set_internal_unit to initialize it. (init_units): Initialize the newunit stack. (get_unique_unit_number): Check the stack for an available unit number and use it. If none there get the next most negative number. (close_units): Free any unit structures pointed to from the save stack. 2016-09-23 Jerry DeLisle PR fortran/48298 * gfortran.h (gfc_dt): Add *udtio. * ioparm.def: Add bit IOPARM_dt_f2003 to align with library use of bit 25. Add IOPARM_dt_dtio bit to common flags. * resolve.c (resolve_transfer): Set dt->udtio to expression. * io.c (gfc_match_inquire): Adjust error message for internal unit KIND. * libgfortran.h: Adjust defines for GFC_INTERNAL_UNIT4, GFC_INTERNAL_UNIT, and GFC_INVALID_UNIT. * trans-io.c (build_dt): Set common_unit to reflect the KIND of the internal unit. Set mask bit for presence of dt->udtio. 2016-09-23 Jerry DeLisle PR fortran/48298 * gfortran.dg/negative_unit_check.f90: Update test. * gfortran.dg/dtio_14.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dtio_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/ioparm.def trunk/gcc/fortran/libgfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/negative_unit_check.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/inquire.c trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c
[Bug middle-end/77718] New: expand_builtin_memcmp swaps args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77718 Bug ID: 77718 Summary: expand_builtin_memcmp swaps args Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: acsawdey at gcc dot gnu.org CC: bernds at gcc dot gnu.org Target Milestone: --- Created attachment 39674 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39674&action=edit test case If you have a memcmp call that has const string args but one or both of them are shorter than the constant length given, the builtin expansion machinery will get called to expand the builtin, but the arguments given are reversed so the result is unexpected. The attached test will provoke this condition. In expand_buildin_memcmp () the following code is where this happens: by_pieces_constfn constfn = NULL; const char *src_str = c_getstr (arg1); if (src_str == NULL) src_str = c_getstr (arg2); else std::swap (arg1_rtx, arg2_rtx); /* If SRC is a string constant and block move would be done by pieces, we can avoid loading the string from memory and only stored the computed constants. */ if (src_str && CONST_INT_P (len_rtx) && (unsigned HOST_WIDE_INT) INTVAL (len_rtx) <= strlen (src_str) + 1) constfn = builtin_memcpy_read_str; rtx result = emit_block_cmp_hints (arg1_rtx, arg2_rtx, len_rtx, TREE_TYPE (len), target, result_eq, constfn, CONST_CAST (char *, src_str)); If you have arg1 a const str, then you get the swap of arg1_rtx and arg2_rtx. Normally this would be hidden because ccp folding earlier would have evaluated the memcmp to a const value since all args are const. However that folding does not happen when one/both of the strings are shorter than the given length since that is an undefined situation. Thus we come in here and get this swap but in this case result_eq won't be set. I think the solution might be to only do the swap when result_eq is set.
[Bug libstdc++/77717] testsuite/21_strings/basic_string_view/operations/compare/char/1.cc makes undefined memcmp call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77717 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-09-23 Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Ville Voutilainen --- Ah, Jonathan fixed the problem for std::experimental::string_view in r238609, we need to apply a similar fix to std::string_view's tests. I'll do that.
[Bug go/77688] [7 Regression] libgo bootstrap broken on mips*-linux-gnu and sparc*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77688 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ian Lance Taylor --- Should be fixed now.
[Bug tree-optimization/71109] [6 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71109 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #6 from Segher Boessenkool --- I wasn't aware of this bug. I'll have a look.
[Bug tree-optimization/71109] [6 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71109 --- Comment #7 from Segher Boessenkool --- It doesn't fail for me, 6.2.1 20160921 nor 7.0.0 20160914 (experimental).
[Bug lto/77716] [7 regression] test case gcc.dg/debug/dwarf2/const-2.c fails starting with r240228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77716 Andrew Pinski changed: What|Removed |Added Keywords||wrong-debug Target Milestone|--- |7.0
[Bug tree-optimization/77677] [7 Regression] ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77677
--- Comment #10 from kugan at gcc dot gnu.org ---
(In reply to Pat Haugen from comment #9)
> (In reply to kugan from comment #8)
> > Author: kugan
> > Date: Fri Sep 23 10:25:09 2016
> > New Revision: 240420
> >
> > URL: https://gcc.gnu.org/viewcvs?rev=240420&root=gcc&view=rev
> > Log:
> > Drop TREE_OVERFLOW
> >
> > gcc/ChangeLog:
> >
> > 2016-09-23 Kugan Vivekanandarajah
> >
> > PR ipa/77677
> > * ipa-cp.c (propagate_vr_accross_jump_function): Drop TREE_OVERFLOW
> > from constant while creating value range.
>
>
> Unfortunately this does not fix the problem building 176.gcc on powerpc.
> Following is reduced testcase. Failure occurs with 'gcc -O2'.
>
> enum machine_mode { MAX_MACHINE_MODE };
> struct {
> int mode : 8
> } a;
> b;
> static fn1();
> fn2() { fn1(a, a.mode); }
>
> fn1(x, mode) enum machine_mode mode;
> { int c = b = c; }
Sorry for the breakage. Posted a patch at
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01746.html for this.
[Bug c++/65866] Wrong warning when using list-initialization: operation on 'b' may be undefined [-Wsequence-point]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65866 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Target Milestone|6.3 |---
[Bug middle-end/65410] "Short local string array" optimization doesn't happen if string has NULs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65410 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
