[Bug rtl-optimization/78437] [7 Regression]: Invalid sign-extend conversion in REE pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78437 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-21 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Alpha is the only architecture both affected by PR rtl-optimization/59461 and enabling REE at -O2, but I presume that this could happen on others too.
[Bug rtl-optimization/78437] [7 Regression]: Invalid sign-extend conversion in REE pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78437 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #2 from Eric Botcazou --- Investigating.
[Bug fortran/78443] New: Incorrect behavior with non_overridable keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78443 Bug ID: 78443 Summary: Incorrect behavior with non_overridable keyword Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: perini at wisc dot edu Target Milestone: --- Created attachment 40094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40094&action=edit Minimal program to test the non_overridable keyword issue Hi, I've been having some issues recently when using the non_overridable keyword on an extended derived type, with gfortran 5.3.0 and 6.1.0. In essence, when the non_overridable function is called from: - A type which extends an abstract type -> segmentation fault (looks like call to null function pointer); - A type which extends a non-abstract type -> call the parent's function instead than the own function. "Modern Fortran" by Metcalf Reid Cohen states: - If the non_overridable attribute appears, that type-bound procedure cannot be overridden during type extension; - non_overridable is incompatible with deferred, since that requires the type-bound procedure to be overridden; - Overriding a type-bound procedure is not permitted if the inherited one has the non_overridable attribute So I'm guessing that using the non_overridable keyword in a non-abstract extended type should be OK and prevent the function being overridden in further type extensions. A bit more discussion has taken place in http://stackoverflow.com/questions/40510423/segmentation-fault-with-deferred-functions-and-non-overridable-keyword The attached code reproduces the error. Thanks for the great work on gfortran! Federico
[Bug target/78438] [7 Regression] incorrect comparison optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78438
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-11-21
CC||jakub at gcc dot gnu.org
Target Milestone|--- |7.0
Summary|incorrect comparison|[7 Regression] incorrect
|optimization|comparison optimization
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started with r242414.
Simplified testcase:
char a = 0;
int b = 197412621;
__attribute__ ((noinline, noclone))
void foo ()
{
a = 0 > (short) (b >> 11);
}
int
main ()
{
asm volatile ("" : : : "memory");
foo ();
if (a != 0)
__builtin_abort ();
return 0;
}
[Bug target/78438] [7 Regression] incorrect comparison optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78438
--- Comment #2 from Jakub Jelinek ---
Before combine we have:
(insn 6 5 7 2 (parallel [
(set (reg:SI 92)
(ashiftrt:SI (reg:SI 93 [ b ])
(const_int 11 [0xb])))
(clobber (reg:CC 17 flags))
]) "pr78438.c":7 563 {*ashrsi3_1}
(expr_list:REG_DEAD (reg:SI 93 [ b ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ashiftrt:SI (mem/c:SI (symbol_ref:DI ("b")
[flags 0x2] ) [1 b+0 S4 A32])
(const_int 11 [0xb]))
(nil)
(insn 7 6 8 2 (parallel [
(set (reg:HI 94)
(lshiftrt:HI (subreg:HI (reg:SI 92) 0)
(const_int 15 [0xf])))
(clobber (reg:CC 17 flags))
]) "pr78438.c":7 572 {*lshrhi3_1}
(expr_list:REG_DEAD (reg:SI 92)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
combine turns that into non-equivalent:
(insn 7 6 8 2 (parallel [
(set (reg:SI 94)
(ashiftrt:SI (reg:SI 93 [ b ])
(const_int 26 [0x1a])))
(clobber (reg:CC 17 flags))
]) "pr78438.c":7 563 {*ashrsi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:SI 93 [ b ])
(nil
[Bug target/78426] [7 Regression] wrong code with strncmp on SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78426 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/78427] missed optimization of loop condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78427 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-21 CC||amker.cheng at gmail dot com Component|c++ |tree-optimization Ever confirmed|0 |1 Known to fail||7.0 --- Comment #3 from Richard Biener --- Confirmed. IVOPTs job in this case (it's not simple loop reversal). Basically what is missing is a candidate for the desired IV, hopefully costs would then make that the cheapest in the end.
[Bug tree-optimization/78428] [5/6/7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 64-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78428 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.9.4 Version|unknown |6.2.1 Keywords||wrong-code Last reconfirmed||2016-11-21 Ever confirmed|0 |1 Summary|wrong code at -O2 and -O3 |[5/6/7 Regression] wrong |on x86_64-linux-gnu in |code at -O2 and -O3 on |64-bit mode |x86_64-linux-gnu in 64-bit ||mode Target Milestone|--- |5.5 Known to fail||5.4.0, 7.0 --- Comment #1 from Richard Biener --- Confirmed. GCC 6 seems to work for me.
[Bug tree-optimization/78429] [7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-21 Component|c |tree-optimization Known to work||6.2.0 Target Milestone|--- |7.0 Summary|ice on valid C code on |[7 Regression] ice on valid |x86_64-linux-gnu at -O3 in |C code on x86_64-linux-gnu |both 32-bit and 64-bit |at -O3 in both 32-bit and |modes (internal compiler|64-bit modes (internal |error: in set_value_range, |compiler error: in |at tree-vrp.c:361) |set_value_range, at ||tree-vrp.c:361) Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug libstdc++/78430] libstc++-v3 Build failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78430 Richard Biener changed: What|Removed |Added Keywords||build Target||mips-elf Host||x86_64-linux --- Comment #2 from Richard Biener --- You can --disable-libcc1 at configure time, it's only used by gdb.
[Bug target/78444] New: Wrong prologue stack alignment for implicit dtor on x86_64-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
Bug ID: 78444
Summary: Wrong prologue stack alignment for implicit dtor on
x86_64-darwin*
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 40095
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40095&action=edit
stand-alone reproducer (c++11)
-std=c++11 -fno-exceptions -fno-rtti
In this code, there's an implict dtor which calls a base class dtor. The stack
is incorrectly aligned at the call to the second dtor (leading to dyld
complaining and aborting the code).
.globl __ZN4llvm2cl6parserIjED1Ev
.weak_definition __ZN4llvm2cl6parserIjED1Ev
__ZN4llvm2cl6parserIjED1Ev:
LFB15:
pushq %rbp
LCFI21:
movq%rsp, %rbp
LCFI22:
subq$8, %rsp
movq%rdi, -8(%rbp)
movq-8(%rbp), %rax
movq%rax, %rdi
call__ZN4llvm2cl12basic_parserIjED2Ev
leave
LCFI23:
ret
LFE15:
=
AFAICT has been present since c++11 introduction in 4.7 (so seems to be an
infrequently triggered issue).
I can't see any particular reason why this is Darwin-specific (the x86_64 code
in the back end has very little Darwin conditional code). However, it looks
like Linux clones the dtor (_ZN4llvm2cl6parserIjED2Ev) and generates correct
prologue code for that. So it's not clear if this is Darwin-specific, or just
that the fail conditions are only triggered for Darwin.
Looking at the tree dumps, the dtors look like regular weak hidden functions.
Looking at the incoming state to ix86_expand_prologue, it seems that the
function is expecting the stack_alignment_needed to be already set to a valid
amount.
with some debug code at the entry of ix86_expand_prologue():
$ ./prev-gcc/xg++ -Bprev-gcc -fno-exceptions -fno-rtti
/Volumes/sc3_src/test-cxx/prologue-x86-64-bug.C -S
_ZN4llvm2cl6OptionD2Ev : is leaf Y incoming 128 set align_needed 64 realign N
_ZN4llvm2cl12basic_parserIjED2Ev : is leaf Y incoming 128 set align_needed 64
realign N
_ZN4llvm2cl12basic_parserIjED1Ev : is leaf Y incoming 128 set align_needed 64
realign N
_ZN4llvm2cl3optIjLb0ENS0_6parserIjEEE16handleOccurrenceEjNS_9StringRefES5_ : is
leaf Y incoming 128 set align_needed 64 realign N
_ZNK4llvm2cl3optIjLb0ENS0_6parserIjEEE16printOptionValueEjb : is leaf Y
incoming 128 set align_needed 64 realign N
_ZN4llvm2cl6parserIjED1Ev : is leaf N incoming 128 set align_needed 64 realign
N
_ZN4llvm2cl3optIjLb0ENS0_6parserIjEEED1Ev : is leaf N incoming 128 set
align_needed 128 realign N
_ZN4llvm2cl3optIjLb0ENS0_6parserIjEEED0Ev : is leaf N incoming 128 set
align_needed 128 realign N
Notice that _ZN4llvm2cl6parserIjED1Ev is not a leaf function, but only claims
to need 64b alignment.
If I hack the following into ix86_finalize_stack_realign_flags()
if (TARGET_MACHO && TARGET_64BIT && !crtl->is_leaf)
{
/* Darwin needs at least 128b alignment at function calls. */
crtl->stack_alignment_needed = crtl->stack_alignment_needed < 128
? 128
: crtl->stack_alignment_needed;
crtl->preferred_stack_boundary = crtl->preferred_stack_boundary < 128
? 128
: crtl->preferred_stack_boundary;
}
it works around the issue.
So the questions are;
1. are preceding phases (e.g. cfgexpand) supposed to make target callbacks that
get this right?
2. is something missing in the pro/epilogue that's supposed to detect this case
and fix it up?
[Bug target/78436] [7 Regression] incorrect write to larger-than-type bitfield (signed char x:9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78436
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-11-21
CC||jakub at gcc dot gnu.org,
||ktkachov at gcc dot gnu.org
Target Milestone|--- |7.0
Summary|incorrect write to |[7 Regression] incorrect
|larger-than-type bitfield |write to larger-than-type
|(signed char x:9) |bitfield (signed char x:9)
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started with the introduction of the store merging pass: r241649.
struct S {
long int : 23;
long int a : 24;
long int b : 10;
long int c : 24;
signed char d : 9;
} s;
__attribute__((noinline, noclone)) void
foo ()
{
s.d = 0;
s.c = -1193165L;
}
int
main ()
{
foo ();
if (s.d != 0)
__builtin_abort ();
return 0;
}
store-merging pass turns:
s.d = 0;
s.c = -1193165;
into:
MEM[(struct S *)&s + 8B] = 4293774131;
[Bug target/78444] Wrong prologue stack alignment for implicit dtor on x86_64-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444 Iain Sandoe changed: What|Removed |Added Keywords||wrong-code Target||x86_64-apple-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-21 Ever confirmed|0 |1 Known to fail||4.7.4, 4.8.5, 4.9.4, 5.4.0, ||6.2.0, 7.0
[Bug target/78436] [7 Regression] incorrect write to larger-than-type bitfield (signed char x:9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78436 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'll have a look.
[Bug tree-optimization/78435] bogus array subscript warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78435 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED Component|middle-end |tree-optimization Resolution|--- |INVALID --- Comment #1 from Richard Biener --- (gdb) p debug_generic_expr (ref) work[98] : _40 = strlen (&work); _41 = (unsigned int) _40; _42 = _41 + 1; size_43 = (int) _42; if (size_43 > 99) goto ; else goto ; : size_65 = ASSERT_EXPR 99>; work[98] = 0; Before inlining (knowing buffersize == 99) we have : _10 = strlen (&work); _11 = (unsigned int) _10; _12 = _11 + 1; size_48 = (int) _12; if (size_48 > buffersize_49(D)) goto ; else goto ; : _13 = buffersize_49(D) + -1; work[_13] = 0; but 'work' is [0, 27]. So clearly the code is bogus (even if we warn on dead code).
[Bug target/78436] [7 Regression] incorrect write to larger-than-type bitfield (signed char x:9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78436 --- Comment #3 from Richard Biener --- Hmm, maybe it's DECL_SIZE (of the FIELD_DECL) vs. TYPE_PRECISION mismatch not honored by store merging (I can very well think of other places having the same confusion...).
[Bug target/78439] [7 Regression] error: insn does not satisfy its constraints (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78439 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug target/78438] [7 Regression] incorrect comparison optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78438
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Jakub Jelinek ---
The over-sized bitfield isn't really needed for this, making it more severe:
struct S {
long int : 23;
long int a : 24;
long int b : 10;
long int c : 24;
signed char d : 8;
} s;
__attribute__((noinline, noclone)) void
foo ()
{
s.d = 0;
s.c = -1193165L;
}
int
main ()
{
foo ();
if (s.d != 0)
__builtin_abort ();
return 0;
}
[Bug target/78436] [7 Regression] incorrect write to larger-than-type bitfield (signed char x:9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78436 --- Comment #4 from ktkachov at gcc dot gnu.org --- Assignment of negative values to signed bitfields has caused me some headaches in encode_tree_to_bitpos due to native_encode_expr sign-extending the value to GET_MODE_SIZE (TYPE_MODE (...)) bytes, making it necessary to truncate the excess padding introduced. Maybe there's a but g in that logic
[Bug target/78445] New: [7 Regression] ICE in maybe_gen_insn, at optabs.c:7014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78445
Bug ID: 78445
Summary: [7 Regression] ICE in maybe_gen_insn, at optabs.c:7014
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
gcc-7.0.0-alpha20161120 snapshot ICEs when compiling the following reduced
snippet w/ -O2 (-O3, -Ofast) -mavx2 -ftree-loop-if-convert -ftree-vectorize:
int gp;
void
s3 (int io)
{
int *nz = gp;
while (gp != 0)
if (io != 0)
{
*nz = gp;
io = *nz;
}
else
io = gp;
}
% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20161120 -mavx2 -O2 -ftree-loop-if-convert
-ftree-vectorize -w -c hwbr0lsy.c
hwbr0lsy.c: In function 's3':
hwbr0lsy.c:11:13: internal compiler error: in maybe_gen_insn, at optabs.c:7014
*nz = gp;
^~~~
[Bug middle-end/78433] [7 Regression] glibc posix/execvpe.c gets miscompiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433 --- Comment #5 from Dominik Vogt --- Is that with any specific version of Glibc?
[Bug target/78438] [7 Regression] incorrect comparison optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78438 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #4 from Jakub Jelinek --- Oops, #c3 was meant for PR78436.
[Bug target/78436] [7 Regression] incorrect write to larger-than-type bitfield (signed char x:9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78436
--- Comment #5 from Jakub Jelinek ---
The over-sized bitfield isn't really needed for this, making it more severe:
struct S {
long int : 23;
long int a : 24;
long int b : 10;
long int c : 24;
signed char d : 8;
} s;
__attribute__((noinline, noclone)) void
foo ()
{
s.d = 0;
s.c = -1193165L;
}
int
main ()
{
foo ();
if (s.d != 0)
__builtin_abort ();
return 0;
}
Indeed, I think the bug is in encode_tree_to_bitpos, still debugging where
exactly.
[Bug target/78439] [7 Regression] error: insn does not satisfy its constraints (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78439 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-21 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. Will try to reduce
[Bug middle-end/78433] [7 Regression] glibc posix/execvpe.c gets miscompiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433 --- Comment #6 from Markus Trippelsdorf --- (In reply to Dominik Vogt from comment #5) > Is that with any specific version of Glibc? I was using trunk.
[Bug tree-optimization/78436] [7 Regression] incorrect write to larger-than-type bitfield (signed char x:9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78436 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Component|target |tree-optimization
[Bug middle-end/78433] [7 Regression] glibc posix/execvpe.c gets miscompiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433 --- Comment #7 from Markus Trippelsdorf --- To reproduce build glibc with -O3 and then run "make check". Or directly: ~ % ~/glibc_build/elf/ld.so --library-path /home/trippels/glibc_build/ ~/glibc_build/posix/tst-vfork3
[Bug target/78439] [7 Regression] error: insn does not satisfy its constraints (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78439
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Reduced testcase:
enum demangle_component_type
{
DEMANGLE_COMPONENT_THROW_SPEC
};
struct demangle_component
{
enum demangle_component_type type;
struct
{
struct
{
struct demangle_component *left;
struct demangle_component *right;
};
};
};
int a, b;
struct d_info
{
struct demangle_component *comps;
int next_comp;
int num_comps;
struct demangle_component *subs;
int num_subs;
int is_conversion;
};
void
fn1 (int p1, struct d_info *p2)
{
p2->num_comps = 2 * p1;
p2->next_comp = p2->num_subs = p1;
p2->is_conversion = 0;
}
int fn3 (int *);
void fn4 (struct d_info *, int);
void
fn2 ()
{
int c;
struct d_info d;
b = 0;
c = fn3 (&a);
fn1 (c, &d);
struct demangle_component e[d.num_comps];
struct demangle_component *f[d.num_subs];
d.comps = e;
d.subs = f;
fn4 (&d, 1);
}
Command line to reproduce:
-O2 -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -mtune=cortex-a8
[Bug tree-optimization/78436] [7 Regression] incorrect write to larger-than-type bitfield (signed char x:9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78436 --- Comment #6 from Jakub Jelinek --- Created attachment 40096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40096&action=edit gcc7-pr78436.patch Untested fix. Most of the changes are just nits I ran into when debugging, the real fix is that byte_size is apparently intentionally 1 byte larger than the mode size, so that shifting by 0 to BITS_PER_UNIT - 1 has the extra byte to shift into. But when not shifting, we IMHO need to subtract that extra + 1 back.
[Bug middle-end/78433] [7 Regression] glibc posix/execvpe.c gets miscompiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433 --- Comment #8 from Dominik Vogt --- This code from maybe_script_execute() writes past the allocated array bounds: /* Construct an argument list for the shell. */ char *new_argv[argc + 1]; new_argv[0] = (char *) _PATH_BSHELL; new_argv[1] = (char *) file; if (argc > 1) memcpy (new_argv + 2, argv + 1, argc * sizeof(char *)); ^ ^^ else new_argv[2] = NULL; ^^^ Before the patch, Gcc often allocated several bytes more than necessary so that many off-by-one bugs went unnoticed.
[Bug c++/47877] -fvisibility-inlines-hidden does not hide member template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47877
Richard Biener changed:
What|Removed |Added
Keywords||documentation
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-11-21
CC|rguenther at suse dot de |jason at gcc dot
gnu.org,
||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Confirmed. It looks like template instantiation somehow ends up using the
explicitely specified visibility from the class. When
determine_visibility_from_class is called for the template
determine_hidden_inline () is false because of the processing_template_decl
check. So the behavior is clearly on purpose and thus a documentation
issue(?):
/* Returns true iff DECL is an inline that should get hidden visibility
because of -fvisibility-inlines-hidden. */
static bool
determine_hidden_inline (tree decl)
{
return (visibility_options.inlines_hidden
/* Don't do this for inline templates; specializations might not be
inline, and we don't want them to inherit the hidden
visibility. We'll set it here for all inline instantiations. */
&& !processing_template_decl
&& TREE_CODE (decl) == FUNCTION_DECL
&& DECL_DECLARED_INLINE_P (decl)
&& (! DECL_LANG_SPECIFIC (decl)
|| ! DECL_EXPLICIT_INSTANTIATION (decl)));
}
so the reason is along non-inline specializations (not sure why we'd want to
avoid mixed visibility here).
[Bug tree-optimization/78435] bogus array subscript warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78435
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2 from Martin Liška ---
I have a simplified source code (easier to read):
char *result;
#define SIZE 100
int main()
{
char buffer[SIZE];
int limit = 100;
__builtin_snprintf (buffer, SIZE, "%d", 12345);
if (__builtin_strlen (buffer) > limit)
buffer[limit] = '\0';
result = __builtin_strdup (buffer);
}
[Bug middle-end/78445] [7 Regression] ICE in maybe_gen_insn, at optabs.c:7014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78445 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-21 Component|target |middle-end Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak --- Confirmed, middle-end tries (and fails) to expand scalar maskstore optab. (gdb) bt #0 internal_error (gmsgid=0x2232ce5 "in %s, at %s:%d") at ../../git/gcc/gcc/diagnostic.c:1379 #1 0x01a44c9b in fancy_abort (file=0x1b97c60 "../../git/gcc/gcc/optabs.c", line=7013, function=0x1b9800d "maybe_gen_insn") at ../../git/gcc/gcc/diagnostic.c:1447 #2 0x00cc9110 in maybe_gen_insn (icode=CODE_FOR_nothing, nops=3, ops=0x7fffc310) at ../../git/gcc/gcc/optabs.c:7013 #3 0x00cc9651 in maybe_expand_insn (icode=CODE_FOR_nothing, nops=3, ops=0x7fffc310) at ../../git/gcc/gcc/optabs.c:7057 #4 0x00cc969b in expand_insn (icode=CODE_FOR_nothing, nops=3, ops=0x7fffc310) at ../../git/gcc/gcc/optabs.c:7088 #5 0x00b6e7fe in expand_mask_store_optab_fn (stmt=0x2e90bb28, optab=maskstore_optab) at ../../git/gcc/gcc/internal-fn.c:2193 #6 0x00b6e820 in expand_MASK_STORE (fn=IFN_MASK_STORE, stmt=0x2e90bb28) at ../../git/gcc/gcc/internal-fn.def:91 #7 0x00b6509b in expand_internal_call (fn=IFN_MASK_STORE, stmt=0x2e90bb28) at ../../git/gcc/gcc/internal-fn.c:2649 #8 0x00b6511c in expand_internal_call (stmt=0x2e90bb28) at ../../git/gcc/gcc/internal-fn.c:2657 (gdb) f 5 #5 0x00b6e7fe in expand_mask_store_optab_fn (stmt=0x2e90bb28, optab=maskstore_optab) at ../../git/gcc/gcc/internal-fn.c:2193 2193 3, ops); (gdb) list 2188 create_fixed_operand (&ops[0], mem); 2189 create_input_operand (&ops[1], reg, TYPE_MODE (type)); 2190 create_input_operand (&ops[2], mask, TYPE_MODE (TREE_TYPE (maskt))); 2191 expand_insn (convert_optab_handler (optab, TYPE_MODE (type), 2192 TYPE_MODE (TREE_TYPE (maskt))), 2193 3, ops); 2194} 2195 2196static void 2197expand_ABNORMAL_DISPATCHER (internal_fn, gcall *) (gdb) p debug_rtx (mem) (mem:SI (reg/v/f:DI 89 [ nz ]) [1 *nz_8+0 S4 A32]) $1 = void (gdb) p debug_rtx (reg) (reg:SI 88 [ prephitmp_5 ]) $2 = void (gdb) p debug_rtx (mask) (reg:QI 95) $3 = void
[Bug c++/78446] New: Ambiguous member lookup for operator() in a function call expression treated as hard error in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78446
Bug ID: 78446
Summary: Ambiguous member lookup for operator() in a function
call expression treated as hard error in SFINAE
context
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Reduced from http://stackoverflow.com/q/40706399/2756719:
struct A { void operator()(); };
struct B { void operator()(); };
struct C : A, B {};
template
decltype(T()()) foo(int);
template int foo(...);
using type = decltype(foo(0));
using type = int;
produces:
prog.cc: In substitution of 'template decltype (T()()) foo(int) [with
T = C]':
prog.cc:10:31: required from here
prog.cc:6:13: error: request for member 'operator()' is ambiguous
decltype(T()()) foo(int);
~~~^~
prog.cc:2:17: note: candidates are: void B::operator()()
struct B { void operator()(); };
^~~~
prog.cc:1:17: note: void A::operator()()
struct A { void operator()(); };
^~~~
prog.cc: In substitution of 'template decltype (T()()) foo(int) [with
T = C]':
prog.cc:10:31: required from here
prog.cc:6:13: error: request for member 'operator()' is ambiguous
decltype(T()()) foo(int);
~~~^~
prog.cc:2:17: note: candidates are: void B::operator()()
struct B { void operator()(); };
^~~~
prog.cc:1:17: note: void A::operator()()
struct A { void operator()(); };
^~~~
(Yes, the error messages are repeated, see
http://melpon.org/wandbox/permlink/nZj4Wn9ZgFMMm63l)
Surprisingly enough, using 'decltype(T().operator()())' compiles
(http://melpon.org/wandbox/permlink/2sJ0ZGcA4ZIvqfvn), so it seems that this
doesn't affect all name lookup, only when the overloaded operator() is used by
a function call expression.
[Bug middle-end/78433] [7 Regression] glibc posix/execvpe.c gets miscompiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433 --- Comment #9 from Dominik Vogt --- ... and I think the buffer allocated in __execvpe() is also one byte too small: char buffer[path_len + file_len + 1]; ... char *pend = mempcpy (buffer, p, subp - p); <-- path_len *pend = '/'; <-- path_len + 1 memcpy (pend + (p < subp), file, file_len + 1); <-- path_len + file_len + 2
[Bug middle-end/67335] [6/7 Regression] ICE in compiling omp simd function with unused argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67335 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 40097 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40097&action=edit gcc7-pr67335.patch Untested fix.
[Bug target/78439] [7 Regression] error: insn does not satisfy its constraints (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78439 --- Comment #3 from ktkachov at gcc dot gnu.org --- The ICE happens due to r242590. Need to figure out if it is the cause of the bug or just exposes it
[Bug middle-end/78433] [7 Regression] glibc posix/execvpe.c gets miscompiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED URL||https://sourceware.org/bugz ||illa/show_bug.cgi?id=20847 Resolution|--- |INVALID --- Comment #10 from Markus Trippelsdorf --- Thanks Dominik. Andreas has reopened the glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20847
[Bug tree-optimization/78396] [7 regression] gcc.dg/vect/bb-slp-cond-1.c FAILs after fix for PR77848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78396
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 from Richard Biener ---
Something like the following looks most reasonable (testcase needs adjustment
to scan the "vect" dump of course):
diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
index 35d7a3e..8c06725 100644
--- a/gcc/tree-vectorizer.c
+++ b/gcc/tree-vectorizer.c
@@ -540,6 +540,7 @@ vectorize_loops (void)
|| loop->force_vectorize)
{
loop_vec_info loop_vinfo, orig_loop_vinfo = NULL;
+ gimple *loop_vectorized_call = vect_loop_vectorized_call (loop);
vectorize_epilogue:
vect_location = find_loop_location (loop);
if (LOCATION_LOCUS (vect_location) != UNKNOWN_LOCATION
@@ -558,6 +559,32 @@ vectorize_epilogue:
if (loop_constraint_set_p (loop, LOOP_C_FINITE))
vect_free_loop_info_assumptions (loop);
+ /* If we applied if-conversion then try to vectorize the
+ BB of innermost loops.
+ ??? Ideally BB vectorization would learn to vectorize
+ control flow by applying if-conversion on-the-fly, the
+ following retains the if-converted loop body even when
+ only non-if-converted parts took part in BB vectorization. */
+ if (loop_vectorized_call
+ && ! loop->inner)
+ {
+ basic_block bb = loop->header;
+ for (gimple_stmt_iterator gsi = gsi_start_bb (bb);
+!gsi_end_p (gsi); gsi_next (&gsi))
+ {
+ gimple *stmt = gsi_stmt (gsi);
+ gimple_set_uid (stmt, -1);
+ gimple_set_visited (stmt, false);
+ }
+ if (vect_slp_bb (bb))
+ {
+ dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
+"basic block vectorized\n");
+ fold_loop_vectorized_call (loop_vectorized_call,
+ boolean_true_node);
+ ret |= TODO_cleanup_cfg;
+ }
+ }
continue;
}
@@ -575,7 +602,6 @@ vectorize_epilogue:
break;
}
- gimple *loop_vectorized_call = vect_loop_vectorized_call (loop);
if (loop_vectorized_call)
set_uid_loop_bbs (loop_vinfo, loop_vectorized_call);
if (LOCATION_LOCUS (vect_location) != UNKNOWN_LOCATION
[Bug rtl-optimization/78437] [7 Regression]: Invalid sign-extend conversion in REE pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78437 --- Comment #3 from Eric Botcazou --- Created attachment 40098 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40098&action=edit Tentative fix It only affects Alpha (by default) but I no longer have access to Alpha hardware so I'm going to play with it on SPARC. Its effect on the assembly code on Alpha is: --- pr78437_1.s 2016-11-21 11:54:33.678363106 +0100 +++ pr78437_2.s 2016-11-21 11:54:40.230542615 +0100 @@ -62,7 +62,7 @@ ldbu $7,max($5) !gprellow sextb $8,$3 stb $8,expected($2) !gprellow - mov $3,$22 + bis $31,$8,$22 sextb $7,$7 cmpeq $3,$7,$3 beq $3,$L4 FWIW the change for PR rtl-opt/59461 eliminated 2 redundant extensions.
[Bug target/78439] [7 Regression] error: insn does not satisfy its constraints (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78439
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot
gnu.org
--- Comment #4 from ktkachov at gcc dot gnu.org ---
Hmm, this looks like a bug exposed by that patch.
The peephole2 pass does something weird.
We have:
(insn 13 33 40 2 (set (mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -28 [0xffe4])) [3 d.num_comps+0 S4 A64])
(reg:SI 12 ip [orig:117 _20 ] [117])) "cp-demangle.c":32 632
{*arm_movsi_vfp}
(expr_list:REG_DEAD (reg:SI 12 ip [orig:117 _20 ] [117])
(nil)))
(insn 40 13 39 2 (set (mem/f/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -24 [0xffe8])) [2 d.subs+0 S4 A32])
(reg/f:SI 13 sp)) "cp-demangle.c":51 632 {*arm_movsi_vfp}
(nil))
being turned into:
(insn 68 33 39 2 (set (mem/c:DI (plus:SI (reg/f:SI 11 fp)
(const_int -28 [0xffe4])) [3 d.num_comps+0 S8 A64])
(reg:DI 12 ip)) "cp-demangle.c":51 -1
(nil))
which is not recognisable.
Something dodgy with the store-multiple peepholes I think
[Bug c++/78073] inherited initializer_list constructor is not accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78073
Andrey Zholos changed:
What|Removed |Added
CC||a...@q-fu.com
--- Comment #2 from Andrey Zholos ---
I think the below code triggers the same bug. But it seems to be fixed in
latest trunk.
// -std=c++1z
struct A {
A(int, int) {}
};
struct B : A {
using A::A;
};
B b{1, 2};
[Bug sanitizer/69278] Confusion option handling for -sanitize-recovery=alll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69278 --- Comment #3 from Martin Liška --- I've just verified that clang 3.8.1 emits *_noabort calls with -fsanitize-recover=all: $ clang++ -fsanitize=address -fsanitize-recover=all /tmp/leak.c -S ; grep store leak.s callq __asan_report_store4_noabort Thus, do we want to change the behavior for GCC 7.1?
[Bug rtl-optimization/78447] New: [7 Regression] wrong code when combine changes shifts by << 5 and >> 15 to >> 10 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78447
Bug ID: 78447
Summary: [7 Regression] wrong code when combine changes shifts
by << 5 and >> 15 to >> 10 at -O
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Created attachment 40099
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40099&action=edit
reduced testcase
Output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
$ ./a.out
Aborted
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-242583-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-242583-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161118 (experimental) (GCC)
Before .combine:
...
(insn 9 8 10 2 (parallel [
(set (reg:SI 108)
(ashift:SI (reg/v:SI 105 [ xD.1799 ])
(const_int 5 [0x5])))
(clobber (reg:CC 17 flags))
]) "testcase.c":13 529 {*ashlsi3_1}
(expr_list:REG_DEAD (reg/v:SI 105 [ xD.1799 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
...
(insn 11 10 12 2 (parallel [
(set (reg:HI 110)
(lshiftrt:HI (subreg:HI (reg:SI 109) 0)
(const_int 15 [0xf])))
(clobber (reg:CC 17 flags))
]) "testcase.c":15 572 {*lshrhi3_1}
(expr_list:REG_DEAD (reg:SI 109)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 12 11 13 2 (set (reg:QI 92 [ _11 ])
(subreg:QI (reg:HI 110) 0)) "testcase.c":15 85 {*movqi_internal}
(expr_list:REG_DEAD (reg:HI 110)
(nil)))
...
.combine shows:
...
Trying 9, 11 -> 12:
...
Successfully matched this instruction:
(set (reg:SI 110)
(lshiftrt:SI (reg/v:SI 105 [ xD.1799 ])
(const_int 10 [0xa])))
Successfully matched this instruction:
(set (subreg:SI (reg:QI 92 [ _11 ]) 0)
(and:SI (reg:SI 110)
(const_int 255 [0xff])))
allowing combination of insns 9, 11 and 12
original costs 4 + 4 + 4 = 12
replacement costs 4 + 4 = 8
Which is probably wrong.
Tested revisions:
r242657 - FAIL
r242583 - FAIL
r242510 - FAIL
r242408 - OK
[Bug tree-optimization/78429] [7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 Martin Liška changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r241529.
[Bug sanitizer/69278] Confusion option handling for -sanitize-recovery=alll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69278 --- Comment #4 from Jakub Jelinek --- Maybe llvm doesn't care about backwards compatibility, but we do.
[Bug target/78439] [7 Regression] error: insn does not satisfy its constraints (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78439 --- Comment #5 from ktkachov at gcc dot gnu.org --- Testing a patch.
[Bug tree-optimization/78428] [5/6/7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 64-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78428
Martin Liška changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
||marxin at gcc dot gnu.org
Known to fail||6.2.0
--- Comment #2 from Martin Liška ---
I can confirm that it fail starting with r218818.
Add -malign-data={abi|compat|cachineline}
Add -malign-data={abi|compat,cachineline} to control how GCC aligns
variables. "compat" uses increased alignment value compatible with
GCC 4.8 and earlier, "abi" uses alignment value as specified by the
psABI, and "cacheline" uses increased alignment value to match the
cache line size. "compat" is the default.
[Bug rtl-optimization/78437] [7 Regression]: Invalid sign-extend conversion in REE pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78437 --- Comment #4 from Uroš Bizjak --- (In reply to Eric Botcazou from comment #3) > Created attachment 40098 [details] > Tentative fix > > It only affects Alpha (by default) but I no longer have access to Alpha > hardware so I'm going to play with it on SPARC. Its effect on the assembly > code on Alpha is: > > --- pr78437_1.s 2016-11-21 11:54:33.678363106 +0100 > +++ pr78437_2.s 2016-11-21 11:54:40.230542615 +0100 > @@ -62,7 +62,7 @@ > ldbu $7,max($5) !gprellow > sextb $8,$3 > stb $8,expected($2) !gprellow > - mov $3,$22 > + bis $31,$8,$22 > sextb $7,$7 > cmpeq $3,$7,$3 > beq $3,$L4 > > FWIW the change for PR rtl-opt/59461 eliminated 2 redundant extensions. Yes this change fixes reduced testcase execution. I have started bootstrap+regtest with your patch on alpha native. Please expect results sometime tomorrow.
[Bug tree-optimization/78429] [7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429
--- Comment #3 from Eric Botcazou ---
It looks like this guard in set_and_canonicalize_value_range:
/* For one bit precision if max < min, then the swapped
range covers all values, so for VR_RANGE it is varying and
for VR_ANTI_RANGE empty range, so drop to varying as well. */
if (TYPE_PRECISION (TREE_TYPE (min)) == 1)
{
set_value_range_to_varying (vr);
return;
}
is bypassed because we have a rather surprising boolean type:
(gdb) p debug_tree(min)
constant 0>
(gdb) p debug_tree((tree)0x76d7b888)
constant 32>
unit size constant 4>
align 32 symtab 0 alias set -1 canonical type 0x76d7b888 precision 32
min max >
[Bug target/78093] [avr] New variable attribute "absdata" and option "-mabsdata" to enable LDS / STS on Reduced Tiny
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78093 --- Comment #4 from Georg-Johann Lay --- Author: gjl Date: Mon Nov 21 12:23:14 2016 New Revision: 242660 URL: https://gcc.gnu.org/viewcvs?rev=242660&root=gcc&view=rev Log: PR target/78093 * config/avr/avr.c (avr_decl_maybe_lds_p): New static function. (avr_encode_section_info) [TARGET_ABSDATA && AVR_TINY]: Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug middle-end/78429] [5/6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Component|tree-optimization |middle-end
Target Milestone|7.0 |5.5
Summary|[7 Regression] ice on valid |[5/6/7 Regression] ice on
|C code on x86_64-linux-gnu |valid C code on
|at -O3 in both 32-bit and |x86_64-linux-gnu at -O3 in
|64-bit modes (internal |both 32-bit and 64-bit
|compiler error: in |modes (internal compiler
|set_value_range, at |error: in set_value_range,
|tree-vrp.c:361) |at tree-vrp.c:361)
--- Comment #4 from Richard Biener ---
Hmm, so
constant 32>
unit size constant 4>
align 32 symtab 0 alias set -1 canonical type 0x2c16c888 precision 32
min max >
(look at the types min/max value). For this rason
(gdb) p debug_tree (min)
constant public
overflow -1>
is not considered is_overflow_infinity (it's not vrp_val_is_min/max).
So what is causing this is likely behavioral change of some constant folding
with respect to BOOLEAN_TYPEs. Here
_22 = BIT_FIELD_REF ;
_53 = (_Bool) _22;
changed behavior in force_fit_type which does:
tree
force_fit_type (tree type, const wide_int_ref &cst,
int overflowable, bool overflowed)
{
signop sign = TYPE_SIGN (type);
/* If we need to set overflow flags, return a new unshared node. */
if (overflowed || !wi::fits_to_tree_p (cst, type))
{
if (overflowed
|| overflowable < 0
|| (overflowable > 0 && sign == SIGNED))
{
wide_int tmp = wide_int::from (cst, TYPE_PRECISION (type), sign);
tree t = build_new_int_cst (type, tmp);
TREE_OVERFLOW (t) = 1;
return t;
}
where -1 no longer "fits" bool even though it should. So
/* Short-circuit boolean types since various transformations assume that
they can only take values 0 and 1. */
if (TREE_CODE (type) == BOOLEAN_TYPE)
return eq_p (x, 0) || eq_p (x, 1);
is wrong and should use eq_p (x, -1) instead as bool is signed? The
int_fits_type_p function is likely wrong as well (uses integer_onep).
The patch has been backported as well, adjusting regression marker.
[Bug middle-end/78429] [5/6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 --- Comment #5 from Richard Biener --- It's built by build_nonstandard_boolean_type via (gdb) bt #0 0x01204281 in build_nonstandard_boolean_type (precision=32) at /space/rguenther/src/gcc-git/gcc/tree.c:8219 #1 0x0120e478 in build_truth_vector_type (nunits=4, vector_size=16) at /space/rguenther/src/gcc-git/gcc/tree.c:10919 #2 0x0118881a in get_mask_type_for_scalar_type ( scalar_type=) at /space/rguenther/src/gcc-git/gcc/tree-vect-stmts.c:8958 #3 0x019519b2 in search_type_for_mask_1 ( var=, vinfo=0x28ab530, cache=...) at /space/rguenther/src/gcc-git/gcc/tree-vect-patterns.c:3538 #4 0x01951be3 in search_type_for_mask (var=, vinfo=0x28ab530)
[Bug middle-end/78429] [6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 Richard Biener changed: What|Removed |Added Target Milestone|5.5 |6.3 Summary|[5/6/7 Regression] ice on |[6/7 Regression] ice on |valid C code on |valid C code on |x86_64-linux-gnu at -O3 in |x86_64-linux-gnu at -O3 in |both 32-bit and 64-bit |both 32-bit and 64-bit |modes (internal compiler|modes (internal compiler |error: in set_value_range, |error: in set_value_range, |at tree-vrp.c:361) |at tree-vrp.c:361) --- Comment #6 from Richard Biener --- Wasn't backported to GCC5 (yet).
[Bug rtl-optimization/78447] [7 Regression] wrong code when combine changes shifts by << 5 and >> 15 to >> 10 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78447 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug middle-end/78429] [6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 --- Comment #7 from Eric Botcazou --- > Wasn't backported to GCC5 (yet). There is no plan to backport it to GCC 5 though.
[Bug middle-end/78429] [6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 --- Comment #8 from Eric Botcazou --- > where -1 no longer "fits" bool even though it should. So > > /* Short-circuit boolean types since various transformations assume that > they can only take values 0 and 1. */ > if (TREE_CODE (type) == BOOLEAN_TYPE) > return eq_p (x, 0) || eq_p (x, 1); > > is wrong and should use eq_p (x, -1) instead as bool is signed? The > int_fits_type_p function is likely wrong as well (uses integer_onep). Standard boolean types as unsigned though, not signed: Index: tree.c === --- tree.c (revision 242632) +++ tree.c (working copy) @@ -8218,7 +8218,7 @@ build_nonstandard_boolean_type (unsigned type = make_node (BOOLEAN_TYPE); TYPE_PRECISION (type) = precision; - fixup_signed_type (type); + fixup_unsigned_type (type); if (precision <= MAX_INT_CACHED_PREC) nonstandard_boolean_type_cache[precision] = type; fixes the ICE.
[Bug middle-end/78429] [6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429
--- Comment #9 from Richard Biener ---
(In reply to Eric Botcazou from comment #8)
> > where -1 no longer "fits" bool even though it should. So
> >
> > /* Short-circuit boolean types since various transformations assume that
> > they can only take values 0 and 1. */
> > if (TREE_CODE (type) == BOOLEAN_TYPE)
> > return eq_p (x, 0) || eq_p (x, 1);
> >
> > is wrong and should use eq_p (x, -1) instead as bool is signed? The
> > int_fits_type_p function is likely wrong as well (uses integer_onep).
>
> Standard boolean types as unsigned though, not signed:
>
> Index: tree.c
> ===
> --- tree.c (revision 242632)
> +++ tree.c (working copy)
> @@ -8218,7 +8218,7 @@ build_nonstandard_boolean_type (unsigned
>
>type = make_node (BOOLEAN_TYPE);
>TYPE_PRECISION (type) = precision;
> - fixup_signed_type (type);
> + fixup_unsigned_type (type);
>
>if (precision <= MAX_INT_CACHED_PREC)
> nonstandard_boolean_type_cache[precision] = type;
>
> fixes the ICE.
fortran does
static tree
gfc_build_logical_type (gfc_logical_info *info)
{
int bit_size = info->bit_size;
tree new_type;
if (bit_size == BOOL_TYPE_SIZE)
{
info->c_bool = 1;
return boolean_type_node;
}
new_type = make_unsigned_type (bit_size);
TREE_SET_CODE (new_type, BOOLEAN_TYPE);
TYPE_MAX_VALUE (new_type) = build_int_cst (new_type, 1);
TYPE_PRECISION (new_type) = 1;
note that the vectorizer emits code to widen the boolean types expecting
sign-extension of vector truth (-1). That matches what the RTL code gen
ends up doing semantics-wise.
It has been changed by
2015-11-09 Ilya Enkovich
* optabs.c (expand_vec_cond_expr): Always get sign from type.
* tree.c (wide_int_to_tree): Support negative values for boolean.
(build_nonstandard_boolean_type): Use signed type for booleans.
thus the signedness is wanted (so is the precision). The issues arise
once we are extracting a vector element and performing the (_Bool) cast...
[Bug middle-end/78429] [6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 --- Comment #10 from Eric Botcazou --- > It's built by build_nonstandard_boolean_type via > > (gdb) bt > #0 0x01204281 in build_nonstandard_boolean_type (precision=32) > at /space/rguenther/src/gcc-git/gcc/tree.c:8219 > #1 0x0120e478 in build_truth_vector_type (nunits=4, vector_size=16) > at /space/rguenther/src/gcc-git/gcc/tree.c:10919 > #2 0x0118881a in get_mask_type_for_scalar_type ( > scalar_type=) > at /space/rguenther/src/gcc-git/gcc/tree-vect-stmts.c:8958 > #3 0x019519b2 in search_type_for_mask_1 ( > var=, vinfo=0x28ab530, cache=...) > at /space/rguenther/src/gcc-git/gcc/tree-vect-patterns.c:3538 > #4 0x01951be3 in search_type_for_mask (var= 0x2c173438>, > vinfo=0x28ab530) Right, so it looks like Ada is not the only producer of non-standard boolean types, there is even a helper function to do it. Which means that any language could be affected by the regression uncovered in Ada.
[Bug middle-end/78411] [7 Regression] FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411 --- Comment #6 from Jakub Jelinek --- Oh, starting with r242550 this FAILs now everywhere. The question is why it FAILed for H.J. before r242550. So shall we just add -ftree-loop-if-convert to dg-options of this test?
[Bug middle-end/78429] [6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 --- Comment #11 from Richard Biener --- The following made them signed (but not precision 1). https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03030.html
[Bug tree-optimization/78396] [7 regression] gcc.dg/vect/bb-slp-cond-1.c FAILs after fix for PR77848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78396 --- Comment #3 from Bill Schmidt --- The ??? comments worry me -- can't this leave us with the same kinds of regressions that led to PR77848? I think the specific test in that PR may regress again.
[Bug middle-end/78429] [6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 --- Comment #12 from rguenther at suse dot de --- On Mon, 21 Nov 2016, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 > > --- Comment #10 from Eric Botcazou --- > > It's built by build_nonstandard_boolean_type via > > > > (gdb) bt > > #0 0x01204281 in build_nonstandard_boolean_type (precision=32) > > at /space/rguenther/src/gcc-git/gcc/tree.c:8219 > > #1 0x0120e478 in build_truth_vector_type (nunits=4, vector_size=16) > > at /space/rguenther/src/gcc-git/gcc/tree.c:10919 > > #2 0x0118881a in get_mask_type_for_scalar_type ( > > scalar_type=) > > at /space/rguenther/src/gcc-git/gcc/tree-vect-stmts.c:8958 > > #3 0x019519b2 in search_type_for_mask_1 ( > > var=, vinfo=0x28ab530, cache=...) > > at /space/rguenther/src/gcc-git/gcc/tree-vect-patterns.c:3538 > > #4 0x01951be3 in search_type_for_mask (var= > 0x2c173438>, > > vinfo=0x28ab530) > > Right, so it looks like Ada is not the only producer of non-standard boolean > types, there is even a helper function to do it. Which means that any > language > could be affected by the regression uncovered in Ada. In practice the above is used in vector context only (plus in the extraction the vectorizer builds). I suppose that being more careful at the extraction side may also help papering over this issue. In the end having a bool_with_only_0_and_1 predicate rather than open-coding (several variants of) the test throughout the middle-end might be a good idea... I don't remember off-head why we ended up with BOOLEA_TYPE element vectors instead of using INTEGER_TYPE but I think it was because the x86 backend actually ends up with QImode boolean vectors for the sake of avx512 mask registers. And I opposed to treating 'char' as vector which means we now have vector with QImode or vector<"bool"> with V4SImode for non-AVX512 targets. So we can identify VECTOR_BOOLEAN_TYPE_P.
[Bug middle-end/78411] [7 Regression] FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411 --- Comment #7 from rguenther at suse dot de --- On Mon, 21 Nov 2016, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411 > > --- Comment #6 from Jakub Jelinek --- > Oh, starting with r242550 this FAILs now everywhere. The question is why it > FAILed for H.J. before r242550. > So shall we just add -ftree-loop-if-convert to dg-options of this test? Not sure. Maybe remove it instead? Why does RTL if-conversion not catch it? Or why does PHI-OPT not catch it: : # s_40 = PHI # i_35 = PHI _25 = MEM[base: products_16(D), index: i_35, step: 8, offset: 0B]; if (_25 > 0) goto ; else goto ; : _17 = -_25; : # iftmp.0_13 = PHI <1(5), -1(6)> # prephitmp_10 = PHI <_25(5), _17(6)> # prephitmp_9 = PHI <-1(5), 1(6)> # prephitmp_33 = PHI <4294967295(5), 1(6)> # prephitmp_32 = PHI <1(5), 4294967295(6)> _31 = (long long unsigned int) prephitmp_10; this should be ABS_EXPR<>. I guess the other PHIs get in the way. Earlier PHI-OPT has too convoluted tests still. The above also shows some excessive PRE of constants (we're inserting more PHIs when dealing with a all-constant-arg PHI): : - # iftmp.0_12 = PHI <1(4), -1(12)> - _4 = _3 * iftmp.0_12; - _5 = (long long unsigned int) _4; + # iftmp.0_12 = PHI <1(3), -1(4)> + # prephitmp_37 = PHI <_3(3), _36(4)> + # prephitmp_38 = PHI <-1(3), 1(4)> + # prephitmp_39 = PHI <4294967295(3), 1(4)> + # prephitmp_41 = PHI <1(3), 4294967295(4)> + _5 = (long long unsigned int) prephitmp_37; I guess I'll (finally) try to do something about that.
[Bug tree-optimization/78396] [7 regression] gcc.dg/vect/bb-slp-cond-1.c FAILs after fix for PR77848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78396 --- Comment #4 from rguenther at suse dot de --- On Mon, 21 Nov 2016, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78396 > > --- Comment #3 from Bill Schmidt --- > The ??? comments worry me -- can't this leave us with the same kinds of > regressions that led to PR77848? I think the specific test in that PR may > regress again. Can you quickly check? I thought nothing was vectorized there... Note that this is likely the only improvement we can do in the GCC 7 timeframe.
[Bug go/78432] [7 Regression] -fdump-go-spec ICEs for aligned causing x32 libgo library to fail to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78432 Matthias Klose changed: What|Removed |Added Target|x86_64-linux-gnu, |x86_64-linux-gnu, |s390-linux-gnu |s390-linux-gnu, ||powerpc-linux-gnu --- Comment #3 from Matthias Klose --- and powerpc-linux-gnu
[Bug target/64802] [ARM] Selecting an -mcpu or -march that supports only one of ARM/Thumb should default to the ISA that *is* supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64802 Thomas Preud'homme changed: What|Removed |Added Status|NEW |RESOLVED CC||thopre01 at gcc dot gnu.org Known to work||7.0 Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot gnu.org --- Comment #2 from Thomas Preud'homme --- Fixed as of r242597.
[Bug rtl-optimization/78342] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2657 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78342
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-11-21
CC||jakub at gcc dot gnu.org,
||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
I'd say the bug is in combine, which turns:
(insn 58 78 109 6 (set (reg:SI 178 [ r2+-3 ])
(const_int 1 [0x1])) "pr78342.c":23 373 {*movsi_internal1}
(nil))
(insn 109 58 61 6 (trap_if (eq (reg:SI 178 [ r2+-3 ])
(const_int 1 [0x1]))
(const_int 0 [0])) -1
(expr_list:REG_DEAD (reg:SI 178 [ r2+-3 ])
(nil)))
;; succ: 7 [100.0%] (FALLTHRU)
into:
(note 58 78 109 6 NOTE_INSN_DELETED)
(insn 109 58 61 6 (trap_if (const_int 1 [0x1])
(const_int 0 [0])) 602 {trap}
(nil))
;; succ: 7 [100.0%] (FALLTHRU)
While trap_if (something other than const1_rtx) is considered normal insn,
trap_if (const1_rtx) is considered a noreturn insn like noreturn call, that has
to terminate a bb. So I think what is wrong is that the corresponding bb still
has a successor, that edge should have been removed and cfg cleaned up.
Possibly if the bb contains conditional trap_if in the middle of the bb and
combiner changes it, we should also split the bb. Are there any other RTL
passes that turn conditional trap_if into unconditional?
[Bug middle-end/78411] [7 Regression] FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411
--- Comment #8 from Richard Biener ---
diff --git a/gcc/tree-ssa-pre.c b/gcc/tree-ssa-pre.c
index 4f17200..c50c598 100644
--- a/gcc/tree-ssa-pre.c
+++ b/gcc/tree-ssa-pre.c
@@ -3017,6 +3017,7 @@ insert_into_preds_of_block (basic_block block, unsigned
int exprnum,
}
/* Make the necessary insertions. */
+ bool all_constant = true;
FOR_EACH_EDGE (pred, ei, block->preds)
{
gimple_seq stmts = NULL;
@@ -3041,8 +3042,15 @@ insert_into_preds_of_block (basic_block block, unsigned
int exprnum,
if (is_gimple_min_invariant (builtexpr))
avail[pred->dest_idx] = get_or_alloc_expr_for_constant (builtexpr);
else
- avail[pred->dest_idx] = get_or_alloc_expr_for_name (builtexpr);
+ {
+ avail[pred->dest_idx] = get_or_alloc_expr_for_name (builtexpr);
+ all_constant = false;
+ }
}
+ /* If we're about to insert a PHI with all arguments constant refuse
+ to do that. But return whether we inserted stuff. */
+ if (all_constant)
+return insertions;
/* If we didn't want a phi node, and we made insertions, we still have
inserted new stuff, and thus return true. If we didn't want a phi node,
and didn't make insertions, we haven't added anything new, so return
but that still leaves us with
_25 = MEM[base: products_16(D), index: i_35, step: 8, offset: 0B];
if (_25 > 0)
goto ;
else
goto ;
:
_17 = -_25;
:
# iftmp.0_13 = PHI <1(5), -1(6)>
# prephitmp_10 = PHI <_25(5), _17(6)>
_9 = (long long unsigned int) prephitmp_10;
and thus phiopt not matching the ABS. For some reason split-paths split
the loop latch confusing RTL if-conversion even more (removing the
possibility to emit a conditional store).
I don't believe what tree-if-conv.c did was reasonable here (together with PRE)
but we do not generate optimal code from the code in the testcase.
Still if-conversion is generally a RTL opt task.
[Bug libstdc++/78448] New: Container max_size() functions don't consider the range of their difference_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78448
Bug ID: 78448
Summary: Container max_size() functions don't consider the
range of their difference_type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
#include
int main() {
using V = std::vector;
V v;
assert(v.max_size() <= std::numeric_limits::max());
}
The requirement is that max_size() returns:
distance(begin(), end()) for the largest possible container
which must fit in Container::difference_type
Re: copy_n should result in a one past the end input iterator
On 21/11/16 03:10 +, Robert Young wrote: /* gcc -Wall -Wextra -std=c++11 copy_n_vs_copy.cpp -lstdc++ -o copy_n_vs_copy One Past the End https://gcc.gnu.org/onlinedocs/libstdc++/manual/iterators.html#iterators.predefined.end BUG location: /usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/include/g++-v5/bits/stl_algo.h */ Hi, This mailing list is for automated email from our Bugzilla database, if you send email to this list it is likely to be missed or ignored. Please report bugs to Bugzilla as described at https://gcc.gnu.org/bugs/ However, this is not a bug because it is unclear what the right behaviour is for this algorithm, see http://cplusplus.github.io/LWG/lwg-active.html#2471 We are not going to change libstdc++ until the C++ standards committee decides what the right behaviour is.
[Bug tree-optimization/78413] [7 Regression] ICE in single_pred_edge, at basic-block.h:361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413 --- Comment #7 from Bill Schmidt --- Author: wschmidt Date: Mon Nov 21 14:10:11 2016 New Revision: 242661 URL: https://gcc.gnu.org/viewcvs?rev=242661&root=gcc&view=rev Log: [gcc] 2016-11-21 Bill Schmidt PR tree-optimization/78413 * tree-if-conv.c (versionable_outer_loop_p): Require that both inner and outer loop latches have single predecessors. [gcc/testsuite] 2016-11-21 Bill Schmidt PR tree-optimization/78413 * gcc.dg/tree-ssa/pr78413.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr78413.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug tree-optimization/78396] [7 regression] gcc.dg/vect/bb-slp-cond-1.c FAILs after fix for PR77848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78396 --- Comment #5 from Bill Schmidt --- OK, I'll test it out shortly.
[Bug c++/70909] Libiberty Demangler segfaults (4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909 --- Comment #13 from Matt Godbolt --- We will try and get a small repro case. It comes from open source software: it's from the compiling_tests.cpp program in trompeloeil (https://github.com/rollbear/trompeloeil/blob/master/compiling_tests.cpp. The trompeloeil author is going to try and make a cut-down case.
[Bug c++/71973] c++ handles built-in functions inconsistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973 --- Comment #5 from Bernd Edlinger --- Author: edlinger Date: Mon Nov 21 14:17:05 2016 New Revision: 242662 URL: https://gcc.gnu.org/viewcvs?rev=242662&root=gcc&view=rev Log: gcc: 2016-11-21 Bernd Edlinger PR c++/71973 * doc/invoke.texi (-Wno-builtin-declaration-mismatch): Document the new default-enabled warning.. * builtin-types.def (BT_CONST_TM_PTR): New primitive type. (BT_PTR_CONST_STRING): Updated. (BT_FN_SIZE_STRING_SIZE_CONST_STRING_CONST_PTR): Removed. (BT_FN_SIZE_STRING_SIZE_CONST_STRING_CONST_TM_PTR): New function type. * builtins.def (DEF_TM_BUILTIN): Disable BOTH_P for TM builtins. (strftime): Update builtin function. * tree-core.h (TI_CONST_TM_PTR_TYPE): New enum value. * tree.h (const_tm_ptr_type_node): New type node. * tree.c (free_lang_data, build_common_tree_nodes): Initialize const_tm_ptr_type_node. c-family: 2016-11-21 Bernd Edlinger PR c++/71973 * c.opt (-Wbuiltin-declaration-mismatch): New warning. * c-common.c (c_common_nodes_and_builtins): Initialize const_tm_ptr_type_node. c: 2016-11-21 Bernd Edlinger PR c++/71973 * c-decl.c (diagnose_mismatched_decls): Use OPT_Wbuiltin_declaration_mismatch here too. cp: 2016-11-21 Bernd Edlinger PR c++/71973 * decl.c (duplicate_decls): Warn when a built-in function is redefined. Don't overload builtin functions with C++ functions. Handle const_tm_ptr_type_node like file_ptr_node. Copy the TREE_NOTHROW flag unmodified to the old decl. lto: 2016-11-21 Bernd Edlinger PR c++/71973 * lto-lang.c (lto_init): Assert const_tm_ptr_type_node is sane. testsuite: 2016-11-21 Bernd Edlinger PR c++/71973 * g++.dg/pr71973-1.C: New test. * g++.dg/pr71973-2.C: New test. * g++.dg/pr71973-3.C: New test. * g++.dg/lto/pr68811_0.C: Add -w to first lto-options. * g++.dg/lookup/extern-c-redecl4.C: Adjust test expectations. * g++.old-deja/g++.mike/p700.C: Add -Wno-builtin-declaration-mismatch to dg-options. * g++.old-deja/g++.other/realloc.C: Likewise. * g++.old-deja/g++.other/builtins10.C: Adjust test expectations. Added: trunk/gcc/testsuite/g++.dg/pr71973-1.C trunk/gcc/testsuite/g++.dg/pr71973-2.C trunk/gcc/testsuite/g++.dg/pr71973-3.C Modified: trunk/gcc/ChangeLog trunk/gcc/builtin-types.def trunk/gcc/builtins.def trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/doc/invoke.texi trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-lang.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lookup/extern-c-redecl4.C trunk/gcc/testsuite/g++.dg/lto/pr68811_0.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p700.C trunk/gcc/testsuite/g++.old-deja/g++.other/builtins10.C trunk/gcc/testsuite/g++.old-deja/g++.other/realloc.C trunk/gcc/tree-core.h trunk/gcc/tree.c trunk/gcc/tree.h
[Bug tree-optimization/78413] [7 Regression] ICE in single_pred_edge, at basic-block.h:361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Bill Schmidt --- Fixed.
[Bug rtl-optimization/78400] [7 Regression] ICE: in df_refs_verify, at df-scan.c:4045 when building powerpc crosscompiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78400 --- Comment #2 from Segher Boessenkool --- Author: segher Date: Mon Nov 21 14:44:21 2016 New Revision: 242663 URL: https://gcc.gnu.org/viewcvs?rev=242663&root=gcc&view=rev Log: shrink-wrap: Fix problem with DF checking (PR78400) With my previous patch the compiler ICEs if you use --enable-checking=df. This patch fixes it, by calling df_update_entry_exit_and_calls instead of df_update_entry_block_defs and df_update_exit_block_uses. PR rtl-optimization/78400 * shrink-wrap.c (try_shrink_wrapping_separate): Call df_update_entry_exit_and_calls instead of df_update_entry_block_defs and df_update_exit_block_uses. Modified: trunk/gcc/ChangeLog trunk/gcc/shrink-wrap.c
[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78114 --- Comment #10 from amker at gcc dot gnu.org --- Author: amker Date: Mon Nov 21 14:58:19 2016 New Revision: 242664 URL: https://gcc.gnu.org/viewcvs?rev=242664&root=gcc&view=rev Log: gcc/testsuite PR testsuite/78114 * gfortran.dg/vect/fast-math-mgrid-resid.f: Add additional options. Refine test by checking predictive commining PHI nodes in vectorized loop wrto vector factor. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 --- Comment #8 from Segher Boessenkool --- Author: segher Date: Mon Nov 21 15:15:21 2016 New Revision: 242665 URL: https://gcc.gnu.org/viewcvs?rev=242665&root=gcc&view=rev Log: Testcase for PR71785 gcc/testsuite/ PR rtl-optimization/71785 * gcc.target/powerpc/pr71785.c: New file. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr71785.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||7.0 --- Comment #9 from Segher Boessenkool --- Fixed on trunk. Probably still want backports, this shortcoming is ancient but nasty, there are a lot of related PRs.
[Bug rtl-optimization/78342] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2657 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78342 Segher Boessenkool changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- Confirmed; needs -m32 only, no -fPIC, not only BE.
[Bug sanitizer/78208] Compile-time hog with -fsanitize=null with operator overloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78208 --- Comment #1 from Jakub Jelinek --- As discussed on gcc-patches, I think this is only a compile-time hog with -fdump-tree-original.
[Bug libfortran/78449] New: compile time ieee_support_halting is not correct on arm and aarch64 ( FAIL: gfortran.dg/ieee/ieee_8.f90 -Os execution test )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78449 Bug ID: 78449 Summary: compile time ieee_support_halting is not correct on arm and aarch64 ( FAIL: gfortran.dg/ieee/ieee_8.f90 -Os execution test ) Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- on aarch64 and arm trapping support requires runtime check (bug 78314), but it seems fortran may need consistent result for ieee_support_halting at compile time and runtime (in which case the correct behaviour is to always return false on targets where there might be no support).
[Bug tree-optimization/78396] [7 regression] gcc.dg/vect/bb-slp-cond-1.c FAILs after fix for PR77848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78396 --- Comment #6 from Bill Schmidt --- gfortran.dg/vect/pr77848.f indeed still passes with this change. I suppose that similar code where something else in the block could be vectorized would still regress, though. I don't think that's sufficient to hold up this fix, but it's just a reason to see if we can do better in GCC 8.
[Bug rtl-optimization/78447] [7 Regression] wrong code when combine changes shifts by << 5 and >> 15 to >> 10 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78447 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-21 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r242414, might be a dup of PR78438.
[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78324 --- Comment #5 from David Malcolm --- Author: dmalcolm Date: Mon Nov 21 15:50:38 2016 New Revision: 242667 URL: https://gcc.gnu.org/viewcvs?rev=242667&root=gcc&view=rev Log: substring_loc info needs default track-macro-expansion (PR preprocessor/78324) gcc/ChangeLog: PR preprocessor/78324 * input.c (get_substring_ranges_for_loc): Fail gracefully if -ftrack-macro-expansion has a value other than 2. gcc/testsuite/ChangeLog: PR preprocessor/78324 * gcc.dg/plugin/diagnostic-test-string-literals-1.c (test_multitoken_macro): New function. * gcc.dg/plugin/diagnostic-test-string-literals-3.c: New test case. * gcc.dg/plugin/diagnostic-test-string-literals-4.c: New test case. * gcc.dg/plugin/plugin.exp (plugin_test_list): Add the new test cases. * gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test_sprintf_note): Move to... * gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: ...here. Drop -ftrack-macro-expansion=0. (test_sprintf_note): Remove "P" macro. Add dg-begin/end-multiline-output directives. (LINE, buffer, ptr): Copy from builtin-sprintf-warn-1.c. Added: trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-3.c trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/input.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c trunk/gcc/testsuite/gcc.dg/plugin/plugin.exp trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c
[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78324 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from David Malcolm --- Should be fixed by r242667 (confirmed using valgrind on x86_64).
[Bug preprocessor/77810] provide format_inform_at_substring to go with format_warning_at_substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77810 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #2 from David Malcolm --- (In reply to Martin Sebor from comment #1) > Created attachment 39727 [details] > Prototype patch. > > I tested the attached proof-of-concept patch by integrating it into the > gimple-ssa-sprintf pass. (sorry, I believe this is the first time I've seen the bug/patch) Do you still have a need for this functionality? FWIW, the leading comment describing format_warning_va/format_diag_va needs rewording; likewise the comment about /* Functions for emitting a warning about a format string. */ Otherwise, the patch looks reasonable (though am not sure if I have approval rights on this one). Did this ever get posted to gcc-patches?
[Bug middle-end/78445] [7 Regression] ICE in maybe_gen_insn, at optabs.c:7014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78445 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r242550.
[Bug tree-optimization/78450] New: strlen(s) return value can be assumed to be less than the size of s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78450
Bug ID: 78450
Summary: strlen(s) return value can be assumed to be less than
the size of s
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: ---
In a call to strlen(p) where p points to two or more constant strings of known
lengths GCC determines the length of the longest string and uses that as the
upper bound of the range of values returned by the call.
Similarly, in a call to strlen(q) where the length of one or more of the
strings pointed to by q is not known but where q points to arrays of known
size, GCC could use the size of the largest array as the upper bound (modulo
flexible array members and such). However, the test case below shows that GCC
does not take advantage of this possible optimization opportunity.
$ (set -x && cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout x.c | grep -e "^[fg] (" -e abort)
+ cat x.c
const char a[] = "123";
const char b[] = "1234";
void f (int i)
{
const char *s = i < 0 ? a : b;
unsigned n = __builtin_strlen (s);
if (4 < n)
__builtin_abort ();
}
char a3[3];
char b4[4];
void g (int i)
{
const char *s = i < 0 ? a3 : b4;
unsigned n = __builtin_strlen (s);
if (3 < n)
__builtin_abort ();
}
+ gcc -O2 -S -Wall -Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout x.c
+ grep --color=auto -e '^[fg] (' -e abort
f (int i)
g (int i)
__builtin_abort ();
[Bug middle-end/78445] [7 Regression] ICE in maybe_gen_insn, at optabs.c:7014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78445 --- Comment #3 from Jakub Jelinek --- That change is clearly bogus, if we have any masked loads/stores, we need to version the loop, even if -ftree-loop-if-convert. Will test a patch for this.
[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78114 --- Comment #11 from janus at gcc dot gnu.org --- r242664 seems to fix the issue I reported in comment 3/4. Thanks!
[Bug middle-end/78445] [7 Regression] ICE in maybe_gen_insn, at optabs.c:7014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78445 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 40100 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40100&action=edit gcc7-pr78445.patch Untested fix.
[Bug fortran/78443] [OOP] Incorrect behavior with non_overridable keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78443 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-21 CC||janus at gcc dot gnu.org Summary|Incorrect behavior with |[OOP] Incorrect behavior |non_overridable keyword |with non_overridable ||keyword Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- I tried the test case with all gfortran versions from 4.7 to current trunk (pre-7). All of them exhibit the same behavior, compiling the code without any problems and giving the following runtime output: square( 2. ) = -100.00 square( 2. ) = -100.00 Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
[Bug preprocessor/77810] provide format_inform_at_substring to go with format_warning_at_substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77810 --- Comment #3 from Martin Sebor --- I haven't posted the patch for review. IIRC, I put it together in hopes of enhancing the -Wformat-length notes to refer to the arguments of the directives and offering fixit hints showing how to resolve some of the warnings. The motivation for this was bug 77690 (and similar cases) where the solution is to add precision to a %s directive to cap the number of bytes it outputs. The general enhancement of adding fixit notes to the warning is being tracked in bug 77831. I'd be interested in your ideas for how they could be put to use beyond the %s directive and where (this might perhaps be worth tackling in conjunction with bug 77696). If there's still time to work on this in stage 3 I'll dust off the patch and post it for review.
[Bug middle-end/77831] add fixit hints to -Wformat-length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77831 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77810 --- Comment #1 from Martin Sebor --- See also bug 77810 which proposes to extend the substring-locations API to informational notes. The enhancement may be helpful or even necessary in implementing the fixit notes.
[Bug target/78451] New: FAIL: gcc.target/i386/sse-22a.c: error: inlining failed in call to always_inline '_mm512_setzero_ps'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78451 Bug ID: 78451 Summary: FAIL: gcc.target/i386/sse-22a.c: error: inlining failed in call to always_inline '_mm512_setzero_ps' Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- The gcc.target/i386/sse-22a.c test has been failing with the following error: FAIL: gcc.target/i386/sse-22a.c (test for excess errors) Excess errors: /home/msebor/build/gcc-78284/gcc/include/avx512fintrin.h:244:1: error: inlining failed in call to always_inline '_mm512_setzero_ps': target specific option mismatch On the gcc-rtegression list it's been reported as failing with an ICE: https://gcc.gnu.org/ml/gcc-regression/2016-11/msg00380.html The failure was mentioned in the following discussion: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02066.html
[Bug bootstrap/77676] powerpc64 and powerpc64le stage2 bootstrap fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77676 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Martin Sebor --- The patch to re-enable -fprintf-return-value was committed in r242674 after successfully bootstrapping on powerpc64*, i386, and x86_64 and passing regression tests. Please open a new bug for any new problems related to the option.
[Bug tree-optimization/78428] [5/6/7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 64-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78428
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
I think store_constructor/store_constructor_field should get
bitregion_{start,end} arguments and pass them through, so that initializing
some object through expand_constructor honors the object boundaries like e.g.
expand_assignment does.
[Bug fortran/78443] [OOP] Incorrect behavior with non_overridable keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78443 --- Comment #2 from janus at gcc dot gnu.org --- Indeed this behavior is a bug. Looking at the dump generated with -fdump-tree-original, it seems that all typebound-procedure calls are generated as they should be: * The three calls in the main program are reduced to non-polymorphic calls: test2 (&class.2, &C.3565); test2 (&class.3, &C.3567); test1 (&class.4, &C.3571); * The calls to 'square' in the test procedures are performed polymorphically: D.3553 = this->_vptr->square ((struct __class_types_P2_t *) this, (real(kind=4) *) x); D.3555 = this->_vptr->square ((struct __class_types_P1_t *) this, (real(kind=4) *) x); So, what goes wrong is probably the assignment of the TBPs in the vtab.
