[Bug tree-optimization/66772] ICE at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66772 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-06 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug tree-optimization/66772] [6 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66772 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 Summary|ICE at -O2 and -O3 on |[6 Regression] ICE at -O2 |x86_64-linux-gnu|and -O3 on x86_64-linux-gnu
[Bug libstdc++/66771] [5/6 Regression] -std=c++11 doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66771 --- Comment #5 from Richard Biener --- I think those are simply invalid uses of C++ (I've seen such instances in a few packages).
[Bug middle-end/66770] [6 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66770 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-06 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug tree-optimization/66733] [6 Regression] ICE at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66733 --- Comment #2 from Richard Biener --- *** Bug 66772 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/66772] [6 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66772 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener --- This is a duplicate of PR66733. *** This bug has been marked as a duplicate of bug 66733 ***
[Bug tree-optimization/66768] __seg_fs and __seg_gs: issue when adding address space support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768 Richard Biener changed: What|Removed |Added CC||amker.cheng at gmail dot com, ||rguenth at gcc dot gnu.org Component|c |tree-optimization --- Comment #3 from Richard Biener --- I can very well imagine that IVOPTs fails to preserve address-spaces here. Eventually it is also RTL expansion that in the end makes the issue surface. Not sure which existing targest with address-space support would share enough properties with the proposed patch to expose the same issue.
[Bug tree-optimization/66767] [6 regression] FAIL: gcc.dg/vect/vect-align-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66767 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-06 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine. Probably a similar issue to that I have already fixed (versioning checks?).
[Bug tree-optimization/66759] [6 Regression] ICE in generic-match.c on 456.hmmer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66759 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-06 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Mine.
[Bug ipa/66760] [4.9/5/6 Regression] compile time regression in IPA inline analysis on PR26854 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66760 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-06 CC||jamborm at gcc dot gnu.org Target Milestone|--- |4.9.4 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I've already questioned the compile-time cost of those at introduction time. It is limited by fbi->aa_walked but only if fbi is passed which it is not when called via ipa_load_from_parm_agg. Changing the interface to pass the counter separately and add one to inline_summary similar to the ones in func_body_info could fix this.
[Bug middle-end/66770] [6 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66770 --- Comment #2 from Richard Biener --- This looks like a dup of PR66759 to me which has a reduced testcase and shows a bug in folding of REAL_CST - x CMP REAL_CST.
[Bug c++/65974] Bogus deprecated-declarations warnings for inline definitions of deprecated virtual methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65974 Neil Bird changed: What|Removed |Added CC||neil at fnxweb dot com --- Comment #1 from Neil Bird --- I am also seeing this, although I don't have to put anything inline. When compiling C++, I get a warning flagged at the end of each class's .cpp for every member declared deprecated in the header, even if it's not used (the bodies for those routines being in the .cpp). # Scientific Linux 6.4, 32-bit $ gcc51 -v Using built-in specs. COLLECT_GCC=gcc51 COLLECT_LTO_WRAPPER=/opt/libexec/gcc/i686-pc-linux-gnu/5.1.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-5.1.0/configure --prefix=/opt --program-suffix=51 --enable-languages=c,c++ --with-isl=/opt Thread model: posix gcc version 5.1.0 (GCC)
[Bug tree-optimization/66768] __seg_fs and __seg_gs: issue when adding address space support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #4 from amker at gcc dot gnu.org --- I shall have a look. Thanks
[Bug debug/66714] ICE in loc_list_from_tree with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714
--- Comment #14 from vries at gcc dot gnu.org ---
1.
In lower_omp_target for function fn3, we handle clause 'map(alloc:bD.1833
[pointer assign, bias: 0])' with variable-sized bD.1833.
The var bD.1833 has value-expr *b.0D.1844. For b.0D.1844, we search the
associated decl with lookup_decl, and find b.0D.1854. We set the value-expr for
b.0D.1854 to '*.omp_data_iD.1851->b.0D.1870'.
Associated code:
...
if (DECL_SIZE (var)
&& TREE_CODE (DECL_SIZE (var)) != INTEGER_CST)
{
tree var2 = DECL_VALUE_EXPR (var);
gcc_assert (TREE_CODE (var2) == INDIRECT_REF);
var2 = TREE_OPERAND (var2, 0);
gcc_assert (DECL_P (var2));
var = var2;
}
if (!maybe_lookup_field (var, ctx))
continue;
if (offloaded)
{
x = build_receiver_ref (var, true, ctx);
tree new_var = lookup_decl (var, ctx);
if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_POINTER
&& !OMP_CLAUSE_MAP_ZERO_BIAS_ARRAY_SECTION (c)
&& TREE_CODE (TREE_TYPE (var)) == ARRAY_TYPE)
x = build_simple_mem_ref (x);
SET_DECL_VALUE_EXPR (new_var, x);
DECL_HAS_VALUE_EXPR_P (new_var) = 1;
}
...
2.
In replace_block_vars_by_duplicates, called from move_sese_region_to_fn, called
from expand_omp_target:
- we copy the value-expr *b.0D.1854 from bD.1855 to bD.1916, and
- we copy the value-expr *.omp_data_iD.1851->b.0D.1870 from b.0D.1854 to
b.0D.1917
Associated code:
...
t = *tp;
if (TREE_CODE (t) != VAR_DECL && TREE_CODE (t) != CONST_DECL)
continue;
replace_by_duplicate_decl (&t, vars_map, to_context);
if (t != *tp)
{
if (TREE_CODE (*tp) == VAR_DECL && DECL_HAS_VALUE_EXPR_P (*tp))
{
SET_DECL_VALUE_EXPR (t, DECL_VALUE_EXPR (*tp));
DECL_HAS_VALUE_EXPR_P (t) = 1;
}
DECL_CHAIN (t) = DECL_CHAIN (*tp);
*tp = t;
}
...
3.
In expand_omp_target for function fn3._omp_fn.0 we remove b.0D.1854 and bD.1855
from the local_decls, because the DECL_CONTEXT is fn3, rather than
fn3._omp_fn.0.
Associated code:
...
/* Remove non-local VAR_DECLs from child_cfun->local_decls list. */
num = vec_safe_length (child_cfun->local_decls);
for (srcidx = 0, dstidx = 0; srcidx < num; srcidx++)
{
t = (*child_cfun->local_decls)[srcidx];
if (DECL_CONTEXT (t) == cfun->decl)
continue;
if (srcidx != dstidx)
(*child_cfun->local_decls)[dstidx] = t;
dstidx++;
}
...
4.
Now that b.0D.1854 and bD.1855 are no longer declared in a function, they're no
longer live, and during garbage collection, we remove:
- cache entry (b.0D.1854, *.omp_data_iD.1851->b.0D.1870), and
- cache entry (bD.1855, *b.0D.1854)
from hash table value_expr_for_decl.
5.
During dwarf processing of fn3._omp_fn.0, we process a scope with decl bD.1916,
which has value-expr *b.0D.1854. When processing b.0D.1854 in
loc_list_from_tree, we run into the sigsegv because the value-expr for
b.0D.1854 is NULL (since the entry has been removed from the hash table).
Associated code:
...
/* FALLTHRU */
case PARM_DECL:
case RESULT_DECL:
if (DECL_HAS_VALUE_EXPR_P (loc))
return loc_list_from_tree (DECL_VALUE_EXPR (loc),
want_address, context);
...
[Bug debug/66714] ICE in loc_list_from_tree with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714 --- Comment #15 from vries at gcc dot gnu.org --- My guess at this point is that the problem is that in replace_block_vars_by_duplicates, we replace the old decls in the block with new decls, but that the value-exprs that we copy from the old to the new decls still contain the old decls.
[Bug libgomp/66714] ICE in loc_list_from_tree with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714 vries at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|debug |libgomp --- Comment #16 from vries at gcc dot gnu.org --- Moving component from debug to libgomp. The assert is with -g, but the code copying untranslated value-exprs is always active, not just with -g.
[Bug libstdc++/66771] [5/6 Regression] -std=c++11 doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66771 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Jonathan Wakely --- (In reply to H.J. Lu from comment #3) > if (m_input.getline(buf, sizeof(buf)) == 0) > return false; This is not valid in C++11, and was poor style even in C++03. The portable way to write it is: if (m_input.getline(buf, sizeof(buf))) return false;
[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 edanor1 at wp dot pl changed: What|Removed |Added CC||edanor1 at wp dot pl --- Comment #19 from edanor1 at wp dot pl --- Hi everyone, I just got a similar output on GCC 5.1.0. I think it might be related, however this appears to be for different syntax. Flags are: "-mavx -std=c++11 -Wfatal-errors -O0" Please let me know if you still need a test case. .../BOOST/boost_1_57_0/boost/type_traits/remove_reference.hpp:42:1: note: in expansion of macro ‘BOOST_TT_AUX_TYPE_TRAIT_PARTIAL_SPEC1_1’ BOOST_TT_AUX_TYPE_TRAIT_PARTIAL_SPEC1_1(typename T,remove_reference,T&,T) ^ 0x6ef1fc finish_member_declaration(tree_node*) ../../gcc/cp/semantics.c:2872 0x66af2d instantiate_class_template_1 ../../gcc/cp/pt.c:9487 0x66af2d instantiate_class_template(tree_node*) ../../gcc/cp/pt.c:9688 0x6c5bed complete_type(tree_node*) ../../gcc/cp/typeck.c:146 0x653e5f tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:12441 0x65e759 tsubst_template_args ../../gcc/cp/pt.c:10257 0x65ec84 tsubst_aggr_type ../../gcc/cp/pt.c:10454 0x653891 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11909 0x66b909 instantiate_class_template_1 ../../gcc/cp/pt.c:9275 0x66b909 instantiate_class_template(tree_node*) ../../gcc/cp/pt.c:9688 0x6c5bed complete_type(tree_node*) ../../gcc/cp/typeck.c:146 0x653e5f tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:12441 0x6519e1 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:14654 0x6514e5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:15066 0x653320 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:12530 0x660c02 tsubst_decl ../../gcc/cp/pt.c:11339 0x653c54 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11830 0x66aed2 instantiate_class_template_1 ../../gcc/cp/pt.c:9424 0x66aed2 instantiate_class_template(tree_node*) ../../gcc/cp/pt.c:9688 0x6c5bed complete_type(tree_node*) ../../gcc/cp/typeck.c:146
[Bug libstdc++/66771] [5/6 Regression] -std=c++11 doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66771 --- Comment #7 from Jonathan Wakely --- Oops sorry, I mean: if (!m_input.getline(buf, sizeof(buf))) return false; The version comparing to 0 only works in C++03 (or non-conforming versions of libstdc++ pre-gcc-5) because testing a stream's state is done via implicit conversion to void*. In C++11 it is done via explicit conversion to bool, which is triggered by an explicit cast to bool, or a use in a conditional statement, or by negating it with !
[Bug libfortran/40267] Eventually get rid of libgfortranbegin.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40267 --- Comment #2 from Francois-Xavier Coudert --- Author: fxcoudert Date: Mon Jul 6 08:22:34 2015 New Revision: 225445 URL: https://gcc.gnu.org/viewcvs?rev=225445&root=gcc&view=rev Log: PR libfortran/40267 * Makefile.am: Remove libgfortranbegin targets. * Makefile.in: Regenerate. * fmain.c: Remove. Removed: trunk/libgfortran/fmain.c Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in
[Bug libfortran/40267] Eventually get rid of libgfortranbegin.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40267 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Francois-Xavier Coudert --- Fixed on trunk, will not be backported.
[Bug target/66749] [4.9/5/6] gcc.target/i386/addr-sel-1.c fails to merge array index into one instruction with -m32 -mregparm=3 or with -miamcu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66749 --- Comment #5 from Yulia Koval --- (In reply to H.J. Lu from comment #4) > Created attachment 35904 [details] > A patch > > Please try this. It fixes the problem.
[Bug tree-optimization/66757] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66757 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Mon Jul 6 08:43:58 2015 New Revision: 225446 URL: https://gcc.gnu.org/viewcvs?rev=225446&root=gcc&view=rev Log: PR tree-optimization/66757 * match.pd: Add missing condition to ~X ^ C -> X ^ ~C. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr66757.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug c/66773] New: sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
Bug ID: 66773
Summary: sign-compare warning for == and != are pretty useless
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.marjamaki at gmail dot com
Target Milestone: ---
I wrote a clang bug report:
https://llvm.org/bugs/show_bug.cgi?id=24036
I recommend that -Wsign-compare is not written for == and != comparisons.
For relational comparisons the sign makes a direct difference, the result of 'a
> b' can be different if you do a sign-cast of an operand.
For equality comparisons the sign does not make a direct difference. the result
of 'a == b' is the same even if you sign-cast an operand.
Code example:
void f(signed int a, unsigned int b) {
if (a == b) {}
}
gcc writes this warning:
signcompare.c:3:19: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
In my humble opinion the risk of a real bug here is really low. a has to be
negative. b has to be really large (unlikely). the bitpatterns of a and b has
to match. if the bitpatterns do match it might actually be the intention that
the test should succeed. but if that is not intentional then there is a bug.
The proper fix for this is to write:
if (a >= 0 && a == b) {}
However I have seen that this is fixed wrongly by a useless cast.
This kind of false positive is indirectly a security problem. People routinely
hide these false positives using casts or changed variable types etc. and that
cause bugs and hides other real warnings.
In my humble opinion the risk of a bug here is really low.
The proper fix for this is to write:
if (a >= 0 && a == b) {}
However I have seen that this is fixed by a useless cast.
This kind of false positive is indirectly a security problem. People routinely
hide these false positives using casts or changed variable types etc. and that
cause bugs and hides other real warnings.
[Bug tree-optimization/66757] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66757 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Botcazou --- Thanks for reporting the problem.
[Bug c++/66774] New: Any optimization causes segfault on binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66774 Bug ID: 66774 Summary: Any optimization causes segfault on binary Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: contact at tobast dot fr Target Milestone: --- Created attachment 35916 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35916&action=edit Source code that fails when optimized, .ii file. Hello, When I run the binary produced by compiling the attached code (which *waits for two integers on its stdin before actually running*, eg. 2000 10) is executed, it results in a segfault when any optimization level is enabled (tested with -O1, -O2, -O3), while it's fine with -O0. As the bug does not occur with -O0 I assume the bug is part of gcc, and not of my own code, but I could obviously be wrong. Apparently, when compiled with both -O2 and -g, then ran through gdb, the segfault comes from the "push" line 12620 of the .ii file, but only after a few pushes happened (?!). The exact command line used for compilation is: $ g++ -Wall -Wextra -O[opt level] [optionnaly -g] code.cpp No warning is raised. My machine runs Archlinux, kernel 4.0.7-2-ARCH, I use the default gcc package from this distribution, and $ g++ -v gives Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-5-20150623/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --with-default-libstdcxx-abi=c++98 Thread model: posix gcc version 5.1.0 (GCC) --- Attached: - code.ii Thank you for all your work.
[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
Daniel Marjamäki changed:
What|Removed |Added
CC||daniel.marjamaki at gmail dot
com
--- Comment #7 from Daniel Marjamäki ---
+1
This is very annoying.
My code is:
unsigned int dostuff();
void f(int x) {
if (x >= 0 && x < dostuff()) {}
}
This kind of false positive is indirectly a security problem. People routinely
hide these false positives using casts or changed variable types etc. and that
cause bugs and hides other real warnings.
I'd vote for either removing this warning or fixing it.
[Bug c++/66774] Any optimization causes segfault on binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66774 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- In cases like this please build your code with -fsanitize=undefined. code.cpp:58:39: runtime error: index 4 out of bounds for type 'int [4][2]' code.cpp:58:42: runtime error: load of address 0x00410b00 with insufficient space for an object of type 'const int' 0x00410b00: note: pointer points here 01 00 00 00 ff ff 01 10 5f 05 a8 05 00 ab 05 05 00 00 b0 05 05 a8 05 00 ff ff 01 11 b1 01 05 00 ^ code.cpp:59:39: runtime error: index 4 out of bounds for type 'int [4][2]' code.cpp:59:42: runtime error: load of address 0x00410b04 with insufficient space for an object of type 'const int' 0x00410b04: note: pointer points here ff ff 01 10 5f 05 a8 05 00 ab 05 05 00 00 b0 05 05 a8 05 00 ff ff 01 11 b1 01 05 00 00 f8 07 cc
[Bug fortran/66775] New: Allocatable function result type(t) produces segfault when uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66775
Bug ID: 66775
Summary: Allocatable function result type(t) produces segfault
when uninitialized
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vehre at gcc dot gnu.org
Target Milestone: ---
Created attachment 35917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35917&action=edit
Full pseudo code of failing example.
The following code produces a segfault:
! { dg-do run }
module test_alloc_func_mod
implicit none
type t
integer :: i = 5
end type
contains
type(t) function t_init() ! { dg-warning "not set" }
allocatable :: t_init
end function
end module test_alloc_func_mod
program test_alloc_func
use test_alloc_func_mod
type(t), allocatable :: temp
temp = t_init() ! <-- This derefs a null-pointer currently
if (allocated (temp)) call abort()
end program
The pseudo code in question is:
t_init ()
{
struct t * __result_t_init;
__result_t_init = 0B;// Setting NULL-pointer.
return __result_t_init;
}
for t_init, and reduced to the essential line (full pseudo code is attached)
struct t * temp;
struct t * D.3388;
temp = (struct t *) __builtin_malloc (4);
D.3388 = t_init ();
*temp = *D.3388; // D.3388 is NULL; dereferencing it here is hazardous.
This error was experienced during patching of pr58586.
[Bug libgomp/66714] ICE in loc_list_from_tree with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714 --- Comment #17 from vries at gcc dot gnu.org --- Created attachment 35918 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35918&action=edit update gzipped trace latest trace
[Bug libgomp/66714] ICE in loc_list_from_tree with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714 --- Comment #18 from vries at gcc dot gnu.org --- Created attachment 35919 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35919&action=edit combined testcase/trigger/tracing patch
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 nsz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||nsz at gcc dot gnu.org Resolution|--- |FIXED --- Comment #15 from nsz at gcc dot gnu.org --- fixed in trunk in r224031 and backported to branch 5 in r225170.
[Bug fortran/58586] ICE with derived type with allocatable component passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58586 --- Comment #8 from vehre at gcc dot gnu.org --- Author: vehre Date: Mon Jul 6 10:26:12 2015 New Revision: 225447 URL: https://gcc.gnu.org/viewcvs?rev=225447&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2015-07-06 Andre Vehreschild PR fortran/58586 * gfortran.dg/alloc_comp_class_3.f03: New test. * gfortran.dg/alloc_comp_class_4.f03: New test. gcc/fortran/ChangeLog: 2015-07-06 Andre Vehreschild PR fortran/58586 * resolve.c (resolve_symbol): Non-private functions in modules with allocatable or pointer components are marked referenced now. Furthermore is the default init especially for those components now done in gfc_conf_procedure_call preventing duplicate code. * trans-decl.c (gfc_generate_function_code): Generate a fake result decl for functions returning an object with allocatable components and initialize them. * trans-expr.c (gfc_conv_procedure_call): For value typed trees use the tree without indirect ref. And for non-decl trees add a temporary variable to prevent evaluating the tree multiple times (prevent multiple function evaluations). * trans.h: Made gfc_trans_structure_assign () protoype available, which is now needed by trans-decl.c:gfc_generate_ function_code(), too. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_3.f03 trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h
[Bug target/66776] New: [AArch64] zero-extend version of csel not matching properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66776
Bug ID: 66776
Summary: [AArch64] zero-extend version of csel not matching
properly
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Consider the code:
unsigned long
foo (unsigned int a, unsigned int b, unsigned int c)
{
return a ? b : c;
}
On aarch64 this generates:
foo:
uxtwx1, w1
cmp w0, wzr
uxtwx2, w2
cselx0, x2, x1, eq
ret
where in fact it could generate:
cmp w0, #0
cselw0, w1, w2, ne
ret
A write to the 32-bit w-register implicitly zero-extends the value up to the
full
64 bits of an x-register.
This is reflected in aarch64.md by the cmovsi_insn_uxtw pattern that matches:
(set (dest:DI)
(zero_extend:DI
(if_then_else:SI (cond) (src1:SI) (src2:SI))
)
)
However, this doesn't get matched because combine instead tries to match
(set (dest:DI)
(if_then_else:DI (cond)
(zero_extend:DI (src1:SI))
(zero_extend:DI (src2:SI))
)
)
As discussed in PR66588 it seems preferable to write the *cmovsi_insn_uxtw
pattern with the zero_extends inside the arms of the if_then_else
[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #4) > combine should not in general try multiple ways to write the same > thing; this will not scale. In this case, I don't see that some > backends would really like to write it one way and some the other, > so we should just use one way. > > There are no defined canonicalization rules for this, but there > are for the similar cases involving MULT, where the extends are > moved inwards as well. This is most in line with how other extends > are treated as well. > > We probably should document the canonicalization rules better; > current practice for backends is to just look at what combine does > and use that; not a great idea in my opinion. Ok, thanks. I've opened PR 66776 for the aarch64 MD changes. Would you like to keep this open to track any documentation changes? Or shall we close this off?
[Bug target/66776] [AArch64] zero-extend version of csel not matching properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66776 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||aarch64* Target Milestone|--- |6.0 Known to fail||6.0
[Bug tree-optimization/66759] [6 Regression] ICE in generic-match.c on 456.hmmer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66759 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Jul 6 10:37:33 2015 New Revision: 225449 URL: https://gcc.gnu.org/viewcvs?rev=225449&root=gcc&view=rev Log: 2015-07-06 Richard Biener PR middle-end/66759 * match.pd: Add missing constraint of y to REAL_CST in REAL_CST - x CMP y to y - CST CMP x simplification. * gcc.dg/torture/pr66759.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr66759.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #1 from nsz at gcc dot gnu.org --- Author: nsz Date: Mon Jul 6 11:00:03 2015 New Revision: 225450 URL: https://gcc.gnu.org/viewcvs?rev=225450&root=gcc&view=rev Log: [AArch64] PR target/66731 Fix fnmul insn with -frounding-math gcc/Changelog: 2015-07-03 Szabolcs Nagy PR target/66731 * config/aarch64/aarch64.md (fnmul3): Handle -frounding-math. gcc/testsuite/Changelog: 2015-07-03 Szabolcs Nagy * gcc.target/aarch64/fnmul-1.c: New. * gcc.target/aarch64/fnmul-2.c: New. * gcc.target/aarch64/fnmul-3.c: New. * gcc.target/aarch64/fnmul-4.c: New. Added: trunk/gcc/testsuite/gcc.target/aarch64/fnmul-1.c trunk/gcc/testsuite/gcc.target/aarch64/fnmul-2.c trunk/gcc/testsuite/gcc.target/aarch64/fnmul-3.c trunk/gcc/testsuite/gcc.target/aarch64/fnmul-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md trunk/gcc/testsuite/ChangeLog
[Bug c++/66774] Any optimization causes segfault on binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66774 --- Comment #2 from Jonathan Wakely --- (In reply to contact from comment #0) > As the bug does not > occur with -O0 I assume the bug is part of gcc, and not of my own code, but > I could obviously be wrong. This is a completely invalid assumption. Many, many bugs appear harmless without optimisations, because "the code appears to work correctly" is just one possible outcome of undefined behaviour, but enabling optimisation can cause a different outcome with more obvious symptoms.
[Bug c/66777] New: faggressive-loop-optimizations behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66777
Bug ID: 66777
Summary: faggressive-loop-optimizations behavior.
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dongkyun.s at samsung dot com
Target Milestone: ---
The following program seems to have optimized with -O2
(-faggressive-loop-optimizations).
#include
int main(void)
{
int a[5];
int i;
for (i = 0; a[i] && i < 5; i++)
printf("%d\n", a[i]);
return 0;
}
1) .s with -O2 option (-faggressive-loop-optimizations)
...
.L4
r02 mo3w r0, #:lower16:.LC0
movtr0, #:upper16:.LC0
bl printf
ldr r1, [r4, #4]!
cmp r1, #0 // a[i]
bne .L4
...
2) .s without -On option (-fno-aggressive-loop-optimizations)
...
.L4
...
ldr r2, [fp, #-8]
mvn r3, #23
mov r2, r2, asl #2
sub r1, fp, #4
add r2, r2, r1
add r3, r2, r3
ldr r3, [r3, #0]
cmp r3, #0 // a[i]
beq .L3
ldr r3, [fp, #-8]
cmp r3, #4 // i < 5
ble .L4
.L3
...
< -faggressive-loop-optimizations >
This assumes that loop code does not invoke undefined behavior by for example
causing signed integer overflows or out-of-bound array accesses. The bounds for
the number of iterations of a loop are used to guide loop unrolling and peeling
and loop exit test optimizations. This option is enabled by default.
The problem with 1) option (-faggressive-loop-optimizations) is that the
developer cannot recognize the program have bug which can cause NULL pointer
exception.
Is there some warning option releated to this optimization ?
[Bug tree-optimization/66733] [6 Regression] ICE at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66733 --- Comment #3 from Richard Biener --- Ok, it's actually slightly more twisted (but indeed related to CCP propagating copies now).
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 --- Comment #9 from Tobias Burnus --- Jason, any news on this: (In reply to Jan Hubicka from comment #8) > Jaon, the issue here is that TYPE_CANONICAL is incomplete type: [...] > Shouldn't the canonical type be always the complete variant of the type?
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 --- Comment #23 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Jul 6 11:50:47 2015 New Revision: 225452 URL: https://gcc.gnu.org/viewcvs?rev=225452&root=gcc&view=rev Log: Allow -mincoming-stack-boundary=3 with -mno-sse Similar to -mpreferred-stack-boundary=3, -mincoming-stack-boundary=3 is allowed with -mno-sse in 64-bit mode. gcc/ PR target/53383 * config/i386/i386.c (ix86_option_override_internal): Allow -mincoming-stack-boundary=3 for 64-bit if SSE is disabled. gcc/testsuite/ PR target/53383 * gcc.target/i386/pr53383-1.c: New file. * gcc.target/i386/pr53383-2.c: Likewise. * gcc.target/i386/pr53383-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr53383-1.c trunk/gcc/testsuite/gcc.target/i386/pr53383-2.c trunk/gcc/testsuite/gcc.target/i386/pr53383-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66769] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66769
--- Comment #3 from fiesh at zefix dot tv ---
Better, self contained problem case:
class A
{
void f(int a);
int g();
};
void A::f(int a) {}
int A::g()
{
auto r = [&] (auto x) { f(*x); };
int * p;
r(p);
}
[Bug c/66777] faggressive-loop-optimizations behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66777 --- Comment #1 from Richard Biener --- -Waggressive-loop-optimizations, but it doesn't warn for me in this case. Of course we warn about t.c: In function ‘main’: t.c:8:26: warning: ‘a[0]’ is used uninitialized in this function [-Wuninitialized] for (i = 0; a[i] && i < 5; i++) ^
[Bug tree-optimization/66759] [6 Regression] ICE in generic-match.c on 456.hmmer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66759 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug c++/66769] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66769 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Markus Trippelsdorf --- dup. (see PR61636 comment5) *** This bug has been marked as a duplicate of bug 61636 ***
[Bug c++/61636] generic lambda "cannot call member function without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61636 Markus Trippelsdorf changed: What|Removed |Added CC||fiesh at zefix dot tv --- Comment #13 from Markus Trippelsdorf --- *** Bug 66769 has been marked as a duplicate of this bug. ***
[Bug ipa/61820] 32-bit g++.dg/ipa/pr61160-3.C execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61820 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Richard PALO --- > I have this as well on SunOS 5.11 illumos with 4.9* (on pkgsrc) Right, the bug is still present on the 4.9 branch (only). It was fixed on mainline between r212903 and r212922, obviously by this patch (r212915) 2014-07-22 Martin Jambor PR ipa/61160 * g++.dg/ipa/pr61160-3.C (main): Return zero. Rainer
[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591 --- Comment #8 from Manuel López-Ibáñez --- > I'd vote for either removing this warning or fixing it. You can use the corresponding -Wno-* option to remove it. There's no much point in voting on this or other bugs: What is needed is someone brave enough to tackle the problem and figure out how to solve it in a way that is accepted by the maintainers. https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps Comment #6 is as relevant today as it was 6 years ago. But perhaps simple cases can be detected without any CCP or VRP in the FE. Someone needs to figure it out.
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 --- Comment #13 from Bernd Schmidt --- Author: bernds Date: Mon Jul 6 12:49:26 2015 New Revision: 225453 URL: https://gcc.gnu.org/viewcvs?rev=225453&root=gcc&view=rev Log: Fix assert caused by bad cfg manipulation in bfin. PR target/66620 * config/bfin/bfin.c (hwloop_optimize): Create new bb between jump and loop start when inserting LSETUP. Modified: trunk/gcc/ChangeLog trunk/gcc/config/bfin/bfin.c
[Bug tree-optimization/66767] [6 regression] FAIL: gcc.dg/vect/vect-align-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66767
--- Comment #2 from Richard Biener ---
Indeed.
:
# PT = { D.2299 } (nonlocal)
# ALIGN = 16, MISALIGN = 0
vectp_p.4_16 = p_7(D) + 1;
addr2int0_4 = (signed long) vectp_p.4_16;
andmask_3 = addr2int0_4 & 15;
if (andmask_3 == 0)
[Bug tree-optimization/66767] [6 regression] FAIL: gcc.dg/vect/vect-align-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66767 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Jul 6 13:12:39 2015 New Revision: 225454 URL: https://gcc.gnu.org/viewcvs?rev=225454&root=gcc&view=rev Log: 2015-07-06 Richard Biener PR tree-optimization/66767 * tree-vect-loop-manip.c (vect_create_cond_for_align_checks): Make sure to build the alignment test on a SSA name without final alignment info valid only if the alignment test evaluates to true. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug tree-optimization/66767] [6 regression] FAIL: gcc.dg/vect/vect-align-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66767 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug target/66778] New: [6.0 Regression] PPC 405 and 440 nmac failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66778 Bug ID: 66778 Summary: [6.0 Regression] PPC 405 and 440 nmac failure Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- A number of PPC 405 and PPC440 target-specific nmac instruction tests began failing on 1 July 2015. FAIL: gcc.target/powerpc/405-nmacchw-2.c scan-assembler nmacchw. FAIL: gcc.target/powerpc/405-nmachhw-2.c scan-assembler nmachhw. FAIL: gcc.target/powerpc/405-nmaclhw-2.c scan-assembler nmaclhw. FAIL: gcc.target/powerpc/440-nmacchw-2.c scan-assembler nmacchw. FAIL: gcc.target/powerpc/440-nmachhw-2.c scan-assembler nmachhw. FAIL: gcc.target/powerpc/440-nmaclhw-2.c scan-assembler nmaclhw. Compiler version: 6.0.0 20150701 (experimental) [trunk revision 225249] (GCC)
[Bug tree-optimization/66739] [6 regression] FAIL: gcc.target/aarch64/subs.c scan-assembler subs\tw[0-9]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66739 Andreas Schwab changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #5 from Andreas Schwab --- *** Bug 66778 has been marked as a duplicate of this bug. ***
[Bug target/66778] [6.0 Regression] PPC 405 and 440 nmac failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66778 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab --- . *** This bug has been marked as a duplicate of bug 66739 ***
[Bug jit/66779] New: jit segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66779 Bug ID: 66779 Summary: jit segfault Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Blocks: 66627 Target Milestone: --- This bug is to track the segfault during jit-compilation reported here: https://gcc.gnu.org/ml/jit/2015-q3/msg00018.html I'm able to reproduce it locally on x86_64 with trunk using the reproducer attached to that mail. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627 [Bug 66627] Tracker bug for jit bugs affecting ravi
[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Andrew Macleod --- I do not believe the lock is needed. See https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html GCC will emit the fence on all stores which then synchronize with loads. If we did emit a fence on the loads, then we wouldn't need the fence on stores. It is likely there will be more loads than stores, so the current approach is usually more efficient.
[Bug tree-optimization/66739] [6 regression] FAIL: gcc.target/aarch64/subs.c scan-assembler subs\tw[0-9]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66739
--- Comment #6 from Richard Biener ---
The ppc testcase,
int
f(int a, int b, int c)
{
a -= (short)b * (c >> 16);
if (!a)
return 10;
return a;
}
is probably artificially triggering the same issue. Here we do not
test for conditional part but for an instruction used implementing
a -= (short)b * (c >> 16);
But it shows the same issue with the followup transform of sinking the
subtraction to the else path of the if.
I suppose a single-use test is the way to go together with some means to
"override" that when the caller is not going to create the result stmts
but will only perform lookups if the result is already computed (that applies
to all single-use tests).
[Bug tree-optimization/66772] [6 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66772 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Jul 6 14:41:22 2015 New Revision: 225459 URL: https://gcc.gnu.org/viewcvs?rev=225459&root=gcc&view=rev Log: 2015-07-06 Richard Biener PR tree-optimization/66772 * tree-ssa-ccp.c (ccp_visit_phi_node): Make sure that copy values are available in the PHI node BB when there are still unexecutable edges. * gcc.dg/torture/pr66772-1.c: New testcase. * gcc.dg/torture/pr66772-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr66733-1.c trunk/gcc/testsuite/gcc.dg/torture/pr66733-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug tree-optimization/66739] [6 regression] FAIL: gcc.target/aarch64/subs.c scan-assembler subs\tw[0-9]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66739 --- Comment #7 from Richard Biener --- I am testing Index: gcc/match.pd === --- gcc/match.pd(revision 225453) +++ gcc/match.pd(working copy) @@ -1336,8 +1353,9 @@ (define_operator_list CBRT BUILT_IN_CBRT attempts to synthetize ABS_EXPR. */ (for cmp (eq ne) (simplify - (cmp (minus @0 @1) integer_zerop) - (cmp @0 @1))) + (cmp (minus@2 @0 @1) integer_zerop) + (if (single_use (@2)) + (cmp @0 @1 /* Transform comparisons of the form X * C1 CMP 0 to X CMP 0 in the signed arithmetic case. That form is created by the compiler
[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767 --- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz --- The problem here is that we don't really know what does the standard specify. People often suggest the Batty's paper Mathematizing C++ Concurrency ( http://www.cl.cam.ac.uk/~pes20/cpp/popl085ap-sewell.pdf ) as the explanation, but the paper really describes a different memory model than the C++ standard (citing section 4: "Unfortunately N3092 allows the following nonsequentially consistent execution of the SB example with SC atomics (initialisation writes, such as (a) and (b), are non-atomic so that they need not be compiled with memory fences): - We devised a stronger restriction on the values that may be read by SC atomics, stated in §2.7, that does provide sequential consistency here." - so it doesn't describe the standard, but something stronger that authors have "devised") You can look at this example https://gcc.gnu.org/ml/gcc/2014-02/msg00053.html . The assert can fail - so it implies that __ATOMIC_SEQ_CST is not a full barrier, it is somehow weaker. But how much weaker is it? Who knows? I look at https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html and I would really like to know "why is it so?" "Where does the standard specify this mapping?" I couldn't really find an answer for that.
[Bug target/66749] [4.9/5/6] gcc.target/i386/addr-sel-1.c fails to merge array index into one instruction with -m32 -mregparm=3 or with -miamcu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66749 --- Comment #6 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Jul 6 15:17:44 2015 New Revision: 225460 URL: https://gcc.gnu.org/viewcvs?rev=225460&root=gcc&view=rev Log: Add -march=iamcu to optimize for IA MCU IA MCU is based on Intel Pentium ISA without x87 and passing parameters in registers. We want to optimize for IA MCU without changing existing Pentium codegen. This patch adds PROCESSOR_IAMCU for -march=iamcu, which is based on -march=pentium with updated cost tables. gcc/ PR target/66749 * config/i386/i386.c (iamcu_cost): New. (m_IAMCU): Likewise. (initial_ix86_arch_features): Disable X86_ARCH_CMOV for m_IAMCU. (processor_target_table): Add an entry for "iamcu". (processor_alias_table): Likewise. (ix86_issue_rate): Handle PROCESSOR_IAMCU. (ix86_adjust_cost): Likewise. (ia32_multipass_dfa_lookahead): Likewise. * config/i386/i386.h (processor_type): Add PROCESSOR_IAMCU. * config/i386/x86-tune.def: Updated for m_IAMCU. gcc/testsuite/ PR target/66749 * gcc.target/i386/pr66749.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr66749.c Modified: trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/x86-tune.def
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 Ramana Radhakrishnan changed: What|Removed |Added Target Milestone|--- |5.2 --- Comment #16 from Ramana Radhakrishnan --- Fixed for 5.2 I believe.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #48 from John Paul Adrian Glaubitz --- Alright, I found it, -fstack-protector-strong is the culprit. Will file a new bug report now. Adrian
[Bug target/66780] New: [4.9 Regression] Compiling with -fstack-protector-strong causes binary to segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66780 Bug ID: 66780 Summary: [4.9 Regression] Compiling with -fstack-protector-strong causes binary to segfault Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org Target Milestone: --- Target: sh*-*-* Hello! After several days of debugging, I finally found out why many packages build on the Debian sh4 buildds currently segfault on sh4, it's the CFLAG -fstack-protector-strong which is the culprit. To reproduce: $ wget http://http.debian.net/debian/pool/main/p/procps/procps_3.3.10.orig.tar.xz $ tar xf procps_3.3.10.orig.tar.xz $ cd procps-3.3.10 $ export CFLAGS="-g -fstack-protector-strong -Wformat -Werror=format-security" ; export "CXXFLAGS=-g -fstack-protector-strong -Wformat -Werror=format-security" ; ./configure ; make $ ./ps/pscommand Signal 11 (SEGV) caught by lt-pscommand (procps-ng version 3.3.10). /root/procps/procps-3.3.10/ps/.libs/lt-pscommand:display.c:66: please report this bug Segmentation fault $ make clean $ export CFLAGS="-g -Wformat -Werror=format-security" ; export "CXXFLAGS=-g -Wformat -Werror=format-security" ; ./configure ; make $ ./ps/pscommand PID TTY TIME CMD 5396 pts/000:00:00 lt-pscommand 32356 pts/000:00:00 bash $ This bug affects many packages in the Debian sh4 port, for example: pcre3: http://buildd.debian-ports.org/status/fetch.php?pkg=pcre3&arch=sh4&ver=2%3A8.35-7&stamp=1436092677 cups: http://buildd.debian-ports.org/status/fetch.php?pkg=cups&arch=sh4&ver=1.7.5-12&stamp=1436128958 glib-2.0: http://buildd.debian-ports.org/status/fetch.php?pkg=glib2.0&arch=sh4&ver=2.44.1-1.1&stamp=1436141984 Adrian
[Bug target/66749] [4.9/5/6] gcc.target/i386/addr-sel-1.c fails to merge array index into one instruction with -m32 -mregparm=3 or with -miamcu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66749 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from H.J. Lu --- Fixed for GCC 6.
[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 ctice at gcc dot gnu.org changed: What|Removed |Added CC||ctice at gcc dot gnu.org --- Comment #3 from ctice at gcc dot gnu.org --- I've been looking at this and I have a patch that I"m currently testing. I hope to be ready to submit it for approval soon.
[Bug fortran/66695] [4.9, 5 Regression] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 --- Comment #1 from Vladimir Fuka --- Anyone can confirm this behaviour?
[Bug jit/66779] jit segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66779 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-06 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Root cause is here (in expr.c): 11035 tree type = lang_hooks.types.type_for_mode (mode, unsignedp); where the langhook returns NULL, leading to a segfault. 11034 enum tree_code tcode = code == NE ? NE_EXPR : EQ_EXPR; 11035 tree type = lang_hooks.types.type_for_mode (mode, unsignedp); 11036 tree temp = fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE (arg1), 11037 gimple_assign_rhs1 (srcstmt), 11038 gimple_assign_rhs2 (srcstmt)); 11039 temp = fold_single_bit_test (loc, tcode, temp, arg1, type); (gdb) p mode $2 = QImode (gdb) p unsignedp $3 = 0 Guarded by: 11031 if (srcstmt 11032 && integer_pow2p (gimple_assign_rhs2 (srcstmt))) Fix is to handle the missing modes in jit_langhook_type_for_mode.
[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767 --- Comment #4 from Andrew Macleod --- I'm not sure where the problem is. We interacted quite a bit as the model was being developed. As I recall, it started with the standard, but they strengthened some of the problem spots for a complete testable model. To the best of my knowledge, this is the most efficient implementation that we *know* to be safe, and that is why we implement it.
[Bug fortran/66724] ICE on input/output statements with wrong specifier data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66724 --- Comment #1 from Gerhard Steinmetz --- Longer scheme : backspace (1, iomsg=#) close (1, iomsg=#) close (1, status=#) endfile (1, iomsg=#) flush (1, iomsg=#) inquire (1, iomsg=#) open (1, access=#) open (1, action=#) open (1, asynchronous=#) open (1, blank=#) open (1, delim=#) open (1, decimal=#) open (1, encoding=#) open (1, form=#) open (1, iomsg=#) open (1, pad=#) open (1, position=#) open (1, round=#) open (1, sign=#) open (1, status=#) read (1, asynchronous=#) read (1, blank=#) read (1, delim=#) read (1, decimal=#) read (1, iomsg=#) read (1, pad=#) read (1, round=#) read (1, sign=#) rewind (1, iomsg=#) wait (1, iomsg=#) write (1, asynchronous=#) write (1, blank=#) write (1, delim=#) write (1, decimal=#) write (1, iomsg=#) write (1, pad=#) write (1, round=#) write (1, sign=#) Replace placeholder # with another string : 1, 1e1, 1d1, .false., '', 'no', null(), (1), (1., 0.), [1], [''], ... Of course, not every combination line/# from above gives an ICE. For example : open (1, access='no') 1 Error: ACCESS specifier in OPEN statement at (1) has invalid value 'no'
[Bug fortran/66695] [4.9, 5 Regression] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-06 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Anyone can confirm this behaviour? Indeed! It appeared between revisions r199034 (2013-05-17, OK) and r199221 (2013-05-22, ICE).
[Bug fortran/66724] ICE on input/output statements with wrong specifier data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66724 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-06 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0).
[Bug target/65956] [5/6 Regression] Another ARM overaligned arg passing issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65956 --- Comment #3 from alalaw01 at gcc dot gnu.org --- Author: alalaw01 Date: Mon Jul 6 16:58:16 2015 New Revision: 225465 URL: https://gcc.gnu.org/viewcvs?rev=225465&root=gcc&view=rev Log: [ARM] PR/65956 AAPCS update for alignment attribute gcc/: PR target/65956 * config/arm/arm.c (arm_needs_doubleword_align): Drop any outer alignment attribute, exploring one level down for records and arrays. gcc/testsuite/: * gcc.target/arm/aapcs/align1.c: New. * gcc.target/arm/aapcs/align_rec1.c: New. * gcc.target/arm/aapcs/align2.c: New. * gcc.target/arm/aapcs/align_rec2.c: New. * gcc.target/arm/aapcs/align3.c: New. * gcc.target/arm/aapcs/align_rec3.c: New. * gcc.target/arm/aapcs/align4.c: New. * gcc.target/arm/aapcs/align_rec4.c: New. * gcc.target/arm/aapcs/align_vararg1.c: New. * gcc.target/arm/aapcs/align_vararg2.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/aapcs/align1.c trunk/gcc/testsuite/gcc.target/arm/aapcs/align2.c trunk/gcc/testsuite/gcc.target/arm/aapcs/align3.c trunk/gcc/testsuite/gcc.target/arm/aapcs/align4.c trunk/gcc/testsuite/gcc.target/arm/aapcs/align_rec1.c trunk/gcc/testsuite/gcc.target/arm/aapcs/align_rec2.c trunk/gcc/testsuite/gcc.target/arm/aapcs/align_rec3.c trunk/gcc/testsuite/gcc.target/arm/aapcs/align_rec4.c trunk/gcc/testsuite/gcc.target/arm/aapcs/align_vaarg1.c trunk/gcc/testsuite/gcc.target/arm/aapcs/align_vaarg2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool ---
There certainly are cases where these warnings are inconvenient, but
there also are cases where they are quite useful -- e.g.
int f(void) { return 0x == -1; }
[Bug fortran/66724] ICE on input/output statements with wrong specifier data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66724 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- I beat up you to the punch on most of these. Everything in comment #1 and #2 is caught except program p write (1, asynchronous=['']) write (1, asynchronous=['no']) end
[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767 --- Comment #5 from mikulas at artax dot karlin.mff.cuni.cz --- So, please pinpoint specific parahraph(s) in the standard that specify that this behavior is acceptable.
[Bug target/65956] [5/6 Regression] Another ARM overaligned arg passing issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65956 --- Comment #4 from alalaw01 at gcc dot gnu.org --- Author: alalaw01 Date: Mon Jul 6 17:06:00 2015 New Revision: 225466 URL: https://gcc.gnu.org/viewcvs?rev=225466&root=gcc&view=rev Log: Fix eipa_src AAPCS issue (PR target/65956) 2015-05-05 Jakub Jelinek PR target/65956 * gcc.c-torture/execute/pr65956.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr65956.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/66724] ICE on input/output statements with wrong specifier data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66724 --- Comment #4 from Steve Kargl --- On Mon, Jul 06, 2015 at 05:05:05PM +, kargl at gcc dot gnu.org wrote: > > I beat up you to the punch on most of these. Everything in > comment #1 and #2 is caught except > > program p >write (1, asynchronous=['']) >write (1, asynchronous=['no']) > end > In particular, r225415 | kargl | 2015-07-04 08:37:04 -0700 (Sat, 04 Jul 2015) | 12 lines r225462 | kargl | 2015-07-06 09:33:38 -0700 (Mon, 06 Jul 2015) | 11 lines
[Bug target/65956] [5/6 Regression] Another ARM overaligned arg passing issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65956 --- Comment #5 from alalaw01 at gcc dot gnu.org --- Author: alalaw01 Date: Mon Jul 6 17:32:07 2015 New Revision: 225469 URL: https://gcc.gnu.org/viewcvs?rev=225469&root=gcc&view=rev Log: 2015-07-06 Alan Lawrence Backport from mainline r225465 2015-07-06 Alan Lawrence gcc/: PR target/65956 * config/arm/arm.c (arm_needs_doubleword_align): Drop any outer alignment attribute, exploring one level down for records and arrays. gcc/testsuite/: * gcc.target/arm/aapcs/align1.c: New. * gcc.target/arm/aapcs/align_rec1.c: New. * gcc.target/arm/aapcs/align2.c: New. * gcc.target/arm/aapcs/align_rec2.c: New. * gcc.target/arm/aapcs/align3.c: New. * gcc.target/arm/aapcs/align_rec3.c: New. * gcc.target/arm/aapcs/align4.c: New. * gcc.target/arm/aapcs/align_rec4.c: New. * gcc.target/arm/aapcs/align_vararg1.c: New. * gcc.target/arm/aapcs/align_vararg2.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/aapcs/align1.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/aapcs/align2.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/aapcs/align3.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/aapcs/align4.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/aapcs/align_rec1.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/aapcs/align_rec2.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/aapcs/align_rec3.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/aapcs/align_rec4.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/aapcs/align_vaarg1.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/aapcs/align_vaarg2.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/arm/arm.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/65956] [5/6 Regression] Another ARM overaligned arg passing issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65956 --- Comment #6 from alalaw01 at gcc dot gnu.org --- Author: alalaw01 Date: Mon Jul 6 17:37:50 2015 New Revision: 225470 URL: https://gcc.gnu.org/viewcvs?rev=225470&root=gcc&view=rev Log: Backport r225466: tests from 'Fix eipa_src AAPCS issue (PR target/65956)' 2015-05-05 Jakub Jelinek PR target/65956 * gcc.c-torture/execute/pr65956.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr65956.c Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/66781] New: "confused by earlier errors, bailing out" with wrong enum within class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66781
Bug ID: 66781
Summary: "confused by earlier errors, bailing out" with wrong
enum within class
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deni_ at hotmail dot fr
Target Milestone: ---
The following code makes the compiler crash with gcc5.1 and 6,0 at least.
Removing `public' still makes the compiler crash, but leads to more error
messages.
-
class foo
{
public:
enum foo::bar{};
foo::bar baz;
};
-
[Bug c/66782] New: Unable to run 64-bit wine after MS->SYSV register changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66782 Bug ID: 66782 Summary: Unable to run 64-bit wine after MS->SYSV register changes Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: austinenglish at gmail dot com Target Milestone: --- Regression, introduced by: [austin@localhost gcc]$ git bisect bad 96c09a553634967a94b5fd4ec3c46b58ffca1700 is the first bad commit commit 96c09a553634967a94b5fd4ec3c46b58ffca1700 Author: uros Date: Sun Sep 21 15:13:14 2014 + * config/i386/i386.c (ix86_expand_call): Generate MS->SYSV extra clobbered registers using clobber_reg. Remove UNSPEC decoration. * config/i386/i386.md (unspec) : Remove. (*call_rex64_ms_sysv): Remove. (*call_value_rex64_ms_sysv): Ditto. * config/i386/predicates.md (call_rex64_ms_sysv_operation): Remove. testsuite/ChangeLog: * gcc.target/i386/avx-vzeroupper-16.c (dg-final): Remove check for call_value_rex64_ms_sysv. * gcc.target/i386/avx-vzeroupper-17.c (dg-final): Ditto. * gcc.target/i386/avx-vzeroupper-18.c (dg-final): Remove check for call_rex64_ms_sysv. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215428 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 106752531e7926ba25b0617448d4ba45911c9dad 83a0c6ad4d406be569059bf7b59320804024d1c3 M gcc See downstream issue report here: https://bugs.winehq.org/show_bug.cgi?id=38653
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #2 from Daniel Marjamäki ---
Thanks!
Hmm.. in my humble opinion, when I see the code:
int f(void) { return 0x == -1; }
.. I get the impression that the developer probably wants to test if the
bitpattern 0xfff.. matches -1.
I'd say an arbitrary U32 variable will rarelly have such large values unless
it's representing bitpatterns.. indexes, positions, sizes, etc are not that
large. and if you match a bitpattern against a negative value I'd say the match
is probably expected.
Is it possible to test how much noise this generates? My feeling is that if I
run this on various open source projects I will get lots of pure noise. If I am
right, do you think such noise would be convincing?
[Bug target/66747] [6 Regression] The commit r225260 broke the builds of the mips-{mti,img}-linux-gnu tool chains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66747 Bernd Edlinger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Bernd Edlinger --- fixed.
[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767 --- Comment #6 from Andrew Macleod --- The standard doesn't define what machines should generate what code. It defines terms for observing effects that need to be adhered to. Their machine model was created over a few years during the early stages of the memory model to help observe and test those effects. To the best of our knowledge we think the results from this model are an efficient and correct implementation within the standards definition. If you can provide a test case which demonstrates that this is not a correct implementation based on observable effects (ie the load is observed out of order somewhere), then we'd look at fixing it in GCC. If you want to discuss whether parts are or aren't compliant without a test case that fails, then you should contact the authors with your questions since they can give you a far better answer than I ever could.
[Bug c/66782] Unable to run 64-bit wine after MS->SYSV register changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66782 --- Comment #1 from Uroš Bizjak --- Adding clobbered registers explicitly is exactly the same as adding them to call_fusage, so I don't see any problem here from the first sight. Can you please provide a minimized testcase, following instructions at [1]. Unfortunately, I don't have access to Windows target, please provide a testcase that fails on linux. You can decorate calls with __attribute__((ms_abi)) even on linux. [1] https://gcc.gnu.org/bugs/#report
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773 --- Comment #3 from Andreas Schwab --- It's always the boundary cases that matter most for security.
[Bug target/66782] Unable to run 64-bit wine after MS->SYSV register changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66782 Uroš Bizjak changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Uroš Bizjak --- CC maintainer.
[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
--- Comment #7 from mikulas at artax dot karlin.mff.cuni.cz ---
#include
atomic_int a = ATOMIC_VAR_INIT(0);
atomic_int b = ATOMIC_VAR_INIT(0);
atomic_int p = ATOMIC_VAR_INIT(0);
int thread_1(void)
{
atomic_store_explicit(&b, 1, memory_order_relaxed);
atomic_load_explicit(&p, memory_order_seq_cst);
return atomic_load_explicit(&a, memory_order_relaxed);
}
int thread_2(void)
{
atomic_store_explicit(&a, 1, memory_order_relaxed);
atomic_load_explicit(&p, memory_order_seq_cst);
return atomic_load_explicit(&b, memory_order_relaxed);
}
See for example this. Suppose that thread_1 and thread_2 are executed
concurrently. If memory_order_seq_cst were a proper full memory barrier, it
would be impossible that both functions return 0. Because you omit the barrier
on read of variable p, it is possible that both functions return 0.
thread_1 is compiled into
movl$1, b(%rip)
movlp(%rip), %eax
movla(%rip), %eax
ret
thread_2 is compiled into
movl$1, a(%rip)
movlp(%rip), %eax
movlb(%rip), %eax
ret
... and the processor is free to move the writes past reads, resulting in both
functions returning zero.
Does the standard allow this behavior? I don't really know. I don't understand
the standard. Please tell me - how do you decide, by interpreting claims in the
section 7.17.3 of the C11 standard, whether the above outcome is allowed or
not?
[Bug bootstrap/66744] [6 Regression] Bootstrap failure due to conflicting access() on i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66744 --- Comment #3 from Matt Grochowalski --- The bootstrap succeeds after applying the patch.
[Bug target/66747] [6 Regression] The commit r225260 broke the builds of the mips-{mti,img}-linux-gnu tool chains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66747 --- Comment #9 from Doug Gilmore --- Our nightly builds are now clean with this patch. Thanks!
[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726 --- Comment #6 from Jeffrey A. Law --- WRT c#2. PRE will try to optimize away a runtime redundant expression. In the cases I'm looking at, there is only a single runtime evaluation. But that evaluation can be sunk from a set of predecessors into a single successor. It's more like tail merging than PRE.
[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726 --- Comment #7 from Jeffrey A. Law --- The other thing to keep in mind, sinking of this nature ought to be applicable to other unary ops and cases where we have multiple PHI args that are SSA_NAMEs.It shouldn't be structurally limited to just conversions where one arg is an SSA_NAME and the other a constant.
[Bug rtl-optimization/66237] [6 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66237 Mikhail Maltsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Mikhail Maltsev --- Though I could not fully test this fix myself (I don't have an aarch64 box), I suppose that it's safe to rely on test results published on the mailing list: https://gcc.gnu.org/ml/gcc-testresults/2015-05/msg02567.html - fail https://gcc.gnu.org/ml/gcc-testresults/2015-05/msg02714.html - pass Thus, fixed for GCC 6.
[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
--- Comment #8 from torvald at gcc dot gnu.org ---
(In reply to mikulas from comment #7)
> #include
>
> atomic_int a = ATOMIC_VAR_INIT(0);
> atomic_int b = ATOMIC_VAR_INIT(0);
> atomic_int p = ATOMIC_VAR_INIT(0);
>
> int thread_1(void)
> {
> atomic_store_explicit(&b, 1, memory_order_relaxed);
> atomic_load_explicit(&p, memory_order_seq_cst);
> return atomic_load_explicit(&a, memory_order_relaxed);
> }
>
> int thread_2(void)
> {
> atomic_store_explicit(&a, 1, memory_order_relaxed);
> atomic_load_explicit(&p, memory_order_seq_cst);
> return atomic_load_explicit(&b, memory_order_relaxed);
> }
>
> See for example this. Suppose that thread_1 and thread_2 are executed
> concurrently. If memory_order_seq_cst were a proper full memory barrier, it
> would be impossible that both functions return 0.
memory_order_seq_cst is a memory order in the Standard's terminology. Fences
are something else (ie, atomic_thread_fence()) , and parametrized by a memory
order. A memory_order_seq_cst *memory access* does not have the same effects
as a memory_order_seq_cst fence. See C++14 29.3p4-7; those paragraphs talk
about memory_order_seq_cst fences specifically, not about memory_order_seq_cst
operations in general.
If you want to make this example of Dekker synchronization correct, you need to
use fences instead of the accesses to p; alternatively, you need to use seq-cst
accesses for all the stores and loads to a and b, in which case there will be
HW fences added via the stores (as Andrew already pointed out).
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773 --- Comment #4 from Daniel Marjamäki --- absolutely. there are often bugs in the boundaries. well. I was hoping to get more optimistic response. how about this.. imagine that we wrote a "possible division by zero" warning for every integer division that uses a non-constant rhs. every warning where rhs can't really be zero would be a false positive. That would be very noisy imo. imho the false positive rate should be similar here. If there is a comparison 'a == -1' and a is unsigned then this warning is useless if a can't be 0x. if a has arbitrary values then statistically it's as likely that a is 0x and 0. So I guess the false positive rate is somewhat similar. Maybe the message can be tweaked? comparison between signed and unsigned integer expressions [-Wsign-compare] I think this message is fine for relational comparisons. A sign-cast is a reasonable solution. For == and != I am afraid the message is somewhat misleading. A sign-cast is not a good solution.
[Bug jit/66783] New: No error-checking for creating structs containing opaque structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66783 Bug ID: 66783 Summary: No error-checking for creating structs containing opaque structs Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Blocks: 66627 Target Milestone: --- Problem reported on mailing list here: https://gcc.gnu.org/ml/jit/2015-q3/msg00022.html We need to reject this kind of thing at the API boundary. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627 [Bug 66627] Tracker bug for jit bugs affecting ravi
