[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
--- Comment #18 from Jakub Jelinek ---
If you want a testcase for aarch64, e.g.
template
struct alignas (16) A { char p[16]; };
A<0> v;
template
struct B
{
typedef A T;
int i, j, k, l;
};
int
foo (int a, B<0> b)
{
return a + b.i;
}
int
bar (int a, B<1> b)
{
return a + b.i;
}
struct C
{
static int h alignas (16);
int i, j, k, l;
};
int
baz (int a, C b)
{
return a + b.i;
}
will do the job, there is a warning on foo's b argument, because A<0> has been
instantiated first and when instantiating B<0>, we already see A<0>'s alignment
and use it when creating the TYPE_DECL. Compared to that, for B<1> we don't
have it instantiated yet, so when TYPE_DECL is created, it gets minimal
alignment. You might want to create e.g. a compat testcase from it too, have
caller of foo with the A<0> v; in it and callee without and vice versa, check
if it is able to pass the argument around properly. Similarly with baz (in
that case it actually was a stable (but wrong) ABI before, the baz caller and
callee would agree, but they now don't in between unpatched and patched GCC.
For ARM you can easily adjust the testcase by s/16/8/g, and maybe removing k
and l fields too.
Comments on the patch:
#include "print-tree.h"
you don't really need this, that is from some debugging, right?
unsigned int alignment ; // alignment for FIELD_DECLS in function arguments.
extraneous space before ;, not sure if it is a good idea to mix // and /*
comments and on the next line it is way too long, so maybe better use /* */
comments above each field.
{
+
+ unsigned int alignment = 0;
+ unsigned int warning_alignment = 0;
extraneous vertical space. Also, what is the point to have a struct containing
those 2 fields and auto vars mirroring that? Just use the struct all the time?
alignment = std::max (alignment, DECL_ALIGN (field));
I think we usually use MAX rather than std::max.
+ if (nregs == 2 && (a.warning_alignment == 16 * BITS_PER_UNIT) && ncrn %
2)
+ if (a.warning_alignment < a.alignment
+ && warn_psabi)
+ warning (0, "Parameter passing changed for argument");
The if condition fits on one line. Do you need the ()s around
a.warning_alignment == 16 * BITS_PER_UNIT? Can't it be written as
if (warn_psabi
&& nregs == 2
&& a.warning_alignment == 16 * BITS_PER_UNIT
&& a.alignment != 16 * BITS_PER_UNIT
&& ncrn % 2)
? That is what is actually tested originally, whether alignment == 16 *
BITS_PER_UNIT. Also, warnings should not start with capital letter.
And it would be nice to tell user which argument it is (does cumulative_args_t
track the argument number or could it?).
on_stack:
pcum->aapcs_stack_words = size / UNITS_PER_WORD;
- if (aarch64_function_arg_alignment (mode, type) == 16 * BITS_PER_UNIT)
+ struct aarch64_fn_arg_alignment ab = aarch64_function_arg_alignment (mode,
type);
+ if (ab.alignment == 16 * BITS_PER_UNIT)
pcum->aapcs_stack_size = ROUND_UP (pcum->aapcs_stack_size,
16 / UNITS_PER_WORD);
No warning here, if ab.alignment is not 16 * BITS_PER_UNIT, but
ab.warning_alignment is and warn_psabi is on? I must say I don't really know
exactly what pcum->aapcs_stack_size influence, but doesn't it influence the ABI
when the function is varargs? I mean, with the above testcase, something like:
void
foo (int a, int b, int c, int d, int e, int f, int g, int h, int i, int j, int
k, int l, int m, B<0> n, ...)
with/without the A<0> v; early?
if (alignment < PARM_BOUNDARY)
alignment = PARM_BOUNDARY;
if (alignment > STACK_BOUNDARY)
alignment = STACK_BOUNDARY;
+
+ if (a.warning_alignment < PARM_BOUNDARY)
+a.warning_alignment = PARM_BOUNDARY;
+
+ if (a.warning_alignment > STACK_BOUNDARY)
+a.warning_alignment = STACK_BOUNDARY;
+
Isn't the above candidate for MAX/MIN to put it into fewer lines?
+ if (a.warning_alignment > alignment
+ && warn_psabi)
+warning (0, "Parameter passing changed for argument in
function_arg_boundary");
+
+
Again, condition can fit onto a single line. Due to MAX/MIN, I guess the only
possible values of those 2 are 64 and 128, so the comparison is fine. But
again, warning should not start with a capital letter and mentioning "in
function_arg_boundary" is not helpful to the users, much better would be to
tell which argument it is or something similar. And, perhaps remove the
alignment variable and always use a.alignment? There is also extra vertical
space before return.
+ align = a.alignment / BITS_PER_UNIT;
Extraneous whitespace after =.
[Bug fortran/80477] Polymorphic functions (thus operators) generates memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #1 from Stefano Zaghi --- I forget to say that I test this issue with GNU gfortran gcc version 6.3.1 20170306 and gcc version 7.0.0 20161206 (experimental). My best regards.
GNU gfortran potential bug: polymorphic functions (thus defined operators) generates serious memory leaks
Dear all, I faced with a possible serious bug: polymorphic functions (necessary to define polymorphic operators in OOP programs) generate memory leaks making OOP program not feasible. I opened a bug report (80477) here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 I report the details also below. My best regards. Issue summary In the attached example "polymorphic_operators_memory_leaks.f90" I show the possible bug in less than 100 lines. Essentially, the derived type "a_type_t" defines the operators "=" and "+" in a polymorphic way (in order to allow "a_type_t" to be extended while all other "agents" using "a_type_t" do not need to be changed, OOP). The assignment operator does not create memory leaks because it is subroutine that does not allocate temporary. On the contrary, the operator "+" is a function that allocates a temporary: this temporary generates the memory leaks because it is not correctly destroyed after its usage. I checked the above conclusion with "valgrind" and it confirms that the "+" operator (function) generates the leaks. Note that the same code compiled and run with Intel Fortran (17.0.2) does not generates memory leaks and it works as expected. Moreover, is the "+" operator/function is modified disallowing polymorphic (namely changing "class(a_type_t), allocatable :: res" with "type(a_type_t) :: res" the leaks disappear, thus I could conclude that the leaks are generated only for polymorphic function results. A word of advice: the test is designed to point out the memory leaks occurrences, running it your RAM will be quickly consumed! Please, be rapid to quickly kill it before your OS start swapping on HD. To test it with valgrind I added a little "ui": it can be executed without arguments, thus its loop will be very long (and your RAM totally consumed) or you can pass one integer argument and the loop will do the iterations you provided, e.g. "a.out 1" will execute 1 iteration loop. This is written into the code comments. Please, consider that if this is really a bug, all serious OOP programs are indeed impossible to be done. Thank you very much for your help. Stefano Zaghi Ph.D. Aerospace Engineer Research Scientist, Dept. of Computational Hydrodynamics at CNR-INSEAN p: +39 0650299260 | m: +39 3497730036 | e: stefano.za...@gmail.com Member of Fortran-FOSS-Programmers Codes Showcase OFF Open source Finite volumes Fluid dynamics code Lib_VTK_IO Fortran library to write and read data conforming the VTK standard FLAP Fortran command Line Arguments Parser for poor men BeFoR64 Base64 encoding/decoding library for FoRtran poor men FiNeRFortran INI ParseR and generator for FoRtran poor men IR_Precision Fortran (standard 2003) module to develop portable codes FoBis.py Fortran Building System for poor men PreForM.py Preprocessor for Fortran poor men MaTiSSe.py Markdown To Impressive Scientific Slides module a_type_m implicit none integer, parameter :: LENGTH = 100 type :: a_type_t real :: x(LENGTH) contains ! operators generic :: assignment(=) => assign_a_type generic :: operator(+) => add_a_type procedure, pass(lhs) :: assign_a_type procedure, pass(lhs) :: add_a_type endtype a_type_t contains subroutine assign_a_type(lhs, rhs) ! Operator `=`. class(a_type_t), intent(inout) :: lhs class(a_type_t), intent(in):: rhs lhs%x = rhs%x endsubroutine assign_a_type function add_a_type(lhs, rhs) result( res ) ! Operator `+`. class(a_type_t), intent(in) :: lhs class(a_type_t), intent(in) :: rhs class(a_type_t), allocatable :: res allocate (a_type_t :: res) res%x = lhs%x + rhs%x endfunction add_a_type endmodule a_type_m program polymorphic_operators_memory_leaks ! pass one argument to limit the loop iterations, e.g.: ! a.out 4 # the loop will be limited to 4 iterations ! useful for testing with valgrind; ! a.out # the loop will run for LENGHT**3 iterations use a_type_m implicit none character(99) :: switch type(a_type_t) :: a type(a_type_t) :: b integer:: N integer:: i a%x = [(i, i=1, LENGTH)] b = a i = command_argument_count() if (i == 1) then call get_command_argument(1,switch) read(switch, *) N else N = LENGTH**3 endif do i=1, N b = a + b ! here the `+` operator generates memory leaks if (mod(i,10**5) == 0) print*, i enddo endprogram polymorphic_operators_memory_leaks
[Bug rtl-optimization/80425] Extra inter-unit register move with zero-extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80425 --- Comment #3 from Uroš Bizjak --- (In reply to Vladimir Makarov from comment #2) > So I don't know how to fix it in IRA or in LRA. I am pretty sure the > old RA and reload would have had the same problem. > > Probably the issue should be fixed in machine dependent code. But the fix > might create more problems. It is possible to create a couple of peephole2 patterns to catch this, but perhaps REE can be enhanced to optimize the above register propagation, so the solution would apply to all targets.
[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
--- Comment #19 from Jakub Jelinek ---
Indeed, with the above plus:
#include
int
fn1 (int a, int b, int c, int d, int e, int f, int g, int h, int i, int j, int
k, int l, int m, B<0> n, ...)
{
va_list ap;
va_start (ap, n);
int x = va_arg (ap, int);
va_end (ap);
return x;
}
int
fn2 (int a, int b, int c, int d, int e, int f, int g, int h, int i, int j, int
k, int l, int m,
B<1> n, ...)
{
va_list ap;
va_start (ap, n);
int x = va_arg (ap, int);
va_end (ap);
return x;
}
there is ABI change for fn1 but not fn2. But we already get a warning with
your patch on that:
warning: Parameter passing changed for argument in function_arg_boundary
so perhaps no need to emit it for the second time.
[Bug tree-optimization/80345] [5 Regression] ICE in rewrite_use_nonlinear_expr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80345 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from amker at gcc dot gnu.org --- Now fixed.
[Bug tree-optimization/80426] [6 Regression] wrong manipulation of range based on INT_MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80426 --- Comment #10 from Eric Botcazou --- Author: ebotcazou Date: Fri Apr 21 08:03:54 2017 New Revision: 247046 URL: https://gcc.gnu.org/viewcvs?rev=247046&root=gcc&view=rev Log: PR tree-optimization/80426 * gcc.c-torture/execute/20170429-1.c: Rename into... * gcc.c-torture/execute/20170419-1.c: ...this. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20170419-1.c - copied unchanged from r247045, trunk/gcc/testsuite/gcc.c-torture/execute/20170429-1.c Removed: trunk/gcc/testsuite/gcc.c-torture/execute/20170429-1.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/80426] [6 Regression] wrong manipulation of range based on INT_MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80426 --- Comment #11 from Eric Botcazou --- Author: ebotcazou Date: Fri Apr 21 08:08:03 2017 New Revision: 247047 URL: https://gcc.gnu.org/viewcvs?rev=247047&root=gcc&view=rev Log: PR tree-optimization/80426 * gcc.c-torture/execute/20170429-1.c: Rename into... * gcc.c-torture/execute/20170419-1.c: ...this. Added: branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20170419-1.c - copied unchanged from r247046, branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20170429-1.c Removed: branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20170429-1.c Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/80476] GCC 7 can't be compiled with bootstrap-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80476 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-21 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Reading Czech error messages, I feel I have to fix the issue. Seriously, I believe it's just one another false positive of the warning and initialization will be probably needed. Let me reproduce that.
[Bug tree-optimization/80237] float to double conversion is not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80237 --- Comment #2 from Richard Biener --- Author: rguenth Date: Fri Apr 21 08:17:23 2017 New Revision: 247049 URL: https://gcc.gnu.org/viewcvs?rev=247049&root=gcc&view=rev Log: 2017-04-21 Richard Biener PR tree-optimization/80237 * tree-ssa-pre.c (find_leader_in_sets): Add third set argument, defaulted to NULL. (phi_translate_1): Also allow a leader in AVAIL_OUT of pred for a simplified result. * gcc.dg/tree-ssa/tailcall-9.c: New testcase. * gcc.dg/tree-ssa/ldist-pr45948.c: Remove undefined behavior, adjust expected optimizations. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/tailcall-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-pr45948.c trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/80426] [6 Regression] wrong manipulation of range based on INT_MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80426 --- Comment #12 from Eric Botcazou --- Author: ebotcazou Date: Fri Apr 21 08:37:13 2017 New Revision: 247050 URL: https://gcc.gnu.org/viewcvs?rev=247050&root=gcc&view=rev Log: Backport from mainline 2017-04-19 Eric Botcazou Jakub Jelinek PR tree-optimization/80426 * tree-vrp.c (extract_range_from_binary_expr_1): For an additive operation on symbolic operands, also compute the overflow for the invariant part when the operation degenerates into a negation. Added: branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/execute/20170419-1.c - copied unchanged from r247047, trunk/gcc/testsuite/gcc.c-torture/execute/20170419-1.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/tree-vrp.c
[Bug tree-optimization/80426] [6 Regression] wrong manipulation of range based on INT_MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80426 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Eric Botcazou --- .
[Bug tree-optimization/80237] float to double conversion is not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80237 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.0 Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed for GCC 8.
[Bug tree-optimization/66278] Missed auto-vectorization of an array subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66278 --- Comment #8 from Martin Liška --- Author: marxin Date: Fri Apr 21 08:50:19 2017 New Revision: 247051 URL: https://gcc.gnu.org/viewcvs?rev=247051&root=gcc&view=rev Log: Add test-case (PR tree-optimization/66278). 2017-04-21 Martin Liska PR tree-optimization/66278 * gcc.dg/vect/pr66278.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr66278.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/80468] [7/8 Regression] ICE on invalid AVX512 code with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80468 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Fri Apr 21 08:51:53 2017 New Revision: 247052 URL: https://gcc.gnu.org/viewcvs?rev=247052&root=gcc&view=rev Log: PR c/80468 * c-decl.c (finish_declspecs) : If int_n_idx is not enabled, set specs->type to integer_type_node. * gcc.dg/pr80468.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr80468.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/66278] Missed auto-vectorization of an array subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66278 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška --- Test has been added, closing as resolved.
[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 --- Comment #20 from Jakub Jelinek --- BTW, the wording e.g. i386 backend has is: inform (input_location, "the ABI of passing structure with complex float" " member has changed in GCC 4.4"); In this arm/aarch64 case, the wording can't be as specific, because it isn't all arguments of this type, but only some arguments of certain type (at some positions; for some types like those that have more aligned static data members it is all such positioned arguments, for others, e.g. the templates where the alignment used to depend on instantiation vs. non-instantiation something earlier, only some), but you should consider using inform rather than warning for consistency, and you should mention the GCC version where it has changed and maybe also print the type in the diagnostic, so that user at least knows what type it is that is problematic (but as it is not something as simple as in the i386 case, there should not be a single inform per TU, but about each case this is encountered). Richard said we should defer RC1 till this is done, do you think you can have a patch for both architectures written today, tested over the weekend, so that we could do RC1 on Monday or Tuesday at latest? Is there an agreement in ARM that what the patch does (for aarch64, and similar one for arm) is what the AAPCS says?
[Bug demangler/70909] Libiberty Demangler segfaults (4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909 --- Comment #53 from Mark Wielaard --- Author: mark Date: Fri Apr 21 09:02:03 2017 New Revision: 247056 URL: https://gcc.gnu.org/viewcvs?rev=247056&root=gcc&view=rev Log: libiberty: Limit demangler maximum d_print_comp recursion call depth. The fix for PR demangler/70909 and 67264 (endless demangler recursion) catches when a demangle_component is printed in a cycle. But that doesn't protect the call stack blowing up from non-cyclic nested types printed recursively through d_print_comp. This can happen by a (very) long mangled string that simply creates a very deep pointer or qualifier chain. Limit the recursive d_print_comp call depth for a d_print_info to 1K nested types. libiberty/ChangeLog: * cp-demangle.c (MAX_RECURSION_COUNT): New constant. (struct d_print_info): Add recursion field. (d_print_init): Initialize recursion. (d_print_comp): Check and update d_print_info recursion depth. Modified: trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c
[Bug tree-optimization/79534] [7/8 Regression] tree-ifcombine aarch64 performance regression with trunk@245151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
--- Comment #12 from James Greenhalgh ---
So while there's nothing buggy about the if-conversion which causes the
performance issue, it does show an interesting missed optimization that ifcvt
can't handle.
We make the transform through find_if_case_2, which looks for things of the
form:
/* TEST BLOCK */
if (test)
goto E; // x not live
/* FALLTHRU */
/* ELSE BLOCK */
x = big();
goto L;
E:
/* THEN BLOCK */
x = b;
goto M;
And transforms them to:
/* Unconditional copy of THEN BLOCK */
x = b;
/* TEST BLOCK */
if (test)
goto M;
/* ELSE BLOCK */
x = big();
goto L;
In the testcase, using the naming conventions above, and snipping irrelevant
details, this looks like:
TEST BLOCK (309)
;; basic block 309, loop depth 4, count 0, freq 3153, maybe hot
;; prev block 308, next block 311, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 219 [98.0%]
(insn 1915 1914 1916 309 (set (reg:CC 66 cc)
(compare:CC (reg:SI 1117)
(const_int 0 [0]))) "foo.cpp":59 391 {cmpsi}
(expr_list:REG_DEAD (reg:SI 1117)
(nil)))
(jump_insn 1916 1915 1922 309 (set (pc)
(if_then_else (ne (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 1905)
(pc))) "foo.cpp":59 9 {condjump}
(expr_list:REG_DEAD (reg:CC 66 cc)
(int_list:REG_BR_PROB 9558 (nil)))
-> 1905)
;; succ: 227 [95.6%]
;; 226 [4.4%] (FALLTHRU)
ELSE BLOCK (226)
;; basic block 226, loop depth 4, count 0, freq 201, maybe hot
;; prev block 224, next block 227, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 309 [4.4%] (FALLTHRU)
;; 311 [3.8%] (FALLTHRU)
(code_label 1917 1413 1417 226 141 (nil) [0 uses])
(note 1417 1917 1418 226 [bb 226] NOTE_INSN_BASIC_BLOCK)
(insn 1418 1417 1905 226 (set (reg:SI 690 [ _1517 ])
(plus:SI (reg:SI 703 [ ivtmp.56D.5375 ])
(const_int -3 [0xfffd]))) 95 {*addsi3_aarch64}
(nil))
;; succ: 237 [100.0%] (FALLTHRU)
THEN BLOCK (227)
;; basic block 227, loop depth 4, count 0, freq 3013, maybe hot
;; prev block 226, next block 228, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 309 [95.6%]
(code_label 1905 1418 1421 227 140 (nil) [1 uses])
(note 1421 1905 1422 227 [bb 227] NOTE_INSN_BASIC_BLOCK)
(insn 1422 1421 1802 227 (set (reg:SI 690 [ _1517 ])
(plus:SI (reg:SI 703 [ ivtmp.56D.5375 ])
(const_int -3 [0xfffd]))) 95 {*addsi3_aarch64}
(nil))
;; succ: 237 [100.0%] (FALLTHRU)
So the interesting thing is that the THEN block and the ELSE block are as good
as identical! Both compute (plus (reg 703) (const_int -3)) and both fall
through to block 237.
The normal if-convert machinery won't catch this because basic block 226 (the
ELSE block) has multiple predecessors. But the transformation we make through
find_if_case_2 ends up looking silly! (again, snipping some unrelated
details/insns):
TEST BLOCK (279)
;; basic block 279, loop depth 4, count 0, freq 3153, maybe hot
;; prev block 278, next block 280, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 203 [98.0%]
/* Unconditional copy of THEN BLOCK. */
(insn 1422 1914 1915 279 (set (reg:SI 690 [ _1517 ])
(plus:SI (reg:SI 703 [ ivtmp.56D.5375 ])
(const_int -3 [0xfffd]))) 95 {*addsi3_aarch64}
(nil))
(insn 1915 1422 1916 279 (set (reg:CC 66 cc)
(compare:CC (reg:SI 1117)
(const_int 0 [0]))) "foo.cpp":59 391 {cmpsi}
(expr_list:REG_DEAD (reg:SI 1117)
(nil)))
(jump_insn 1916 1915 1922 279 (set (pc)
(if_then_else (ne (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref:DI 1470)
(pc))) "foo.cpp":59 9 {condjump}
(expr_list:REG_DEAD (reg:CC 66 cc)
(int_list:REG_BR_PROB 9558 (nil)))
-> 1470)
;; succ: 218 [95.6%]
;; 209 [4.4%] (FALLTHRU)
ELSE BLOCK (209):
;; basic block 209, loop depth 4, count 0, freq 201, maybe hot
;; prev block 208, next block 210, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 279 [4.4%] (FALLTHRU)
;; 280 [3.8%] (FALLTHRU)
(code_label 1917 1413 1417 209 141 (nil) [0 uses])
(note 1417 1917 1418 209 [bb 209] NOTE_INSN_BASIC_BLOCK)
(insn 1418 1417 1802 209 (set (reg:SI 690 [ _1517 ])
(plus:SI (reg:SI 703 [ ivtmp.56D.5375 ])
(const_int -3 [0xfffd]))) 95 {*addsi3_aarch64}
(nil))
;; succ: 218 [100.0%] (FALLTHRU)
Note that if we are on the "else" path, we now we compute (pl
[Bug c/80468] [7 Regression] ICE on invalid AVX512 code with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80468 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE on |[7 Regression] ICE on |invalid AVX512 code with|invalid AVX512 code with |-m32|-m32 --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far, queued for 7.2.
[Bug bootstrap/80476] GCC 7 can't be compiled with bootstrap-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80476 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Except for the most common --with-build-config options, people should use --disable-werror, it is too hard to keep the sources warning free for all possible optimization levels, PGO, LTO etc. variants.
[Bug bootstrap/80476] GCC 7 can't be compiled with bootstrap-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80476 --- Comment #4 from Martin Liška --- Initializing the variable to zero fixes the issue. Should I install that to trunk?
[Bug rtl-optimization/78116] [7/8 regression] Performance drop after r241173 on avx512 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116 --- Comment #16 from Andrew Senkevich --- (In reply to amker from comment #13) > We should create another PR for additional copy instructions after my patch > and close this one. IMHO they are two different issues. I agree, currently there are no fills from stack on both testcases for which this PR was created. But I have no bugzilla permissions to close it, could somebody from CC close it please? (In reply to Pat Haugen from comment #14) . . . > Additional info, it's really just one copy introduced, but becomes 4 after > unrolling. This is the loop from the first testcase without -funroll-loops. > Looks like we could get rid of the vmovaps by making zmm2 the dest on the > vpermps (assuming I'm understanding the asm correctly). > > .L26: > vpermps (%rcx), %zmm10, %zmm1 > leal1(%rsi), %esi > vmovaps %zmm1, %zmm2 > vmaxps (%r15,%rdx), %zmm3, %zmm1 > vfnmadd132ps(%r12,%rdx), %zmm7, %zmm2 > cmpl%esi, %r8d > leaq-64(%rcx), %rcx > vmaxps %zmm1, %zmm2, %zmm1 > vmovups %zmm1, (%rdi,%rdx) > leaq64(%rdx), %rdx > ja .L26 Looks like so. For which optimization/analysis we should file ticket for it?
[Bug target/68390] [5 Regression] Incorrect code due to indirect tail call of varargs function with hard float ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68390 --- Comment #5 from Christophe Lyon --- Author: clyon Date: Fri Apr 21 09:23:59 2017 New Revision: 247057 URL: https://gcc.gnu.org/viewcvs?rev=247057&root=gcc&view=rev Log: [ARM] PR68390 Incorrect code due to indirect tail call of varargs function with hard float ABI 2017-04-21 Christophe Lyon Backport from mainline +2015-11-23 Kugan Vivekanandarajah PR target/68390 gcc/ * config/arm/arm.c (arm_function_ok_for_sibcall): Get function type for indirect function call. gcc/testsuite/ * gcc.c-torture/execute/pr68390.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr68390.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/68390] [5 Regression] Incorrect code due to indirect tail call of varargs function with hard float ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68390 Christophe Lyon changed: What|Removed |Added Status|NEW |RESOLVED CC||clyon at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Christophe Lyon --- Should be fixed now.
[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 --- Comment #21 from Jakub Jelinek --- inform, beyond being consistent with what i386 and rs6000 backends do here, has the advantage that it doesn't break the build even with -Werror, generally there is nothing wrong on the code we want to inform user about, so there is nothing to fix unless they want to achieve ABI compatibility with code compiled by older GCC versions. For this category i386/rs6000 backends use inform. There are also warning uses with OPT_Wpsabi, but those are there for when user is doing something considered wrong, e.g. passing vector argument by value in a function without corresponding ISA supporting those vectors enabled.
[Bug target/80479] New: endless stream of valgrind errors when using trunk build with trunk on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479 Bug ID: 80479 Summary: endless stream of valgrind errors when using trunk build with trunk on ppc64le Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- When I build trunk with trunk on ppc64le (--enable-valgrind-annotations --disable-bootstrap) the resulting compiler produces many valgrind errors, even on simple testcases. Building trunk with an older release works fine. trippels@gcc2-power8 ~ % valgrind --track-origins=yes --trace-children=yes ~/gcc_test/usr/local/bin/g++ -O2 bench.cpp ==140970== Memcheck, a memory error detector ==140970== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==140970== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==140970== Command: /home/trippels/gcc_test/usr/local/bin/g++ -O2 bench.cpp ==140970== ==140970== Invalid read of size 4 ==140970==at 0x100A9630: make_relative_prefix_1 (make-relative-prefix.c:356) ==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*) (gcc.c:4222) ==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416) ==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228) ==140970==by 0x10003B97: main (gcc-main.c:46) ==140970== Address 0x43bd2b4 is 2 bytes after a block of size 2 alloc'd ==140970==at 0x4083E0C: malloc (vg_replace_malloc.c:299) ==140970==by 0x100A9397: save_string (make-relative-prefix.c:108) ==140970==by 0x100A9397: split_directories (make-relative-prefix.c:174) ==140970==by 0x100A951B: make_relative_prefix_1 (make-relative-prefix.c:325) ==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*) (gcc.c:4222) ==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416) ==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228) ==140970==by 0x10003B97: main (gcc-main.c:46) ==140970== ==140970== Invalid read of size 4 ==140970==at 0x100A9634: make_relative_prefix_1 (make-relative-prefix.c:356) ==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*) (gcc.c:4222) ==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416) ==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228) ==140970==by 0x10003B97: main (gcc-main.c:46) ==140970== Address 0x43bd474 is 2 bytes after a block of size 2 alloc'd ==140970==at 0x4083E0C: malloc (vg_replace_malloc.c:299) ==140970==by 0x100A9397: save_string (make-relative-prefix.c:108) ==140970==by 0x100A9397: split_directories (make-relative-prefix.c:174) ==140970==by 0x100A95CF: make_relative_prefix_1 (make-relative-prefix.c:348) ==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*) (gcc.c:4222) ==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416) ==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228) ==140970==by 0x10003B97: main (gcc-main.c:46) ==140970== ==140970== Conditional jump or move depends on uninitialised value(s) ==140970==at 0x100A963C: make_relative_prefix_1 (make-relative-prefix.c:356) ==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*) (gcc.c:4222) ==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416) ==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228) ==140970==by 0x10003B97: main (gcc-main.c:46) ==140970== ==140970== Conditional jump or move depends on uninitialised value(s) ==140970==at 0x100A9648: make_relative_prefix_1 (make-relative-prefix.c:356) ==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*) (gcc.c:4222) ==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416) ==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228) ==140970==by 0x10003B97: main (gcc-main.c:46) ... ==140970== ERROR SUMMARY: 98 errors from 21 contexts (suppressed: 0 from 0)
[Bug c/80409] Document that va_arg(ap, void*) can be used to consume any pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80409 --- Comment #3 from joseph at codesourcery dot com --- On Wed, 12 Apr 2017, pascal_cuoq at hotmail dot com wrote: > Since the open-source world divides the C compilation platform described by > the > C standard into C compilers (Clang, GCC) and standard libraries (Glibc, musl, > ...), with the implementation of varargs on the compiler side and the > implementation of scanf on the standard library side, it would make sense to > document that on target platforms where the representation of pointers is > uniform, the compilers allow va_arg(ap, void*) to consume any pointer > argument. Note that this is documented in POSIX (XSI-shaded, in the specification of stdarg.h).
[Bug rtl-optimization/78116] [7/8 regression] Performance drop after r241173 on avx512 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116 --- Comment #17 from amker at gcc dot gnu.org --- (In reply to Andrew Senkevich from comment #16) > (In reply to amker from comment #13) > > We should create another PR for additional copy instructions after my patch > > and close this one. IMHO they are two different issues. > > I agree, currently there are no fills from stack on both testcases for which > this PR was created. > But I have no bugzilla permissions to close it, could somebody from CC close > it please? > > (In reply to Pat Haugen from comment #14) > . . . > > Additional info, it's really just one copy introduced, but becomes 4 after > > unrolling. This is the loop from the first testcase without -funroll-loops. > > Looks like we could get rid of the vmovaps by making zmm2 the dest on the > > vpermps (assuming I'm understanding the asm correctly). > > > > .L26: > > vpermps (%rcx), %zmm10, %zmm1 > > leal1(%rsi), %esi > > vmovaps %zmm1, %zmm2 > > vmaxps (%r15,%rdx), %zmm3, %zmm1 > > vfnmadd132ps(%r12,%rdx), %zmm7, %zmm2 > > cmpl%esi, %r8d > > leaq-64(%rcx), %rcx > > vmaxps %zmm1, %zmm2, %zmm1 > > vmovups %zmm1, (%rdi,%rdx) > > leaq64(%rdx), %rdx > > ja .L26 > > Looks like so. For which optimization/analysis we should file ticket for it? Put rtl-optimization would be fine for this. I can close this ticket after new one is created. Thanks.
[Bug target/80479] endless stream of valgrind errors when using trunk build with trunk on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479 Markus Trippelsdorf changed: What|Removed |Added Target||ppc64le Host||ppc64le --- Comment #1 from Markus Trippelsdorf --- Not sure what is going on. I will try a bootstrap with --enable-checking=valgrind.
[Bug rtl-optimization/80474] ipa-cp wrongly adding LO(symbol) twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474 Richard Biener changed: What|Removed |Added Target||mips-o32 Status|UNCONFIRMED |WAITING Last reconfirmed||2017-04-21 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Can you provide unreduced preprocessed source plus command-line options to reproduce with a cross?
[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80232 --- Comment #6 from Richard Biener --- I've adjusted the generic cost model for gather/scatter for GCC 8 (doesn't help here).
[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80232 Bug 80232 depends on bug 57796, which changed state. Bug 57796 Summary: AVX2 gather vectorization: code bloat and reduction of performance https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/57796] AVX2 gather vectorization: code bloat and reduction of performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Cost model is fixed for GCC 8.
[Bug tree-optimization/80153] ivopt generate wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80153 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Known to work||7.0.1 Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed for GCC 7.
[Bug target/80479] endless stream of valgrind errors when using trunk build with trunk on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479 --- Comment #2 from Markus Trippelsdorf --- Hmm, all error locations involve calls to strcmp().
[Bug target/80479] endless stream of valgrind errors when using trunk build with trunk on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-04-21
Ever confirmed|0 |1
--- Comment #3 from Markus Trippelsdorf ---
trippels@gcc2-power8 ~ % cat example.c
#include
int main ()
{
char str1[15];
char str2[15];
strcpy(str1, "abcdef");
strcpy(str2, "ABCDEF");
return strcmp(str1, str2);
}
trippels@gcc2-power8 ~ % ~/gcc_7/usr/local/bin/gcc -O2 -g example.c
trippels@gcc2-power8 ~ % valgrind ./a.out
==28988== Memcheck, a memory error detector
==28988== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==28988== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==28988== Command: ./a.out
==28988==
==28988== Conditional jump or move depends on uninitialised value(s)
==28988==at 0x14E8: main (example.c:9)
[Bug target/80479] endless stream of valgrind errors when using trunk build with trunk on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- I'll take a look. It's maybe related to folding improvements I did.
[Bug ipa/79765] [CHKP] ICE in create_target_clone in multiple_target.c:211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79765
Alexander Ivchenko changed:
What|Removed |Added
CC||aivchenk at gmail dot com
--- Comment #1 from Alexander Ivchenko ---
Multi-versioning pass tries to make versions out of mpx chunks, which have no
bodies and hence it fails. I think there is no reason to keep target_clones
attribute for chunks. The following patch helps:
diff --git a/gcc/ipa-chkp.c b/gcc/ipa-chkp.c
index c7fc3a0..5de11b3 100644
--- a/gcc/ipa-chkp.c
+++ b/gcc/ipa-chkp.c
@@ -718,6 +718,9 @@ chkp_produce_thunks (bool early)
0, CGRAPH_FREQ_BASE);
node->create_reference (node->instrumented_version,
IPA_REF_CHKP, NULL);
+ DECL_ATTRIBUTES (node->decl)
+ = remove_attribute ("target_clones",
+ DECL_ATTRIBUTES (node->decl));
/* Thunk shouldn't be a cdtor. */
DECL_STATIC_CONSTRUCTOR (node->decl) = 0;
DECL_STATIC_DESTRUCTOR (node->decl) = 0;
.. And at "O0" it works. However it fails later on at O1 and above.
gcc/gcc/testsuite/gcc.target/i386/mvc1.c:18:1: error: virtual definition of
statement not up-to-date
main ()
^~~~
_3 = foo.chkp.ifunc ();
gcc/gcc/testsuite/gcc.target/i386/mvc1.c:18:1: internal compiler error:
verify_ssa failed
r0x113ccab verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.c:1184
0xd65f4b execute_function_todo
../../gcc/gcc/passes.c:1973
0xd64fab do_per_function
../../gcc/gcc/passes.c:1650
0xd660d6 execute_todo
../../gcc/gcc/passes.c:2016
[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479 --- Comment #5 from Markus Trippelsdorf --- Looks more like a missing valgrind suppression.
[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479
--- Comment #6 from Martin Liška ---
The memcmp is emitted directly by isntructions, it would need someone who can
verify that it's not touching the uninitialized bytes of str{1,2} (bytes 8-15).
After calling memset for these bytes, the error is gone in valgrind.
[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479 Markus Trippelsdorf changed: What|Removed |Added CC||acsawdey at gcc dot gnu.org --- Comment #7 from Markus Trippelsdorf --- Started with r244598.
[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.2 --- Comment #8 from Richard Biener --- So it would be interesting to see if it faults when placing the strings at the edge of a page boundary... In any case reading excess bytes from an aligned location is ok but of course unfortunate for tolls like valgrind. So not sure if a bug (but see above).
[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773 --- Comment #14 from wilco at gcc dot gnu.org --- (In reply to PeteVine from comment #11) > I've just retested gcc7 on both ARM platforms. > > AArch64 gets a 3% improvement now, while ARMv7 reproduces the issue, just as > before. I'm compiling/profiling on a Cortex A5 which could be the main > reason behind all this, as it doesn't have hard division. Can you try comparing the .S outputs on both the Cortex-A5 and Cortex-A53 system using exact same options, ie. -marm -mcpu=cortex-a5? Assuming you're using the same GCC version, you should get identical .S files and the same .gcda.
[Bug fortran/79430] [7/8 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #62 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #61) > (In reply to Thomas Koenig from comment #60) > > r242780 works. > > > > With both r243586 and r244391, plus the patch for r245191 > > applied, I got numerous failures in the test suite. > > > > Apparently, something else was wrong for some time, which > > blocks the attempt at bisection for that particular error > > in that range. > > There was also this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79344 > fixed in r245194. You don't apply any -fcheck= flags, right? No, I don't. I appear to have hit a wall in bisecting. I keep getting lots of failures in your test suite with additional errors. Either I am doing something wrong in testing, or there were indeed other errors present which keep the intermediate versions from working. Could you re-check this, for exapmle by doing "svn update -r 243183" in trunk, recompiling the compiler, and then running your testsuite again? Or how could I just, with a single command, run the test case you are interested in, without going through all the other tests? I am currently at a loss how to proceed.
[Bug c++/80480] New: The compiler gets killed by an internal error when compiling ZNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80480 Bug ID: 80480 Summary: The compiler gets killed by an internal error when compiling ZNC Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: abel at abelromero dot com Target Milestone: --- I was compiling ZNC-1.6.5 (http://znc.in/releases/znc-1.6.5.tar.gz) and I got that error: [...] Linking module nickserv... Building module sample... Linking module sample... Building module log... g++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Makefile:116: recipe for target 'log.o' failed make[1]: *** [log.o] Error 4 Makefile:105: recipe for target 'modules' failed make: *** [modules] Error 2
[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80480 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- You need more memory. Look for OOM killer in dmseg.
[Bug tree-optimization/78869] [6/7/8 Regression] Strange __builtin_memcpy optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78869 Martin Jambor changed: What|Removed |Added Depends on|78687 |80293 --- Comment #4 from Martin Jambor --- Richi, I believe you wanted to add a dependency on PR 80293 (and not on PR 78687). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78687 [Bug 78687] inefficient code generated for eggs.variant https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80293 [Bug 80293] [6/7/8 Regression] unnecessary code at -O2 (-O1 is fine)
[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80480 --- Comment #2 from Abel Romero --- I commit that bug to improve g++ because I solved this issue by installing version 4.7 and linking to it for the system to be able to access it by this way: apt-get install g++-4.7 (as root) ln -fs /usr/bin/g++-4.7 /usr/bin/g++ good luck. -D1W0U.
[Bug rtl-optimization/80481] New: Unoptimal additional copy instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80481 Bug ID: 80481 Summary: Unoptimal additional copy instructions Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: andrew.n.senkevich at gmail dot com Target Milestone: --- Created attachment 41242 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41242&action=edit test-case to reproduce Hi, as was found in pr78116 attached testcase (compiled with g++ -Ofast -fopenmp -funroll-loops -march=knl) have series of moves (1) which looks like can be avoided if set target register of previous vpermps (2) equal to move target register and rearrange order of vpermps, vmaxps according to data flow (f.e. (3) should be after (4)). .L26: vmaxps (%r10,%rax), %zmm15, %zmm1 vpermps (%rcx), %zmm9, %zmm2 (2) vmovaps %zmm2, %zmm14 (1) vpermps -64(%rcx), %zmm9, %zmm2(2) (3) vfnmadd132ps(%r14,%rax), %zmm12, %zmm14 leal4(%rsi), %esi vmaxps %zmm1, %zmm14, %zmm13 (4) vmovaps %zmm2, %zmm14 (1) vmaxps 64(%r10,%rax), %zmm15, %zmm1 vfnmadd132ps64(%r14,%rax), %zmm12, %zmm14 vpermps -128(%rcx), %zmm9, %zmm2 (2) cmpl%esi, %r11d vmovups %zmm13, (%r9,%rax) leaq-256(%rcx), %rcx vmaxps %zmm1, %zmm14, %zmm13 vmovaps %zmm2, %zmm14 (1) vmaxps 128(%r10,%rax), %zmm15, %zmm1 vfnmadd132ps128(%r14,%rax), %zmm12, %zmm14 vpermps 64(%rcx), %zmm9, %zmm2 (2) vmovups %zmm13, 64(%r9,%rax) vmaxps %zmm1, %zmm14, %zmm13 vmovaps %zmm2, %zmm14 (1) vmaxps 192(%r10,%rax), %zmm15, %zmm1 vfnmadd132ps192(%r14,%rax), %zmm12, %zmm14 vmovups %zmm13, 128(%r9,%rax) vmaxps %zmm1, %zmm14, %zmm13 vmovups %zmm13, 192(%r9,%rax) leaq256(%rax), %rax ja .L26 It is better visible without -funroll-loops: .L26: vpermps (%rcx), %zmm10, %zmm1 (2) leal1(%rsi), %esi vmovaps %zmm1, %zmm2 (1) vmaxps (%r15,%rdx), %zmm3, %zmm1 vfnmadd132ps(%r12,%rdx), %zmm7, %zmm2 cmpl%esi, %r8d leaq-64(%rcx), %rcx vmaxps %zmm1, %zmm2, %zmm1 vmovups %zmm1, (%rdi,%rdx) leaq64(%rdx), %rdx ja .L26
[Bug tree-optimization/78847] pointer arithmetic from c++ ranged-based for loop not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78847 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Apr 21 12:09:20 2017 New Revision: 247061 URL: https://gcc.gnu.org/viewcvs?rev=247061&root=gcc&view=rev Log: 2017-04-21 Richard Biener PR tree-optimization/78847 * fold-const.c (split_tree): Handle POINTER_PLUS_EXPR. * g++.dg/tree-ssa/pr78847.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr78847.C Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/78847] pointer arithmetic from c++ ranged-based for loop not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78847 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.0 Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed for GCC 8.
[Bug rtl-optimization/78116] [7/8 regression] Performance drop after r241173 on avx512 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116 --- Comment #18 from Andrew Senkevich --- Created pr80481.
[Bug fortran/79430] [7/8 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #63 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #62) > (In reply to Jürgen Reuter from comment #61) > > (In reply to Thomas Koenig from comment #60) > > > r242780 works. > > > > > > With both r243586 and r244391, plus the patch for r245191 > > > applied, I got numerous failures in the test suite. > > > > > > Apparently, something else was wrong for some time, which > > > blocks the attempt at bisection for that particular error > > > in that range. > > > > There was also this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79344 > > fixed in r245194. You don't apply any -fcheck= flags, right? > > No, I don't. > > I appear to have hit a wall in bisecting. > > I keep getting lots of failures in your test suite with additional > errors. Either I am doing something wrong in testing, or there > were indeed other errors present which keep the intermediate > versions from working. > > Could you re-check this, for exapmle by doing "svn update -r 243183" > in trunk, recompiling the compiler, and then running your testsuite > again? > > Or how could I just, with a single command, run the test case > you are interested in, without going through all the other tests? > > I am currently at a loss how to proceed. Darn Did you apply the patch from PR79344? You can run the single test if you go to the build folder, into the directory tests/functional_test and just do `make check TESTS=mlm_matching_isr.run`. This runs only this one single test. I tried to produce a smaller test case, but our setup explicitly creates, links and loads a dynamic library. This is rather hard to emulate. Whenever I tried to give the routines the input directly, the optimization seems to be gone.
[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80480 Abel Romero changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Abel Romero --- The OOM killer doesn't show any killing to process g++ . # dmesg | grep -i oom [6071354.290556] sshd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0 [6071354.290697] [] oom_kill_process+0x202/0x3c0 [6071354.290881] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6092958.118942] sshd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0 [6092958.119083] [] oom_kill_process+0x202/0x3c0 [6092958.119286] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6114741.218529] freshclam invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0 [6114741.218655] [] oom_kill_process+0x202/0x3c0 [6114741.218837] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6136104.105414] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [6136104.105553] [] oom_kill_process+0x202/0x3c0 [6136104.105738] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6157693.098063] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [6157693.098242] [] oom_kill_process+0x202/0x3c0 [6157693.098507] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6179343.973294] /usr/sbin/amavi invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0 [6179343.973434] [] oom_kill_process+0x202/0x3c0 [6179343.973639] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6200925.008085] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [6200925.008212] [] oom_kill_process+0x202/0x3c0 [6200925.008388] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6222509.488296] tail invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0 [6222509.488435] [] oom_kill_process+0x202/0x3c0 [6222509.488619] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6244171.974954] docker-proxy invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [6244171.975085] [] oom_kill_process+0x202/0x3c0 [6244171.975272] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6265735.007848] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [6265735.007976] [] oom_kill_process+0x202/0x3c0 [6265735.008211] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6287454.932900] docker-containe invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [6287454.933078] [] oom_kill_process+0x202/0x3c0 [6287454.933383] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6308984.614383] docker-containe invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [6308984.614520] [] oom_kill_process+0x202/0x3c0 [6308984.614701] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [6330490.947849] kworker/u2:2 invoked oom-killer: gfp_mask=0x2420848, order=0, oom_score_adj=0 [6330490.948021] [] oom_kill_process+0x202/0x3c0 [6330490.948486] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [11989690.430639] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [11989690.430773] [] oom_kill_process+0x202/0x3c0 [11989690.430959] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [15256553.392370] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [15256553.392481] [] oom_kill_process+0x202/0x3c0 [15256553.392682] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [15272895.669235] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [15272895.669355] [] oom_kill_process+0x202/0x3c0 [15272895.669587] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [15289024.964421] docker-containe invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [15289024.964537] [] oom_kill_process+0x202/0x3c0 [15289024.964724] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [15289107.045937] docker-containe invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [15289107.046049] [] oom_kill_process+0x202/0x3c0 [15289107.046211] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [15294500.163513] freshclam invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0 [15294500.163621] [] oom_kill_process+0x202/0x3c0 [15294500.163787] [
[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773 --- Comment #15 from PeteVine --- I don't have a cross-compiler built/installed. If you're positive the bug doesn't reproduce on your end (targeting generic or A5 codegen), then maybe it's about some interaction between gcc instrumentation and the slightly dated system libraries. I think my little A5->A53 experiment shows once the instrumented binary is built, it doesn't matter how the profile data is gathered.
[Bug tree-optimization/79547] duplicate strlen calls with same argument not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79547 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|8.0 | Resolution|--- |FIXED Status|RESOLVED|ASSIGNED Known to work|8.0 | Resolution|FIXED |--- --- Comment #7 from Richard Biener --- Fixed for GCC8. --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Apr 21 12:47:02 2017 New Revision: 247062 URL: https://gcc.gnu.org/viewcvs?rev=247062&root=gcc&view=rev Log: 2017-04-21 Richard Biener PR tree-optimization/79547 * tree-ssa-structalias.c (find_func_aliases_for_builtin_call): Handle strlen, strcmp, strncmp, strcasecmp, strncasecmp, memcmp, bcmp, strspn, strcspn, __builtin_object_size and __builtin_constant_p without any constraints. * gcc.dg/tree-ssa/strlen-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/strlen-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/79547] duplicate strlen calls with same argument not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79547 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|8.0 | Resolution|--- |FIXED Status|RESOLVED|ASSIGNED Known to work|8.0 | Resolution|FIXED |--- --- Comment #7 from Richard Biener --- Fixed for GCC8. --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Apr 21 12:47:02 2017 New Revision: 247062 URL: https://gcc.gnu.org/viewcvs?rev=247062&root=gcc&view=rev Log: 2017-04-21 Richard Biener PR tree-optimization/79547 * tree-ssa-structalias.c (find_func_aliases_for_builtin_call): Handle strlen, strcmp, strncmp, strcasecmp, strncasecmp, memcmp, bcmp, strspn, strcspn, __builtin_object_size and __builtin_constant_p without any constraints. * gcc.dg/tree-ssa/strlen-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/strlen-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80480 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-04-21 Ever confirmed|0 |1 --- Comment #4 from Markus Trippelsdorf --- If you want to report a memory hog, the please attach the preprocessed file in question. See: https://gcc.gnu.org/bugs/
[Bug fortran/80477] Polymorphic functions (thus operators) generates memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #2 from Stefano Zaghi --- A very kind and great Fortraner (Chris MacMackin) has just let me know that a very similar (or really the same) bug has been already reported (60913) here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60913 Probably my test is slightly more simple. I read that the other bug report is dated 2014: can I conclude that such a bug will need a long time to be fixed? Please, consider that this is not a "polemic" question: I consider all of you my superheros! However, this bug really stops me to use OOP thus I have to decide about my future work: without GNU I have no other compilers, thus if I will decide to invest more on OOP I have probably to left Fortran, probably for Julia... My best regards.
[Bug rtl-optimization/78116] [7/8 regression] Performance drop after r241173 on avx512 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116 amker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #19 from amker at gcc dot gnu.org --- (In reply to Andrew Senkevich from comment #18) > Created pr80481. Thanks very much, consider this one fixed then.
[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #9 from Alan Modra ---
The following doesn't fail, but the strcmp optimization doesn't trigger
either..
#include
#include
#include
int
main ()
{
#if 0
char str1[15];
char str2[15];
#else
const size_t len = 65536;
char *buf1, *buf2, *str1, *str2;
buf1 = mmap (NULL, 2 * len, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (buf1 == MAP_FAILED)
{
perror ("mmap failed");
return 0;
}
if (munmap (buf1 + len, len) < 0)
{
perror ("munmap failed");
return 0;
}
buf2 = mmap (NULL, 2 * len, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (buf2 == MAP_FAILED)
{
perror ("mmap failed");
return 0;
}
if (munmap (buf2 + len, len) < 0)
{
perror ("munmap failed");
return 0;
}
str1 = buf1 + len - 7;
str2 = buf2 + len - 7;
#endif
strcpy (str1, "abcdef");
strcpy (str2, "ABCDEF");
return strcmp (str1, str2);
}
For the #if 1 case, valgrind is complaining about the compare of two eight byte
words read from the stack, which indeed do have one uninitialized byte past the
string terminating zero. I don't believe it matters. (The generated asm looks
OK to me, but that might be because my brain has shut down for the night.)
[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80480 --- Comment #5 from Andreas Schwab --- (In reply to Abel Romero from comment #3) > The OOM killer doesn't show any killing to process g++ . That just means that the kernel log overflowed. Given the multitude of OOM messages your system is definitely far from having enough memory.
[Bug fortran/79430] [7/8 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #64 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #63) > (In reply to Thomas Koenig from comment #62) > > I am currently at a loss how to proceed. > > Darn Did you apply the patch from PR79344? Yes. What I get if I do > `make check TESTS=mlm_matching_isr.run`. == WHIZARD 2.4.1: tests/functional_tests/test-suite.log == # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 is FAIL: mlm_matching_isr.run == Running script ./mlm_matching_isr.run | Writing log to 'mlm_matching_isr.log' | (Logging turned off.) | Preloaded model: SM | Process library 'mlm_matching_isr_lib': initialized | Preloaded library: mlm_matching_isr_lib | Reading commands from file '../../share/tests/functional_tests/mlm_matching_isr.sin' | Switching to model 'SM', scheme 'default' ?logging => true ?openmp_logging = false ?vis_history = false ?integration_timer = false ?pacify = true + IDENTIFIER= u ** *** ERROR: This PDG-array variable is undefined at this point ** | (WHIZARD run continues) + IDENTIFIER= d ** *** ERROR: This PDG-array variable is undefined at this point ** | (WHIZARD run continues) [user variable] quark = PDG() + IDENTIFIER= U ** *** ERROR: This PDG-array variable is undefined at this point ** | (WHIZARD run continues) + IDENTIFIER= D This occurred between 242780 (OK) and 242981 (not OK). Oh well... maybe I will bisect that one first, to find out what went wrong there, and then another bisection to find out which patch fixed that, and then
[Bug target/80482] New: [7 Regression] vec_mul produces compilation error if 1 of its parms is const or volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80482
Bug ID: 80482
Summary: [7 Regression] vec_mul produces compilation error if 1
of its parms is const or volatile
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
If one (just one) of its parameters is const, volatile, or const volatile
vec_mul produces a compilation error. This occurs for gcc 7 but not 5 nor 6.
For example:
#include
void P() {
const volatile vector float cvva = vec_splats(0.00187682f);
volatile vector float vva = vec_splats(0.00187682f);
const vector float cva = vec_splats(0.00187682f);
vector float va = vec_splats(0.00187682f);
vector float dx = {1.0f, 2.0f, 3.0f, 4.0f};
vector float X1m0 = vec_mul(va, va);
vector float X2m0 = vec_mul(va, dx);
vector float X3m0 = vec_mul(dx, va);
vector float X1m1 = vec_mul(cva, cva);
vector float X2m1 = vec_mul(cva, dx);
vector float X3m1 = vec_mul(dx, cva);
vector float Y1m2 = vec_mul(vva, vva);
vector float Y2m2 = vec_mul(vva, dx);
vector float Y3m2 = vec_mul(dx, vva);
vector float X1m3 = vec_mul(cvva, cvva);
vector float X2m3 = vec_mul(cvva, dx);
vector float X3m3 = vec_mul(dx, cvva);
}
bii.c:16:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
vector float X2m1 = vec_mul(cva, dx);
^~
bii.c:17:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
vector float X3m1 = vec_mul(dx, cva);
^~
bii.c:20:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
vector float Y2m2 = vec_mul(vva, dx);
^~
bii.c:21:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
vector float Y3m2 = vec_mul(dx, vva);
^~
bii.c:24:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
vector float X2m3 = vec_mul(cvva, dx);
^~
bii.c:25:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
vector float X3m3 = vec_mul(dx, cvva);
^~
I tried a few of the other vec_XYZ built-ins and they do not produce the same
error (though I did not test them all).
Note that I am investigating this further.
[Bug fortran/79430] [7/8 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #65 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #64) > (In reply to Jürgen Reuter from comment #63) > > (In reply to Thomas Koenig from comment #62) > > > > I am currently at a loss how to proceed. > > > > Darn Did you apply the patch from PR79344? > > Yes. > > + IDENTIFIER= u > * > * > *** ERROR: This PDG-array variable is undefined at this point > * There is obviously something wrong. > Oh well... maybe I will bisect that one first, to find out what > went wrong there, and then another bisection to find out which patch > fixed that, and then There were 4 regressions ca. 12/2016 that I can remember that affected our code: 1) PR79229 which started in r241439 but affected only -fcheck=mem, fixed in r245581 2) PR79230, started with r243480, affected many tests generally, fixed in r245191 3) PR79344, started with r242875. affected many things, fixed in r245194. 4) this ugly one here. There is another one (PR80361), which is older, and affects only -fcheck=recursive. From what I can see these are all.
[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773 --- Comment #16 from PeteVine --- Also, I'd like to repeat the fact using -mcpu=cortex-a7 fixes the issue (no library calls present). Incidentally, having run that A7 profiled binary on a Cortex-A53, I'm seeing a 10% hit compared to a vanilla A7 binary. Hopefully that's just an artifact of profiling a different CPU architecture.
[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80480 Abel Romero changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Abel Romero --- I rebooted and it appears. Sorry. I didn't know that the kernel log gets overflowed. # dmesg | grep -i oom [ 33.073516] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-500 [ 33.073688] [] oom_kill_process+0x202/0x3c0 [ 33.074034] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name [ 240.201283] cc1plus invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0 [ 240.201490] [] oom_kill_process+0x202/0x3c0 [ 240.201684] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80480 Markus Trippelsdorf changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773 --- Comment #17 from wilco at gcc dot gnu.org --- (In reply to PeteVine from comment #16) > Also, I'd like to repeat the fact using -mcpu=cortex-a7 fixes the issue (no > library calls present). Cortex-A7 has hardware division so it doesn't emit library calls. > Incidentally, having run that A7 profiled binary on a Cortex-A53, I'm seeing > a 10% hit compared to a vanilla A7 binary. Hopefully that's just an artifact > of profiling a different CPU architecture. Well that sounds like the same issue. Note -fprofile-generate simple inserts counters in the generated code. In fact the generated code is practically identical between Cortex-A5 and Cortex-A7.
[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 --- Comment #22 from Ramana Radhakrishnan --- (In reply to Jakub Jelinek from comment #20) > BTW, the wording e.g. i386 backend has is: > inform (input_location, > "the ABI of passing structure with complex float" > " member has changed in GCC 4.4"); > In this arm/aarch64 case, the wording can't be as specific, because it isn't > all arguments of this type, but only some arguments of certain type (at some > positions; for some types like those that have more aligned static data > members it is all such positioned arguments, for others, e.g. the templates > where the alignment used to depend on instantiation vs. non-instantiation > something earlier, only some), but you should consider using inform rather > than warning for consistency, and you should mention the GCC version where > it has changed and maybe also print the type in the diagnostic, so that user > at least knows what type it is that is problematic (but as it is not > something as simple as in the i386 case, there should not be a single inform > per TU, but about each case this is encountered). > > Richard said we should defer RC1 till this is done, do you think you can > have a patch for both architectures written today, tested over the weekend, > so that we could do RC1 on Monday or Tuesday at latest? I'll see what I can do but it's going to be tough to finish that by today. > Is there an agreement in ARM that what the patch does (for aarch64, and > similar one for arm) is what the AAPCS says? I don't see agreement being reached until next week. Sorry about the delay but it's just bad timing unfortunately.
[Bug libstdc++/80316] std::promise treats no shared state as undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80316 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Fri Apr 21 14:49:19 2017 New Revision: 247064 URL: https://gcc.gnu.org/viewcvs?rev=247064&root=gcc&view=rev Log: PR libstdc++/80316 make promise::set_value throw no_state error PR libstdc++/80316 * include/std/future (_State_baseV2::_Setter::operator()): Remove _S_check calls that are done after the pointer to the shared state is already dereferenced. (_State_baseV2::_Setter<_Res, void>): Define specialization for void as partial specialization so it can be defined within the definition of _State_baseV2. (_State_baseV2::__setter): Call _S_check. (_State_baseV2::__setter(promise*)): Add overload for use by promise::set_value and promise::set_value_at_thread_exit. (promise, promise, promise): Make _State a friend. (_State_baseV2::_Setter): Remove explicit specialization. (promise::set_value, promise::set_value_at_thread_exit): Use new __setter overload. * testsuite/30_threads/promise/members/at_thread_exit2.cc: New test. * testsuite/30_threads/promise/members/set_exception.cc: Test promise and promise specializations. * testsuite/30_threads/promise/members/set_exception2.cc: Likewise. Test for no_state error condition. * testsuite/30_threads/promise/members/set_value2.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/30_threads/promise/members/at_thread_exit2.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/future trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception2.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_value2.cc
[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479 --- Comment #10 from acsawdey at gcc dot gnu.org --- OK, so I'm the culprit who added the strncmp/strcmp inline expansion. If both strings have alignment > 8 we cannot inadvertently cross a page boundary doing 8B loads. For any argument that has smaller alignment, it emits a runtime check to see if the inline code would cross a 4k boundary. If so, the library function call is used instead of the inline code. The testcase gcc.dg/strncmp-2.c tests that we don't step over this by allocating 2 pages and using mprotect PROT_NONE on the second, then trying to provoke things by putting strings right up to the boundary. The code generation for strncmp/strcmp is done by the same code in rs6000.c so testing strncmp for this mostly also tests whether strcmp has any issues. The generated comparison code, while it does use 8B loads, also makes use of cmpb to make sure that data beyond the 0 byte is not significant in the result. Startup: load two doublewords, are they equal? ldbrx 9,28,10 ldbrx 10,30,10 subf. 3,10,9 beq 0,.L23 If they are, go to this piece that looks to see if there was a zero byte: .L23: cmpb 10,9,3 cmpdi 7,10,0 beq 7,.L22 If we don't branch, the strings are equal, result of zero is in r3 and we are done. If we didn't branch to .L23 above, we fall through to this piece that computes the final result by finding the correct differing byte and subtracting: .L11: cmpb 3,9,10 cmpb 8,9,26 addi 31,31,1 orc 3,8,3 cntlzd 3,3 addi 3,3,8 rldcl 9,9,3,56 rldcl 3,10,3,56 subf 3,3,9 extsw 9,3 If we did go to .L22 then we have a repeating sequence like this to load and compare 8B at a time: .L22: addi 9,8,8 addi 10,4,8 ldbrx 9,0,9 ldbrx 10,0,10 subf. 3,10,9 bne 0,.L11 cmpb 10,9,3 cmpdi 7,10,0 bne 7,.L10 Here we either go to the L11 piece to extract the differing bytes and subtract, or we found a zero byte and strings are equal (r3=0) and bail out to L10. At the end of our 64 bytes of inline comparison we bail out to strcmp: addi 4,4,64 addi 3,8,64 bl strcmp So, yes we do read 8B at a time, but the code makes use of cmpb so that the bytes following the zero byte are never significant to the comparison. On the other hand I've already had to fix this a couple times so it is certainly possible that errors remain -- please do let me know if you see something.
[Bug c++/80179] [6/7/8 Regression] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80179 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Apr 21 19:26:54 2017 New Revision: 247067 URL: https://gcc.gnu.org/viewcvs?rev=247067&root=gcc&view=rev Log: PR c++/80179 - ICE with initialized flexible array member. * constexpr.c (verify_ctor_sanity): Handle flexible array members. Added: trunk/gcc/testsuite/g++.dg/ext/flexary24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug fortran/80484] New: Three syntax errors involving derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 Bug ID: 80484 Summary: Three syntax errors involving derived-type I/O Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: walt.brainerd at gmail dot com Target Milestone: --- Windows 10, gcc 7.0.1 20170416 If the commented versions of the USE or WRITE statements are used, the program works fine. The function B converts wage to a structure with one component. I can provide all the supporting code if needed, but that doesn't seem relevant. program test_b_format use b_format_mod, only: B, write (formatted) ! use b_format_mod implicit none real :: wage = 15.10 integer :: ios character(len=99) :: iom = "OK" ! write (unit=*, fmt="(DT'$$$Z.##')", iostat=ios, iomsg=iom) B(wage) write (unit=*, fmt="(2DT'$$$Z.##')", iostat=ios, iomsg=iom) B(wage) write (unit=*, fmt="(DT'$$$Z.##'/)", iostat=ios, iomsg=iom) B(wage) print *, trim(iom) end program test_b_format test_b_format.f90:3:47: use b_format_mod, only: B, write (formatted) 1 Error: Module nature in USE statement at (1) shall be either INTRINSIC or NON_INTRINSIC test_b_format.f90:12:36: write (unit=*, fmt="(2DT'$$$Z.##')", iostat=ios, iomsg=iom) B(wage) 1 Error: Unexpected element ''' in format string at (1) test_b_format.f90:13:35: write (unit=*, fmt="(DT'$$$Z.##'/)", iostat=ios, iomsg=iom) B(wage) 1 Error: Unexpected element '/' in format string at (1)
[Bug sanitizer/80349] [6 Regression] UBSAN: compile time crash with "type mismatch in binary expression" message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80349
--- Comment #7 from Dmitry Babokin ---
One more. GCC r247062.
> cat f.cpp
unsigned long int ll;
int foo() {
return (2036854775807 >> ll & char(207648476159223) | 502810590243120797UL)
<< 0;
}
> g++ -fsanitize=undefined -O0 -c f.cpp
f.cpp: In function ‘int foo()’:
f.cpp:2:5: error: type mismatch in binary expression
int foo() {
^~~
long unsigned int
long int
long unsigned int
D.2746 = _2 | 502810590243120797;
f.cpp:2:5: internal compiler error: verify_gimple failed
[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773 --- Comment #18 from PeteVine --- > Well that sounds like the same issue. > Note -fprofile-generate simple inserts counters in the generated code. In > fact the generated code is practically identical between Cortex-A5 and > Cortex-A7. As long as the gcda file is not present, -fprofile-use yields an equally good binary (obviously!), so clearly it's about the profile data somehow. If you have any ideas or debugging suggestions, go ahead, I'll gladly test them.
[Bug c++/80485] New: rejects-valid: constexpr static_cast of pointer-to-member-function to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
Bug ID: 80485
Summary: rejects-valid: constexpr static_cast of
pointer-to-member-function to bool
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
GCC rejects the following code (partly adapted from Boost's tribool), which I
think is valid:
struct dummy {
void nonnull() {};
};
typedef void (dummy::*safe_bool)();
constexpr safe_bool a = &dummy::nonnull;
static_assert( static_cast( a ), "" );
int main () { return 0; }
I'm compiling with -std=c++14 and I'm seeing these errors:
:9:1: error: non-constant condition for static assertion
static_assert( static_cast( a ), "" );
^
:9:16: error: '(dummy::nonnull != 0)' is not a constant expression
static_assert( static_cast( a ), "" );
^~
Compiler exited with result code 1
This code is accepted by Clang.
This looks related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71896 but
that has status "RESOLVED FIXED" but I'm seeing this on "GCC 7 (snapshot)" on
godbolt.org (see https://godbolt.org/g/JnrZss ) as well as on my GCC 6.2.0.
[Bug fortran/80392] [5/6/7/8 Regression] [OOP] ICE with allocatable polymorphic function result in a procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80392 --- Comment #5 from janus at gcc dot gnu.org --- Author: janus Date: Fri Apr 21 20:47:12 2017 New Revision: 247069 URL: https://gcc.gnu.org/viewcvs?rev=247069&root=gcc&view=rev Log: 2017-04-21 Janus Weil PR fortran/80392 * trans-types.c (gfc_get_derived_type): Prevent an infinite loop when building a derived type that includes a procedure pointer component with a polymorphic result. 2017-04-21 Janus Weil PR fortran/80392 * gfortran.dg/proc_ptr_comp_49.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_49.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/80486] New: spurious -Walloc-size-larger-than and -Wstringop-overflow in dominance.c during profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80486 Bug ID: 80486 Summary: spurious -Walloc-size-larger-than and -Wstringop-overflow in dominance.c during profiledbootstrap Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- A profiledbootstrap on powerpc64le and x86_64 shows a bunch of -Walloc-size-larger-than and -Wstringop-overflow warnings that don't show up otherwise. They also don't show when the C++ new expression the former warnings point is replaced with the libiberty XCNEWVEC and XNEWVEC macros. /src/gcc/trunk/gcc/dominance.c:303:0: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] edge_iterator *stack = new edge_iterator[m_n_basic_blocks + 1]; /src/gcc/trunk/gcc/dominance.c: In member function ‘calc_dfs_tree’: /src/gcc/trunk/libstdc++-v3/libsupc++/new:122:7: note: in a call to allocation function ‘operator new []’ declared here void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) ^ In function ‘new_zero_array’, inlined from ‘dom_init’ at /src/gcc/trunk/gcc/dominance.c:164:0, inlined from ‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at /src/gcc/trunk/gcc/dominance.c:194:0, inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0: /src/gcc/trunk/gcc/dominance.c:153:0: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] T *result = new T[num]; /src/gcc/trunk/gcc/dominance.c: In function ‘verify_dominators’: /src/gcc/trunk/libstdc++-v3/libsupc++/new:122:7: note: in a call to allocation function ‘operator new []’ declared here void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) ^ In function ‘new_zero_array’, inlined from ‘dom_init’ at /src/gcc/trunk/gcc/dominance.c:164:0, inlined from ‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at /src/gcc/trunk/gcc/dominance.c:194:0, inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0: /src/gcc/trunk/gcc/dominance.c:154:0: warning: ‘memset’: specified size between 18446744065119617024 and 18446744073709551612 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] memset (result, 0, sizeof (T) * num); In function ‘new_zero_array’, inlined from ‘dom_init’ at /src/gcc/trunk/gcc/dominance.c:165:0, inlined from ‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at /src/gcc/trunk/gcc/dominance.c:194:0, inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0: /src/gcc/trunk/gcc/dominance.c:153:0: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] T *result = new T[num]; /src/gcc/trunk/gcc/dominance.c: In function ‘verify_dominators’: /src/gcc/trunk/libstdc++-v3/libsupc++/new:122:7: note: in a call to allocation function ‘operator new []’ declared here void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) ^ In function ‘new_zero_array’, inlined from ‘dom_init’ at /src/gcc/trunk/gcc/dominance.c:165:0, inlined from ‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at /src/gcc/trunk/gcc/dominance.c:194:0, inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0: /src/gcc/trunk/gcc/dominance.c:154:0: warning: ‘memset’: specified size between 18446744065119617024 and 18446744073709551612 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] memset (result, 0, sizeof (T) * num); In member function ‘dom_init’, inlined from ‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at /src/gcc/trunk/gcc/dominance.c:194:0, inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0: /src/gcc/trunk/gcc/dominance.c:167:0: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] m_path_min = new TBB[num]; /src/gcc/trunk/gcc/dominance.c: In function ‘verify_dominators’: /src/gcc/trunk/libstdc++-v3/libsupc++/new:122:7: note: in a call to allocation function ‘operator new []’ declared here void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) ^ In member function ‘dom_init’, inlined from ‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at /src/gcc/trunk/gcc/dominance.c:194:0, inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0: /src/gcc/trunk/gcc/dominance.c:168:0: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] m_key = new TBB[num]; /src/gcc/
[Bug fortran/80361] [5/6/7/8 Regression] [OOP] bogus recursive call to nonrecursive procedure with -fcheck=recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361 --- Comment #25 from janus at gcc dot gnu.org --- Author: janus Date: Fri Apr 21 21:11:22 2017 New Revision: 247070 URL: https://gcc.gnu.org/viewcvs?rev=247070&root=gcc&view=rev Log: 2017-04-21 Janus Weil Backport from trunk PR fortran/80361 * class.c (generate_finalization_wrapper): Give the finalization wrapper the recursive attribute. 2017-04-21 Janus Weil Backport from trunk PR fortran/80361 * gfortran.dg/class_62.f90: New test case. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/class_62.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/class.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/80486] spurious -Walloc-size-larger-than and -Wstringop-overflow in dominance.c during profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80486 Martin Sebor changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Martin Sebor --- Configured with --disable-werror the warnings don't break boootstrap but they suggest a bug or limitation in GCC (especially since replacing the new expression with the equivalent libiberty macros eliminates the warnings).
[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221 --- Comment #16 from Tom de Vries --- Created attachment 41243 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41243&action=edit tentative patch implementing dg-save-linenr
[Bug target/80482] [7 Regression] vec_mul produces compilation error if 1 of its parms is const or volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80482 --- Comment #1 from seurer at gcc dot gnu.org --- I see the problem. The compiler is enforcing "the parameter types must match" too tightly. It should be checking the unqualified types (sans const/volatile) instead of the types directly.
[Bug middle-end/77671] missing -Wformat-overflow warning on sprintf overflow with "%s"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77671 --- Comment #5 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00968.html
[Bug fortran/80361] [5/6/7/8 Regression] [OOP] bogus recursive call to nonrecursive procedure with -fcheck=recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361 --- Comment #26 from janus at gcc dot gnu.org --- Author: janus Date: Fri Apr 21 21:37:16 2017 New Revision: 247071 URL: https://gcc.gnu.org/viewcvs?rev=247071&root=gcc&view=rev Log: 2017-04-21 Janus Weil Backport from trunk PR fortran/80361 * class.c (generate_finalization_wrapper): Give the finalization wrapper the recursive attribute. 2017-04-21 Janus Weil Backport from trunk PR fortran/80361 * gfortran.dg/class_62.f90: New test case. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/class_62.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/class.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/80361] [5/6/7/8 Regression] [OOP] bogus recursive call to nonrecursive procedure with -fcheck=recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #27 from janus at gcc dot gnu.org --- Fixed for the upcoming releases 7.0, 6.4 and 5.5. Closing.
[Bug fortran/80484] Three syntax errors involving derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-04-21 CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle --- I will have a look at these.
[Bug tree-optimization/80487] New: redundant memset/memcpy/strcpy calls not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80487
Bug ID: 80487
Summary: redundant memset/memcpy/strcpy calls not eliminated
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Somewhat similar to bug 79716 but (IIUC) with a different root cause, the
redundant clearing of the array prior to the call to strncpy in the following
function is not eliminated as it could be. (Strncpy is specified to append
NULs to fill the destination.)
$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c
void sink (void*);
void f (const char *s)
{
char a[256] = ""; // redundant initialization
__builtin_strncpy (a, s, sizeof a);
sink (a);
}
void g (const char *s)
{
char a[256];
__builtin_memset (a, 0, sizeof a); // redundant memset
__builtin_strncpy (a, s, sizeof a);
sink (a);
}
;; Function f (f, funcdef_no=0, decl_uid=1797, cgraph_uid=0, symbol_order=0)
f (const char * s)
{
char a[256];
[100.00%]:
a = "";
__builtin_strncpy (&a, s_3(D), 256);
sink (&a);
a ={v} {CLOBBER};
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1801, cgraph_uid=1, symbol_order=1)
g (const char * s)
{
char a[256];
[100.00%]:
__builtin_memset (&a, 0, 256);
__builtin_strncpy (&a, s_3(D), 256);
sink (&a);
a ={v} {CLOBBER};
return;
}
[Bug c++/80488] New: Erroneous error "lambda-expression in template argument"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80488
Bug ID: 80488
Summary: Erroneous error "lambda-expression in template
argument"
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Compile with -std=gnu++1z:
template using x = void;
using Y = x<+[]{}>;
The above code creates a lambda and then applies unary operator +, forcing it
to decay to a function pointer. Since that's constexpr, it should be a valid
template argument.
clang-trunk accepts this code.
[Bug fortran/80484] Three syntax errors involving derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #2 from Jerry DeLisle --- (In reply to Walt Brainerd from comment #0) > Windows 10, gcc 7.0.1 20170416 > > If the commented versions of the USE or WRITE statements > are used, the program works fine. > > The function B converts wage to a structure with one component. > > I can provide all the supporting code if needed, > but that doesn't seem relevant. > Yes, please provide. I need complete 'valid' code to test debug. I will eventually create a new test case for the testsuite. It is relevant because I need to reproduce exact conditions. Yes I could contrive something but I might miss something doing so.
[Bug fortran/80484] Three syntax errors involving derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #3 from Jerry DeLisle --- As an example of what I just said: $ gfc pr80484.f03 f951: internal compiler error: in gfc_match_use, at fortran/module.c:689 With no module defined. This is an unrelated bug I just stumbled on... with your example the original post here.
