[Bug target/81622] New: [7/8 Regression] ICE on invalid altivec code with ppc64{,le}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622
Bug ID: 81622
Summary: [7/8 Regression] ICE on invalid altivec code with
ppc64{,le}
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: pthaugen at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: ppc64-linux-gnu
Running following invalid snippet fails since GCC 7:
$ cat ice.i
void a()
{
__builtin_vec_ld (1, 2);
}
$ /home/marxin/Programming/gcc2/objdir/gcc/xg++ -B
/home/marxin/Programming/gcc2/objdir/gcc/ ice.i -c
ice.i: In function ‘void a()’:
ice.i:3:25: internal compiler error: Segmentation fault
__builtin_vec_ld (1, 2);
^
0xeac98f crash_signal
../../gcc/toplev.c:338
0xa070d8 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3203
0xa070d8 altivec_resolve_overloaded_builtin(unsigned int, tree_node*, void*)
../../gcc/config/rs6000/rs6000-c.c:6468
0x902e7e finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2447
0x80e264 cp_parser_postfix_expression
../../gcc/cp/parser.c:7034
0x810a67 cp_parser_unary_expression
../../gcc/cp/parser.c:8156
0x811b3d cp_parser_cast_expression
../../gcc/cp/parser.c:8923
0x811c37 cp_parser_binary_expression
../../gcc/cp/parser.c:9024
0x812955 cp_parser_assignment_expression
../../gcc/cp/parser.c:9311
0x812cf2 cp_parser_expression
../../gcc/cp/parser.c:9480
0x81611d cp_parser_expression_statement
../../gcc/cp/parser.c:11048
0x815a89 cp_parser_statement
../../gcc/cp/parser.c:10864
0x816779 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11190
0x81666c cp_parser_compound_statement
../../gcc/cp/parser.c:11144
0x82ad37 cp_parser_function_body
../../gcc/cp/parser.c:21608
0x82affd cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21646
0x8342a0 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:26466
0x8340a4 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:26378
0x82647e cp_parser_init_declarator
../../gcc/cp/parser.c:19337
0x81a4f9 cp_parser_simple_declaration
../../gcc/cp/parser.c:12951
[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616 Richard Biener changed: What|Removed |Added Target|x86 |x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-31 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. Honza is working on this.
[Bug target/81613] [7/8 regression] FAIL: gfortran.dg/intrinsic_modulo_1.f90 -O3 -g execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81613 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.2
[Bug rtl-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611 Richard Biener changed: What|Removed |Added Known to work||4.7.3 Target Milestone|--- |8.0 Summary|gcc un-learned loop / |[8 Regression] gcc |post-increment optimization |un-learned loop / ||post-increment optimization Known to fail||8.0 --- Comment #1 from Richard Biener --- Looks like a register allocation / SSA coalescing issue to me. The IV is either not coalesced on the backedge or RA splits the live range. Maybe IVOPTs related as well. I suspect unless you do some more digging (bisection?) nothing will happen here ;)
[Bug c++/81609] incompatible extern C declarations of the same extern function at local scope accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81609 --- Comment #2 from Richard Biener --- But does it match C FE behavior?
[Bug tree-optimization/81607] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|8.0 |--- --- Comment #2 from Richard Biener --- I will have a looksee.
[Bug tree-optimization/81603] Various compiler UB on very large constant offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81603 --- Comment #1 from Richard Biener --- Well, yes - offset_int is basically former double_int and thus good for addresses/offsets measured in bits. Of course in this case why do we need the offset in bits at all? ... That said, we're looking at an ADDR_EXPR here, so we know bitsize % BITS_PER_UNIT == 0. Given we reject max_size == -1 this code could have used get_addr_base_and_unit_offset instead and avoid bit precision stuff.
[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |7.2 --- Comment #7 from Richard Biener --- optimize_bit_field_compare() is a premature red herring...
[Bug debug/81623] New: [8 Regression] FAIL: g++.dg/debug/debug9.C -gstabs -O3 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81623
Bug ID: 81623
Summary: [8 Regression] FAIL: g++.dg/debug/debug9.C -gstabs -O3
(test for excess errors)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at ucw dot cz
Target Milestone: ---
Starting from r249885, the test-case fails:
g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/debug/debug9.C -gstabs
-O3 -c
/tmp/ccY5CXGf.s: Assembler messages:
/tmp/ccY5CXGf.s:194: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LFBB1' {.text.startup section}
/tmp/ccY5CXGf.s:195: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LFBB1' {.text.startup section}
[Bug testsuite/81624] New: [8 Regression] FAIL: gcc.target/i386/pr59501-3a.c scan-assembler-not and[^\n\r]*sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81624 Bug ID: 81624 Summary: [8 Regression] FAIL: gcc.target/i386/pr59501-3a.c scan-assembler-not and[^\n\r]*sp Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hjl at gcc dot gnu.org Target Milestone: --- Starting from r250084, the test-case fails. Thanks.
[Bug tree-optimization/81297] [8 Regression] ICE in get_single_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81297
--- Comment #5 from Richard Biener ---
So we fold (plus -1 -2147483648) with type 'int' and TYPE_OVERFLOW_WRAPS. That
gets int_const_binop to set TREE_OVERFLOW (because generally fold only looks at
the SIGN and not TYPE_OVERFLOW_* when setting TREE_OVERFLOW).
The unfortunate thing here is that the overflow prevails in sth non-constant at
the end. But recursively walking all trees to weed out TREE_OVERFLOW after
each folding to non-constant looks awkward (and might even lead to more
folding!?).
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 250725)
+++ gcc/fold-const.c(working copy)
@@ -9107,8 +9107,8 @@ expr_not_equal_to (tree t, const wide_in
Return the folded expression if folding is successful. Otherwise,
return NULL_TREE. */
-tree
-fold_binary_loc (location_t loc,
+static tree
+fold_binary_loc_1 (location_t loc,
enum tree_code code, tree type, tree op0, tree op1)
{
enum tree_code_class kind = TREE_CODE_CLASS (code);
@@ -11177,6 +11177,31 @@ fold_binary_loc (location_t loc,
} /* switch (code) */
}
+static tree
+drop_tree_overflow_r (tree *expr_p, int *ws, void *)
+{
+ if (TREE_OVERFLOW_P (*expr_p))
+{
+ *expr_p = drop_tree_overflow (*expr_p);
+ *ws = 0;
+}
+ else if (! EXPR_P (*expr_p))
+*ws = 0;
+ return NULL_TREE;
+}
+
+tree
+fold_binary_loc (location_t loc,
+enum tree_code code, tree type, tree op0, tree op1)
+{
+ tree res = fold_binary_loc_1 (loc, code, type, op0, op1);
+ if (res && ! TREE_CONSTANT (res))
+walk_tree (&res, drop_tree_overflow_r, NULL, NULL);
+
+ return res;
+}
+
+
/* Callback for walk_tree, looking for LABEL_EXPR. Return *TP if it is
a LABEL_EXPR; otherwise return NULL_TREE. Do not check the subtrees
of GOTO_EXPR. */
note we're not properly re-building/folding subtrees here so fold checking
might be unhappy. It's also not clear that just ignoring TREE_CONSTANT
exprs is enough if you consider folding two non-constant but with dropped
overflow parts to a constant afterwards...
So I'm going to remove the assert in VRP that I added mainly for the
-fstrict-overflow removal as a sanity check.
[Bug rtl-optimization/81625] New: GCC v4.7 ... v8 is bloating code by > 25% compared to v3.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81625
Bug ID: 81625
Summary: GCC v4.7 ... v8 is bloating code by > 25% compared to
v3.4
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 41867
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41867&action=edit
snake-i.c: C test case.
The attached test case, compiled for code size
$ avr-gcc snake-i.c -mmcu=atmega168 -Os -S -dp -ffunction-sections -o
snake-i_$${v}.s
Gives the following sizes with different compiler versions:
avr-gcc (GCC) 3.4.6
textdata bss dec hex filename
672 0 0 672 2a0 snake-i_20060421.o
avr-gcc (GCC) 4.7.2
textdata bss dec hex filename
854 0 0 854 356 snake-i_4.7.2.o
avr-gcc (GCC) 4.9.2 20140912 (prerelease)
textdata bss dec hex filename
894 0 0 894 37e snake-i_4.9.2-pre1.o
avr-gcc (GCC) 5.2.1 20150816
textdata bss dec hex filename
876 0 0 876 36c snake-i_5.2.1.o
avr-gcc (GCC) 6.4.1 20170726
textdata bss dec hex filename
852 0 0 852 354 snake-i_6.4.1.o
avr-gcc (GCC) 7.1.1 20170725
textdata bss dec hex filename
850 0 0 850 352 snake-i_7.1.1.o
avr-gcc (GCC) 8.0.0 20170718 (experimental)
textdata bss dec hex filename
852 0 0 852 354 snake-i_8.0_2017-07-19.o
Hence, compared to 3.4.6, we have the following bloat factor:
3.4.6: 672
4.7.2: 854 = +27%
4.9.2: 894 = +33%
5.2.1: 876 = +30%
6.4.1: 852 = +26%
7.1.1: 850 = +26%
8.0.0: 852 = +26%
Mostly due to bad register selection; multiple expensive address computations
(for address that's just 1 after the already computed address), missed
post-increment opportunity, ...
Note that the code from 3.4.6 is already sub-optimal so there is even more room
for improvement.
Just some samples:
if (s->changed.text)
{
s->changed.text = 0;
sb->str[0] = s->game.level + '0';
sb->str[1] = '\n';
u16_to_string (sb->str+2, s->game.score);
}
3.4.6:
tst r24 ; 421 tstqi [length = 1]
breq .L20; 422 branch [length = 1]
std Z+6,__zero_reg__ ; 426 *movqi/3[length = 1]
; Compute address of sb->str to Y=r28.
subi r28,lo8(-(67)) ; 428 *addhi3/4 [length = 2]
sbci r29,hi8(-(67))
ldd r24,Z+7 ; 429 *movqi/4[length = 1]
; Using post-increment to store '0' + ...
subi r24,lo8(-(48)) ; 430 addqi3/2[length = 1]
st Y+,r24; 431 *movqi/3[length = 1]
ldi r24,lo8(10) ; 434 *movqi/2[length = 1]
; Dito to store '\n'.
st Y+,r24; 435 *movqi/3[length = 1]
ldd r22,Z+8 ; 438 *movhi/2[length = 2]
ldd r23,Z+9
; Now has sb->str + 2 to pass in r24.
movw r24,r28 ; 439 *movhi/1[length = 1]
call u16_to_string ; 440 call_value_insn/3 [length = 2]
.L20:
/* epilogue: frame size=0 */
8.0.0:
tst r24 ; 296 cmpqi3/1[length = 1]
brne .+2 ; 297 branch [length = 2]
rjmp .L20
; Using reg X=r26 which doesn't support X+const addressing, all described
; in LEGITIMIZE_RELOAD_ADDRESS. So it adds 6 and after access has to
; subtract 6 again
adiw r26,6 ; 299 movqi_insn/3[length = 3]
st X,__zero_reg__
sbiw r26,6
; Computes address in Z=r30 as Y+67
movw r30,r28 ; 397 *movhi/1[length = 1]
subi r30,-67 ; 300 addhi3_clobber/2[length = 2]
sbci r31,-1
; Still using X.
adiw r26,7 ; 301 movqi_insn/4[length = 3]
ld r24,X
sbiw r26,7
subi r24,lo8(-(48)) ; 302 addqi3/2[length = 1]
; Store '0' +...
st Z,r24 ; 303 movqi_insn/3[length = 1]
; What the dickens? Z++ after store to Z, why not just Z+ above?
adiw r30,1 ; 304 *addhi3/3 [length = 1]
ldi r24,lo8(10) ; 305 movqi_insn/2[length = 1]
st Z,r24 ; 306 movqi_insn/3[length = 1]
; Still using X
adiw r26,8 ; 307 *movhi/3[length = 3]
ld r22,X+
ld r23,X
; Moving Y to r24 and computing Y+67 *again*
movw r24,r28 ; 399 *movhi/1[length = 1]
subi r24,-69 ; 310 *addhi3/4 [length = 2]
sbci r25,-1
/* epilogue start */
; 7 * POP for epilogue
jmp u16_to_string; 311 call_value_insn/4 [length = 2]
A second spot with crazy expensive code; both code bloat and slow execu
[Bug testsuite/81626] New: Need effective target omp_target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81626 Bug ID: 81626 Summary: Need effective target omp_target Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- When we build a compiler with nvptx accelerator for openacc testing and test libgomp, we run into 308 FAIL/UNRESOLVED like this: ... FAIL: libgomp.fortran/target8.f90 -Os (test for excess errors) UNRESOLVED: libgomp.fortran/target8.f90 -Os compilation failed to produce executable ... The failure in more detail is a missing symbol __nvptx_uni: ... unresolved symbol __nvptx_uni collect2: error: ld returned 1 exit status mkoffload: fatal error: x86_64-none-linux-gnu-accel-nvptx-none-gcc returned 1 exit status compilation terminated. ... In order to run openmp nvptx offloading test, we need to compile all nvptx code with -mgomp. Compiling libgcc with -mgomp provides the missing symbol. Since the compiler as we configure it for openacc testing does not provide any multilibs with -mgomp, openmp nvptx offloading testing is not supported. If we add an effective target that tests if openmp offloading testing is supported, then we can use it to report UNSUPPORTED instead of FAIL/UNRESOLVED.
[Bug target/81492] internal compiler error: Segmentation fault (ia64 target with "-O1 -g" and __attribute__((optimize("O3"))))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81492 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Good, so it's known issue PR75750 which is fixed in GCC 6.4: commit ca9024ae9128af5bba2f2c770c5551ad02715ccf Author: jakub Date: Fri May 5 21:29:10 2017 + Backported from mainline 2017-02-21 Jakub Jelinek PR target/79570 * sel-sched.c (moveup_expr_cached): Don't call sel_bb_head on temporarily removed DEBUG_INSNs. * gcc.dg/pr79570.c: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch@247673 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug rtl-optimization/81625] GCC v4.7 ... v8 is bloating code by > 25% compared to v3.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81625 --- Comment #1 from Georg-Johann Lay --- Created attachment 41868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41868&action=edit Assembly as generated by 3.4.6 for reference.
[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77346 Arseny Solokha changed: What|Removed |Added Known to work||8.0 Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |push_reload, at |push_reload, at |reload.c:1350 |reload.c:1350 --- Comment #17 from Arseny Solokha --- -mno-lra has been recently removed on the 8 branch.
[Bug tree-optimization/81627] New: ICE on valid code at -O3: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81627
Bug ID: 81627
Summary: ICE on valid code at -O3: in
check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:707
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170731 (experimental) [trunk revision 250725] (GCC)
$
$ gcc-trunk -O2 small.c; ./a.out
$
$ gcc-trunk -O3 small.c
during GIMPLE pass: pcom
small.c: In function ‘fn1’:
small.c:3:6: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:707
void fn1 ()
^~~
0xdd5aed check_loop_closed_ssa_use
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:706
0xdd8b5e verify_loop_closed_ssa(bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:751
0xb6b1a9 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:2008
0xb6bac9 execute_todo
../../gcc-source-trunk/gcc/passes.c:2044
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$
-
int a, b, c, d[6], e, f;
void fn1 ()
{
for (b = 1; b < 5; b++)
{
for (c = 0; c < 5; c++)
d[b] = e;
if (a)
f++;
d[b + 1] = 1;
}
}
int main ()
{
fn1 ();
return 0;
}
[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|ASSIGNED|NEW
Component|tree-optimization |c++
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
0x0088d7d5 in cp_fold (x=)
at /tmp/trunk/gcc/cp/cp-gimplify.c:2251
2251x = fold_build2_loc (loc, code, TREE_TYPE (x), op0, op1);
Value returned is $25 = (tree_node *) 0x769e6640
(gdb) p debug_generic_expr (op1)
a
$26 = void
(gdb) p debug_generic_expr (op0)
(long int) d.c
$27 = void
(gdb) p debug_generic_expr (x)
(1 ? (int) (long int) d.c : 0) << a
$28 = void
because we run into
static tree
cp_fold (tree x)
{
...
case VEC_COND_EXPR:
case COND_EXPR:
...
/* A COND_EXPR might have incompatible types in branches if one or both
arms are bitfields. If folding exposed such a branch, fix it up. */
if (TREE_CODE (x) != code)
if (tree type = is_bitfield_expr_with_lowered_type (x))
x = fold_convert (type, x);
and fold (int) (long int) d.c to (long int) d.c here.
C++ FE bug.
Not sure why this isn't simply the following as we surely have to preserve
the type of the COND_EXPR when folding.
Index: gcc/cp/cp-gimplify.c
===
--- gcc/cp/cp-gimplify.c(revision 250725)
+++ gcc/cp/cp-gimplify.c(working copy)
@@ -2314,8 +2314,7 @@ cp_fold (tree x)
/* A COND_EXPR might have incompatible types in branches if one or both
arms are bitfields. If folding exposed such a branch, fix it up. */
if (TREE_CODE (x) != code)
- if (tree type = is_bitfield_expr_with_lowered_type (x))
- x = fold_convert (type, x);
+ x = fold_convert (TREE_TYPE (org_x), x);
break;
Leaving to C++ folks.
[Bug tree-optimization/81603] Various compiler UB on very large constant offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81603 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Mon Jul 31 08:22:14 2017 New Revision: 250727 URL: https://gcc.gnu.org/viewcvs?rev=250727&root=gcc&view=rev Log: PR tree-optimization/81603 * ipa-polymorphic-call.c (ipa_polymorphic_call_context::ipa_polymorphic_call_context): Perform offset arithmetic in offset_int, bail out if the resulting bit offset doesn't fit into shwi. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-polymorphic-call.c
[Bug tree-optimization/81627] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81627 Richard Biener changed: What|Removed |Added CC||amker at gcc dot gnu.org Version|unknown |8.0 Target Milestone|--- |8.0 Summary|ICE on valid code at -O3: |[8 Regression] ICE on valid |in |code at -O3: in |check_loop_closed_ssa_use, |check_loop_closed_ssa_use, |at |at |tree-ssa-loop-manip.c:707 |tree-ssa-loop-manip.c:707 --- Comment #1 from Richard Biener --- pcom -> Bin.
[Bug testsuite/81624] [8 Regression] FAIL: gcc.target/i386/pr59501-3a.c scan-assembler-not and[^\n\r]*sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81624 Richard Biener changed: What|Removed |Added Version|7.0 |8.0 Target Milestone|--- |8.0
[Bug debug/81623] [8 Regression] FAIL: g++.dg/debug/debug9.C -gstabs -O3 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81623 Richard Biener changed: What|Removed |Added Version|7.0 |8.0 Target Milestone|--- |8.0
[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.2
[Bug tree-optimization/81627] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81627 amker at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #2 from amker at gcc dot gnu.org --- Sorry for the breakage. I will investigate this.
[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81604 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Mon Jul 31 08:24:58 2017 New Revision: 250728 URL: https://gcc.gnu.org/viewcvs?rev=250728&root=gcc&view=rev Log: PR sanitizer/81604 * ubsan.c (ubsan_type_descriptor): For UBSAN_PRINT_ARRAY don't change type to the element type, instead add eltype variable and use it where we are interested in the element type. * c-c++-common/ubsan/pr81604.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr81604.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c
[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Started with r234384.
[Bug tree-optimization/49857] Put constant switch-tables into flash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #17 from Georg-Johann Lay --- Giving up on this. A working solution as patch series is here, so anyone can pick it up. http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01804.html http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01808.html http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01810.html Note that it only can be done for artificial data -- or you have to make sure that the data is not accessed by inline asm by different means (and of course, no pointers must escape, and a respective hook must not be called from within the C++ front-end). avr-part approval: http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01835.html gcc-part rejection as "too specific": http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01879.html
[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 --- Comment #5 from Marek Polacek --- cp_genericize_r does this fix-up too, and so has to cp_fold, but apparently what's in cp_fold isn't enough.
[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81604 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Jul 31 08:46:29 2017 New Revision: 250729 URL: https://gcc.gnu.org/viewcvs?rev=250729&root=gcc&view=rev Log: PR sanitizer/81604 * ubsan.c (ubsan_type_descriptor): For UBSAN_PRINT_ARRAY don't change type to the element type, instead add eltype variable and use it where we are interested in the element type. * c-c++-common/ubsan/pr81604.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/c-c++-common/ubsan/pr81604.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/ubsan.c
[Bug sanitizer/81530] [8 Regression] ICE in add_stmt in gcc/cp/semantics.c:387
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81530 --- Comment #1 from Martin Liška --- Author: marxin Date: Mon Jul 31 08:53:00 2017 New Revision: 250730 URL: https://gcc.gnu.org/viewcvs?rev=250730&root=gcc&view=rev Log: Do UBSAN sanitization just when current_function_decl != NULL_TREE (PR sanitize/81530). 2017-07-31 Martin Liska PR sanitize/81530 * cp-gimplify.c (cp_genericize): Guard condition with flag_sanitize_p also with current_function_decl non-null equality. * cp-ubsan.c (cp_ubsan_instrument_vptr_p): Likewise. * decl.c (compute_array_index_type): Likewise. * init.c (finish_length_check): Likewise. * typeck.c (cp_build_binary_op): Likewise. 2017-07-31 Martin Liska PR sanitize/81530 * c-convert.c (convert): Guard condition with flag_sanitize_p also with current_function_decl non-null equality. * c-decl.c (grokdeclarator): Likewise. * c-typeck.c (build_binary_op): Likewise. 2017-07-31 Martin Liska PR sanitize/81530 * convert.c (convert_to_integer_1): Guard condition with flag_sanitize_p also with current_function_decl non-null equality. 2017-07-31 Martin Liska PR sanitize/81530 * c-ubsan.c (ubsan_maybe_instrument_array_ref): Guard condition with flag_sanitize_p also with current_function_decl non-null equality. (ubsan_maybe_instrument_reference_or_call): Likewise. 2017-07-31 Martin Liska PR sanitize/81530 * g++.dg/ubsan/pr81530.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr81530.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-ubsan.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-convert.c trunk/gcc/c/c-decl.c trunk/gcc/c/c-typeck.c trunk/gcc/convert.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/cp-ubsan.c trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/81530] [8 Regression] ICE in add_stmt in gcc/cp/semantics.c:387
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81530 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Fixed.
[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81604 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Jul 31 08:56:03 2017 New Revision: 250732 URL: https://gcc.gnu.org/viewcvs?rev=250732&root=gcc&view=rev Log: PR sanitizer/81604 * ubsan.c (ubsan_type_descriptor): For UBSAN_PRINT_ARRAY don't change type to the element type, instead add eltype variable and use it where we are interested in the element type. * c-c++-common/ubsan/pr81604.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/c-c++-common/ubsan/pr81604.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/ubsan.c
[Bug target/81628] New: Backport r250637 and r250638 to the powerpcspe* target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81628 Bug ID: 81628 Summary: Backport r250637 and r250638 to the powerpcspe* target Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com CC: andrewjenner at gcc dot gnu.org, charlet at gcc dot gnu.org Target Milestone: --- Target: powerpcspe-*-linux-gnu* Revisions r250637 and r250638 remove -mno-lra (i.e. reload-based RA) from the rs6000 target, leaving -mlra as a stub. They also remove -mlra from one testcase specific to SPE targets. However, SPE support was factored out to its own target during the stage 1 of the gcc 8 branch lefiteme, after the point when LRA had been switched on for rs6000 by default, so -mlra and -mno-lra still make difference there. AFAICT, tests in testsuite/gcc.target/powerpc are shared by both targets now, so the changes in testsuite by the aforementioned revisions also affect both of them. Furtunately, changes in testsuite made there are safe, as they don't change RA used by the SPE target when compiling them. Nevertheless, it seems reasonable to disable reload for SPE as well, until two targets did not diverge too much.
[Bug c++/43745] [avr] g++ puts VTABLES in SRAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #11 from Georg-Johann Lay --- This cannot be fixed in GCC as C++ doesn't support ISO/IEC DTR 18037 named address spaces. This feature requires that the C++ front-end knows about ASes and handles them properly. This doesn't imply that ASes are exposed on language level; knowing about ASes "internally" would be sufficient. As it's pretty much clear that C++ WG21 will never accept such qualifiers (not even the C WG14) did, just close this as WON'T FIX. All that can be done is proposing work-arounds: Use "Embedded-C++" coding convention that avoids VTABLEs, or use a device that can host .rodata in flash like families -mmcu=avrtiny and -mmcu=avrxmega3.
[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81604 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Mon Jul 31 09:29:58 2017 New Revision: 250733 URL: https://gcc.gnu.org/viewcvs?rev=250733&root=gcc&view=rev Log: PR sanitizer/81604 * ubsan.c (ubsan_type_descriptor): For UBSAN_PRINT_ARRAY don't change type to the element type, instead add eltype variable and use it where we are interested in the element type. * c-c++-common/ubsan/pr81604.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/pr81604.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/ubsan.c
[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 --- Comment #6 from Marek Polacek --- Actually I think richi's fix is the right one. Let me test.
[Bug c/81629] New: redefined memcpy leads to segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81629
Bug ID: 81629
Summary: redefined memcpy leads to segmentation fault
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: frederic.besson at inria dot fr
Target Milestone: ---
Hi,
The simple code below crashes with internal compiler error: Segmentation
fault.
It seems gcc does not like the redefinition of memcpy.
extern unsigned long long memcpy(unsigned long long, unsigned long long,
unsigned long long);
void foo(unsigned long long ctx, unsigned long long output)
{
memcpy(ctx + 2LLU, ctx, 1U);
return;
}
Best regards,
[Bug c/81629] redefined memcpy leads to segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81629 --- Comment #1 from Frédéric Besson --- Created attachment 41869 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41869&action=edit preprcessed source
[Bug fortran/81581] runtime checks for DIM argument of intrinsic SUM missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81581 --- Comment #2 from Thomas Koenig --- Author: tkoenig Date: Mon Jul 31 09:34:36 2017 New Revision: 250735 URL: https://gcc.gnu.org/viewcvs?rev=250735&root=gcc&view=rev Log: 2017-07-31 Thomas Koenig PR fortran/81581 * m4/ifuntion.m4 (name`'rtype_qual`_'atype_code): Perform check for dim. (`m'name`'rtype_qual`_'atype_code): Likewise. Change type of rank and tim to index_type. (`s'name`'rtype_qual`_'atype_code): Perform check for dim. * generated/iall_i16.c: Regenerated. * generated/iall_i1.c: Regenerated. * generated/iall_i2.c: Regenerated. * generated/iall_i4.c: Regenerated. * generated/iall_i8.c: Regenerated. * generated/iany_i16.c: Regenerated. * generated/iany_i1.c: Regenerated. * generated/iany_i2.c: Regenerated. * generated/iany_i4.c: Regenerated. * generated/iany_i8.c: Regenerated. * generated/iparity_i16.c: Regenerated. * generated/iparity_i1.c: Regenerated. * generated/iparity_i2.c: Regenerated. * generated/iparity_i4.c: Regenerated. * generated/iparity_i8.c: Regenerated. * generated/maxloc1_16_i16.c: Regenerated. * generated/maxloc1_16_i1.c: Regenerated. * generated/maxloc1_16_i2.c: Regenerated. * generated/maxloc1_16_i4.c: Regenerated. * generated/maxloc1_16_i8.c: Regenerated. * generated/maxloc1_16_r10.c: Regenerated. * generated/maxloc1_16_r16.c: Regenerated. * generated/maxloc1_16_r4.c: Regenerated. * generated/maxloc1_16_r8.c: Regenerated. * generated/maxloc1_4_i16.c: Regenerated. * generated/maxloc1_4_i1.c: Regenerated. * generated/maxloc1_4_i2.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r10.c: Regenerated. * generated/maxloc1_4_r16.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i16.c: Regenerated. * generated/maxloc1_8_i1.c: Regenerated. * generated/maxloc1_8_i2.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r10.c: Regenerated. * generated/maxloc1_8_r16.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i16.c: Regenerated. * generated/maxval_i1.c: Regenerated. * generated/maxval_i2.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r10.c: Regenerated. * generated/maxval_r16.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc1_16_i16.c: Regenerated. * generated/minloc1_16_i1.c: Regenerated. * generated/minloc1_16_i2.c: Regenerated. * generated/minloc1_16_i4.c: Regenerated. * generated/minloc1_16_i8.c: Regenerated. * generated/minloc1_16_r10.c: Regenerated. * generated/minloc1_16_r16.c: Regenerated. * generated/minloc1_16_r4.c: Regenerated. * generated/minloc1_16_r8.c: Regenerated. * generated/minloc1_4_i16.c: Regenerated. * generated/minloc1_4_i1.c: Regenerated. * generated/minloc1_4_i2.c: Regenerated. * generated/minloc1_4_i4.c: Regenerated. * generated/minloc1_4_i8.c: Regenerated. * generated/minloc1_4_r10.c: Regenerated. * generated/minloc1_4_r16.c: Regenerated. * generated/minloc1_4_r4.c: Regenerated. * generated/minloc1_4_r8.c: Regenerated. * generated/minloc1_8_i16.c: Regenerated. * generated/minloc1_8_i1.c: Regenerated. * generated/minloc1_8_i2.c: Regenerated. * generated/minloc1_8_i4.c: Regenerated. * generated/minloc1_8_i8.c: Regenerated. * generated/minloc1_8_r10.c: Regenerated. * generated/minloc1_8_r16.c: Regenerated. * generated/minloc1_8_r4.c: Regenerated. * generated/minloc1_8_r8.c: Regenerated. * generated/minval_i16.c: Regenerated. * generated/minval_i1.c: Regenerated. * generated/minval_i2.c: Regenerated. * generated/minval_i4.c: Regenerated. * generated/minval_i8.c: Regenerated. * generated/minval_r10.c: Regenerated. * generated/minval_r16.c: Regenerated. * generated/minval_r4.c: Regenerated. * generated/minval_r8.c: Regenerated. * generated/norm2_r10.c: Regenerated. * generated/norm2_r16.c: Regenerated. * generated/norm2_r4.c: Regenerated. * generated/norm2_r8.c: Regenerated. * generated/parity_l16.c: Regenerated. * generated/parity_l1.c: R
[Bug fortran/81581] runtime checks for DIM argument of intrinsic SUM missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81581 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Koenig --- Fixed on trunk, closing.
[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81604 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed everywhere.
[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307 Jan Hubicka changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Jan Hubicka --- *** Bug 81623 has been marked as a duplicate of this bug. ***
[Bug debug/81623] [8 Regression] FAIL: g++.dg/debug/debug9.C -gstabs -O3 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81623 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hubicka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jan Hubicka --- This is bug in stabs output - I am not sure if we can support debug info for split functions there somehow. Added some info to PR81307 *** This bug has been marked as a duplicate of bug 81307 ***
[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 --- Comment #7 from rguenther at suse dot de --- On Mon, 31 Jul 2017, mpolacek at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 > > --- Comment #6 from Marek Polacek --- > Actually I think richi's fix is the right one. Let me test. Note for aggregate types fold_const might just ICE so I'm not 100% sure we don't need some more guards on it. Like if type != expected-type or so?
[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 --- Comment #8 from Marek Polacek --- I'm actually testing this --- a/gcc/cp/cp-gimplify.c +++ b/gcc/cp/cp-gimplify.c @@ -2314,9 +2314,9 @@ cp_fold (tree x) /* A COND_EXPR might have incompatible types in branches if one or both arms are bitfields. If folding exposed such a branch, fix it up. */ - if (TREE_CODE (x) != code) - if (tree type = is_bitfield_expr_with_lowered_type (x)) - x = fold_convert (type, x); + if (TREE_CODE (x) != code + && !useless_type_conversion_p (TREE_TYPE (org_x), TREE_TYPE (x))) + x = fold_convert (TREE_TYPE (org_x), x); break; so I hope that case is covered. We'll see.
[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 --- Comment #9 from rguenther at suse dot de --- On Mon, 31 Jul 2017, mpolacek at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 > > --- Comment #8 from Marek Polacek --- > I'm actually testing this > > --- a/gcc/cp/cp-gimplify.c > +++ b/gcc/cp/cp-gimplify.c > @@ -2314,9 +2314,9 @@ cp_fold (tree x) > >/* A COND_EXPR might have incompatible types in branches if one or both > arms are bitfields. If folding exposed such a branch, fix it up. */ > - if (TREE_CODE (x) != code) > - if (tree type = is_bitfield_expr_with_lowered_type (x)) > - x = fold_convert (type, x); > + if (TREE_CODE (x) != code > + && !useless_type_conversion_p (TREE_TYPE (org_x), TREE_TYPE (x))) > + x = fold_convert (TREE_TYPE (org_x), x); > >break; > > so I hope that case is covered. We'll see. Yeah, hopefully the FE doesn't mess up types for aggregates ;) useless_type_conversion_p should be fine in the gimplify hook.
[Bug go/81617] mksigtab.sh fails to resolve NSIG with glibc 2.26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81617 Andreas Schwab changed: What|Removed |Added Version|8.0 |7.0 Target Milestone|--- |7.2
[Bug middle-end/81629] redefined memcpy leads to segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81629 Richard Biener changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-07-31 Component|c |middle-end Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Use -ffreestanding or -fno-builtin-memcpy. We ICE because gimple_builtin_call_types_compatible_p doesn't detect the arg mismatch.
[Bug c/81629] redefined memcpy leads to segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81629 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|ASSIGNED|NEW Component|middle-end |c Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Richard Biener --- Oh. The real issue is that the FE registers the function with the bogus prototype as builtin. So gimple_builtin_call_types_compatible_p sees the call matches the prototype. That this is BUILT_IN_MEMCPY is simply a lie by the FE. Still invalid input. We also do not even warn about the bogus prototype given.
[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81592 --- Comment #2 from Arnd Bergmann --- I have scanned the linux kernel sources for related bogus warnings and found six others like this one that do not show up using gcc-7.1.1 without UBSAN but do show up with UBSAN added in: security/keys/proc.c: In function 'proc_keys_show': security/keys/proc.c:232:19: error: '%lu' directive writing between 1 and 20 bytes into a region of size 16 [-Werror=format-overflow=] sound/soc/fsl/fsl_sai.c: In function 'fsl_sai_probe': sound/soc/fsl/fsl_sai.c:837:21: error: '%d' directive writing between 1 and 10 bytes into a region of size 4 [-Werror=format-overflow=] drivers/block/cciss.c: In function 'cciss_init_one': drivers/block/cciss.c:5039:28: error: '%d' directive writing between 1 and 10 bytes into a region of size 3 [-Werror=format-overflow=] sound/isa/gus/gus_mem_proc.c: In function 'snd_gf1_mem_proc_init': sound/isa/gus/gus_mem_proc.c:72:27: error: '%i' directive writing between 1 and 10 bytes into a region of size 8 [-Werror=format-overflow=] sound/isa/gus/gus_mem_proc.c:72:18: note: directive argument in the range [0, 2147483646] drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_probe': drivers/net/ethernet/marvell/mvneta_bm.c:306:17: error: ',capacity' directive writing 9 bytes into a region of size between 1 and 10 [-Werror=format-overflow=] drivers/net/ethernet/marvell/mvneta_bm.c:306:3: note: 'sprintf' output between 15 and 24 bytes into a destination of size 15 drivers/pnp/pnpbios/proc.c: In function 'pnpbios_proc_exit': drivers/pnp/pnpbios/proc.c:338:18: error: '%02x' directive writing between 2 and 8 bytes into a region of size 3 [-Werror=format-overflow=] drivers/pnp/pnpbios/proc.c:338:17: note: directive argument in the range [0, 2147483646] drivers/mfd/max77620.c: In function 'max77620_probe': drivers/mfd/max77620.c:282:25: error: '%d' directive writing between 1 and 10 bytes into a region of size 7 [-Werror=format-overflow=] These are all similarly bogus to the original warning, in all cases it seems that gcc normally has no problems identifying the range. I can provide preprocessed source files for all instances if that helps.
[Bug target/81614] Should -mtune-ctrl=partial_reg_stall be turned by default?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81614 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Jan Hubicka --- There are two flags (which I believe was introduced by me) - partial-reg-stall which models behavior of PentiumPro where partial writes to register were cheap as long as the partially written register was never used in wider mode as the stall. - partial-reg-dependency which models later CPUs where partial writes are handled as read-mody-write instructions and thus slow even if the result is used only in same width as write. This was design of Athlons. The first flag avoids random optimizations which replace full sized instruction by part size (for example xol $1, eax is not changed to xorb to save size). Still we could generate partial register stalls out of combine. The second is trying to make sure we always read full register (by movzx). We set those as: DEF_TUNE (X86_TUNE_PARTIAL_REG_STALL, "partial_reg_stall", m_PPRO) DEF_TUNE (X86_TUNE_PARTIAL_REG_DEPENDENCY, "partial_reg_dependency", m_P4_NOCONA | m_CORE_ALL | m_BONNELL | m_SILVERMONT | m_INTEL | m_KNL | m_AMD_MULTIPLE | m_GENERIC) I would say that it makes no sense to have both X86_TUNE_PARTIAL_REG_STALL and X86_TUNE_PARTIAL_REG_DEPENDENCY set on one chip. According to Fog's manual indeed Core and later chips can rename partial registers again so they should be moved to X86_TUNE_PARTIAL_REG_STALL category and we should try to fix possible regressions. In the testcase given, for X86_TUNE_PARTIAL_REG_DEPENDENCY we ought to emit the dependency breaking instruction to clear full register before partial write when optimizing for speed. All AMD chips since Athlon are however X86_TUNE_PARTIAL_REG_DEPENDENCY design so for generic we will need to check what are the tradeoffs. I would say that X86_TUNE_PARTIAL_REG_DEPENDENCY is in general more conservative and works well for (X86_TUNE_PARTIAL_REG_STALL chips as the cases we produce partial write (sete) are relatively rare.
[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/25967] Add attribute naked for x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967 --- Comment #17 from uros at gcc dot gnu.org --- Author: uros Date: Mon Jul 31 10:22:41 2017 New Revision: 250736 URL: https://gcc.gnu.org/viewcvs?rev=250736&root=gcc&view=rev Log: PR target/25967 * config/i386/i386.c (ix86_function_naked): New function. (ix86_can_use_return_insn_p): Return false for naked functions. (ix86_expand_prologue): Skip prologue for naked functions. (ix86_expand_epilogue): Skip epilogue for naked functions and emit trap instruction. (ix86_warn_func_return): New function. (ix86_attribute_table): Add "naked" attribute specification. (TARGET_WARN_FUNC_RETURN): Define. * doc/extend.texi (x86 Function Attributes) : Document it. testsuite/ChangeLog: PR target/25967 * gcc.target/i386/naked-1.c: New test. * gcc.target/i386/naked-2.c: Ditto. * gcc.target/i386/naked-3.c: Ditto. * gcc.target/x86_64/abi/ms-sysv/ms-sysv.c: Remove do_test_body0 stub function, use attribute "naked" instead. * gcc.dg/pr44290-1.c: Use naked_functions effective target. * gcc.dg/pr44290-2.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/i386/naked-1.c trunk/gcc/testsuite/gcc.target/i386/naked-2.c trunk/gcc/testsuite/gcc.target/i386/naked-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr44290-1.c trunk/gcc/testsuite/gcc.dg/pr44290-2.c trunk/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c
[Bug c/81630] New: powl returns values with insufficient accuracy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81630
Bug ID: 81630
Summary: powl returns values with insufficient accuracy
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kakehi at waseda dot jp
Target Milestone: ---
Created attachment 41870
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41870&action=edit
compare powl(t,N) with exp2l(N*log2l(t))
I calculated powl(t,N) where t= (N+1)/N, N: an integer value 2^n (n: positive
integer) to get an approximation to Napier's constant.
Here is some results:
n powl(t, N)exp2l(N*log2l(t))
25: 2.7182817879534639155837683e+00 2.7182817879534906457209692e+00
26: 2.7182818082062409458920377e+00 2.7182818082062676638861742e+00
27: 2.7182818183325918449770586e+00 2.7182818183326563803766523e+00
28: 2.7182818233957862993910304e+00 2.7182818233958507905551755e+00
29: 2.7182818259273639105617903e+00 2.7182818259274480086548631e+00
30: 2.7182818271931621957604452e+00 2.7182818271932466208488932e+00
31: 2.7182818278260525070993969e+00 2.7182818278261459278132700e+00
32: 2.7182818278260525070993969e+00 2.7182818281425955814038786e+00
33: 2.7182818278260525070993969e+00 2.7182818283008204083076031e+00
34: 2.7182818278260525070993969e+00 2.7182818283799328217594654e+00
35: 2.7182818278260525070993969e+00 2.7182818284194890285938168e+00
As you see, powl(t,N) values have saturated when n>30, where exp2l(N*log2l(t)),
which is a formula mathematically equivalent to powl(t,N), produces increasing
values in converging to Napier's constant.
The values are obtained by the program "comparePow.c":
#include
#include
#include
/* checking the powl function.
*/
int main(int argc, char *argv[]){
if( argc==1 ){ printf("usage: $ comparePOW n [m]"); exit(-1);}
int n= atoi(argv[1]), m;
if( argc==2 ) m= n; else m= atoi(argv[2]);
for(int i= n; i<=m; i++){
long double N=powl(2.0, (long double)i);
if( N==N+1 ){ printf("too large N\n"); exit(-1); }
long double t= (N+1)/N;
long double powlx= powl(t,N);
long double powly= exp2l(N*log2l(t));
printf("%3d: %.25Le %.25Le\n", i, powlx, powly);
}
return 0;
}
by running it with the command "./a.out 25 35".
The command "gcc -v" produces:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/c++/4.2.1
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
[Bug target/25967] Add attribute naked for x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Uroš Bizjak --- Implemented for gcc 8.
[Bug target/81614] Should -mtune-ctrl=partial_reg_stall be turned by default?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81614 --- Comment #7 from Jan Hubicka --- As a historical note, X86_TUNE_PARTIAL_REG_STALL was moved to historical relics at the time both current designs (Penium 4 and Athlon) were using PARTIAL_REG_DEPENDENCY. I believed that main reason for this design was good perofrmance for 16bit code which is no longer a priority. It should have been pulled back when this concept was re-introduced for Pentium M and Cores (which i did not notice :)
[Bug c/81629] redefined memcpy leads to segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81629 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- We'll need something like -Wincompatible-library-redeclaration. If the user declares a library function and that declaration is not compatible, shout.
[Bug target/25967] Add attribute naked for x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967 --- Comment #19 from Daniel Santos --- (In reply to Uroš Bizjak from comment #18) > Implemented for gcc 8. Awesome! There are actually a number of times over the years that I've wished this were implemented, thanks! :)
[Bug c/81630] powl returns values with insufficient accuracy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81630 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Marc Glisse --- > Apple LLVM version 8.1.0 (clang-802.0.42) That's not gcc.
[Bug fortran/44292] [libgfortran ABI breakage] Increase internal size of RECL= of the OPEN statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44292 Thomas Koenig changed: What|Removed |Added Last reconfirmed|2010-05-30 05:38:00 |2017-7-31 CC||jvdelisle at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- Hi Jerry, should we also look at this when we bump the library number?
[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81400 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #5 from Martin Liška --- Adding to CC people who can know how initialization of TLS stack protection canary should work.
[Bug c/81631] New: -Wcast-qual false positive for pointer to array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81631
Bug ID: 81631
Summary: -Wcast-qual false positive for pointer to array
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc17 at cwde dot de
Target Milestone: ---
Hi,
--
typedef int footype[6];
extern void const * bar;
void baz(void)
{
footype const * x;
x = (footype const *) bar;
}
--
with -Wcast-qual, this yields
--
$ gcc -Wcast-qual -c foo.c
foo.c:12:7: warning: cast discards 'const' qualifier from pointer target type
[-Wcast-qual]
x = (footype const *) bar;
^
--
If "footype" is any other type than an array, I don't get the warning. I tested
gcc 4.5.1, 6.3.0, 7.1.0, on cygwin and Debian, all show this behavior. clang
doesn't warn.
[Bug testsuite/81626] Need effective target omp_target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81626 --- Comment #1 from Tom de Vries --- Created attachment 41871 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41871&action=edit Tentative patch
[Bug hsa/81477] HSA offloading regressions: "function cannot be cloned"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81477 --- Comment #4 from Martin Jambor --- Author: jamborm Date: Mon Jul 31 11:18:31 2017 New Revision: 250738 URL: https://gcc.gnu.org/viewcvs?rev=250738&root=gcc&view=rev Log: [PR 81477] Set versionable regardless of optimization level 2017-07-31 Martin Jambor PR hsa/81477 * ipa-fnsummary.c (ipa_fn_summary_generate): Set versionable regardless of optimization level. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-fnsummary.c
[Bug hsa/81477] HSA offloading regressions: "function cannot be cloned"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81477 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Jambor --- Fixed.
[Bug tree-optimization/81588] [7/8 Regression] Wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81588 Jakub Jelinek changed: What|Removed |Added Attachment #41860|0 |1 is obsolete|| --- Comment #3 from Jakub Jelinek --- Created attachment 41872 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41872&action=edit gcc8-pr81588.patch Untested fix - second attempt.
[Bug testsuite/81626] Need effective target omp_target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81626 --- Comment #2 from Jakub Jelinek --- Ugh, that is going to be a maintainance nightmare for the testsuite. Why and how are you configuring your accel compiler without the OpenMP support?
[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jan.kratochvil at redhat dot
com,
||palves at redhat dot com
--- Comment #3 from Jakub Jelinek ---
For the N_SLINE stuff, I guess something like:
--- dbxout.c.jj 22017-07-29 09:50:38.0 +0200
+++ dbxout.c 2017-07-31 14:30:00.474385901 +0200
@@ -1273,7 +1273,8 @@ dbxout_source_line (unsigned int lineno,
#ifdef DBX_OUTPUT_SOURCE_LINE
DBX_OUTPUT_SOURCE_LINE (asm_out_file, lineno, dbxout_source_line_counter);
#else
- if (DBX_LINES_FUNCTION_RELATIVE)
+ if (DBX_LINES_FUNCTION_RELATIVE
+ && in_cold_section_p == first_function_block_is_cold)
{
char begin_label[20];
dbxout_begin_stabn_sline (lineno);
could cure that part. No idea how the debugger finds out if it is absolute or
relative though.
Then there is DBX_BLOCKS_FUNCTION_RELATIVE macro which decides if N_LBRAC or
N_RBRAC should be relative to start of function or not. Again, no idea how the
debugger finds out if it is relative or absolute.
So I guess we need help from the debugger folks here...
[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307 --- Comment #4 from Jakub Jelinek --- Looking at gdb I see though that the block_address_function_relative variable is computed from the object format, so I'm afraid it has to be relative. Another option is to pretend there isn't just one function, but two with the same origin. As -g* options shouldn't affect code generation, we can hardly disable hot/cold partitioning if -gstabs is used.
[Bug testsuite/81624] [8 Regression] FAIL: gcc.target/i386/pr59501-3a.c scan-assembler-not and[^\n\r]*sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81624 H.J. Lu changed: What|Removed |Added CC|hjl at gcc dot gnu.org |jakub at redhat dot com Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment #1 from H.J. Lu --- A patch was posted at https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00400.html and waiting from review from Jakub: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01568.html H.J.
[Bug target/25967] Add attribute naked for x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967 --- Comment #20 from uros at gcc dot gnu.org --- Author: uros Date: Mon Jul 31 13:11:59 2017 New Revision: 250742 URL: https://gcc.gnu.org/viewcvs?rev=250742&root=gcc&view=rev Log: PR target/25967 * config/i386/i386.c (ix86_allocate_stack_slots_for_args): New function. (TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS): Define. testsuite/ChangeLog: PR target/25967 * gcc.target/i386/naked-3.c (dg-options): Use -O0. (naked): Add attribute regparm(1) for x86_32 targets. Add integer argument. Remove global "data" variable. (main): Pass integer argument to naked function. * gcc.target/i386/naked-4.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/naked-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/naked-3.c
[Bug libstdc++/81599] Error in documentation of std::stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81599 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-31 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. I'll send a patch.
[Bug target/25967] Add attribute naked for x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967 --- Comment #21 from Uroš Bizjak --- The above patch is needed to pass arguments to a naked function. Please note that arguments can be reliably passed only in registers, so regparm convention is necessary for x86_32. gcc.target/i386/naked-3.c and gcc.target/i386/naked-4.c testcases show function arguments and function result passing in action.
[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81400 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #6 from Alexander Monakov --- TLS canary is initialized by the libc; in Glibc sources you can grep for THREAD_STACK_SET_GUARD. In this example the leftmost byte of the SSP canary is overwritten by a zero. This does not change the canary because Glibc deliberately zeroes that leftmost byte (presumably, to harden against information-leak attacks when a string function like strcpy can be used to copy the canary value in an attacker-controlled manner): https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/dl-osinfo.h;h=823cd8224df939134018fbd8f0227e9f501393ab;hb=HEAD#l63 So what is the GCC bug here? What do we want to change?
[Bug libstdc++/81599] Error in documentation of std::stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81599 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/81632] New: spurious -Wterminate warning about throw in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81632
Bug ID: 81632
Summary: spurious -Wterminate warning about throw in destructor
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
In the following piece of code GCC issues a spurious warning about an exception
that escapes a dtor, although it is actually caught.
Observed with GCC 6 and 7. GCC 5 does not feature -Wterminate.
$ cat /tmp/foo.cc
struct foo
{
~foo()
{
try
{
throw 42;
}
catch (int)
{
throw;
}
catch (...)
{
}
}
};
int main()
{
}
$ g++-mp-6 --version
g++-mp-6 (MacPorts gcc6 6.3.0_2) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-mp-6 -Wterminate /tmp/foo.cc -std=c++14
/tmp/foo.cc: In destructor 'foo::~foo()':
/tmp/foo.cc:11:9: warning: throw will always call terminate() [-Wterminate]
throw;
^
/tmp/foo.cc:11:9: note: in C++11 destructors default to noexcept
$ g++-mp-7 --version
g++-mp-7 (MacPorts gcc7 7-20170622_0) 7.1.
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-mp-7 -Wterminate /tmp/foo.cc -std=c++14
/tmp/foo.cc: In destructor 'foo::~foo()':
/tmp/foo.cc:11:9: warning: throw will always call terminate() [-Wterminate]
throw;
^
/tmp/foo.cc:11:9: note: in C++11 destructors default to noexcept
There is no such warning if this try/catch is wrapped in another one, so that's
really just the logic of bouncing to another catch clause that is missing.
Cheers!
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-07-31 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > I was under the impression that I would get a test0.i file since the only > documentation of using -save-temps I can find comes from the gcc docs: > https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-save-temps Which says Store the usual “temporary” intermediate files permanently. > which mentions *.i files in their example. because the compiled file is a C file. The *.i (*.ii) files are C (C++ files), thus cannot (shall not) be produced by gfortran. As noticed in comment 0, -save-temps generates a preprocessed *.f90 if it does not already exists. Note that INCLUDE statements are ignored. IMO this PR should be closed as INVALID or WONTFIX.
[Bug libstdc++/81599] Error in documentation of std::stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81599 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Mon Jul 31 13:44:16 2017 New Revision: 250743 URL: https://gcc.gnu.org/viewcvs?rev=250743&root=gcc&view=rev Log: PR libstdc++/81599 * include/bits/stl_stack.h: Fix typo. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_stack.h
[Bug libstdc++/81599] Error in documentation of std::stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81599 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c/51515] Unable to forward declare nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51515 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Because it's not valid C.
[Bug libgomp/81591] segmentation fault when using priorities of nested tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81591 --- Comment #3 from Jakub Jelinek --- I think we need a reproducer for this. Can you provide something?
[Bug libgomp/81591] segmentation fault when using priorities of nested tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81591 --- Comment #4 from Jakub Jelinek --- Before that is available, perhaps backtrace from the gomp_fatal call in the _LIBGOMP_CHECKING_ enabled build might be also useful.
[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622 --- Comment #1 from Bill Schmidt --- Do you see the same behavior with "vec_ld (1, 2);" ?
[Bug tree-optimization/81633] New: Incorrect floating point result with tree vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81633 Bug ID: 81633 Summary: Incorrect floating point result with tree vectoriser Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wence at gmx dot li Target Milestone: --- Created attachment 41873 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41873&action=edit Preprocessed source. The attached source (reduced from a real kernel) multiplies a 4x4 identity matrix by its first column, It should produce the output: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 With GCC 7.1.0, (and a recent 8.0.0 snapshot) it produces instead: 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 The bug disappears if I say either -fno-tree-vectorize or -fno-tree-loop-vectorize $ gcc -o prog.exe -Wall -Wextra -std=c99 -pedantic -O3 -v prog.c Using built-in specs. COLLECT_GCC=/opt/wandbox/gcc-7.1.0/bin/gcc COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-7.1.0/configure --prefix=/opt/wandbox/gcc-7.1.0 --enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release --disable-nls LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-7.1.0/lib,-rpath,/opt/wandbox/gcc-7.1.0/lib64,-rpath,/opt/wandbox/gcc-7.1.0/lib32 --enable-lto Thread model: posix gcc version 7.1.0 (GCC) COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-Wpedantic' '-std=c99' '-Wall' '-Wextra' '-O3' '-v' '-mtune=generic' '-march=x86-64' /opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1 -quiet -v -imultiarch x86_64-linux-gnu prog.c -quiet -dumpbase prog.c -mtune=generic -march=x86-64 -auxbase prog -O3 -Wpedantic -Wall -Wextra -std=c99 -version -o /tmp/ccorXUPc.s GNU C99 (GCC) version 7.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include /opt/wandbox/gcc-7.1.0/include /opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C99 (GCC) version 7.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 5122689c716743eb07fee255d0dfe7c4 COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-Wpedantic' '-std=c99' '-Wall' '-Wextra' '-O3' '-v' '-mtune=generic' '-march=x86-64' as -v --64 -o /tmp/cc0c1aeA.o /tmp/ccorXUPc.s GNU assembler version 2.26.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.26.1 COMPILER_PATH=/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-Wpedantic' '-std=c99' '-Wall' '-Wextra' '-O3' '-v' '-mtune=generic' '-march=x86-64' /opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/collect2 -plugin /opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/liblto_plugin.so -plugin-opt=/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccfS7LEX.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o prog.exe /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/crtbegin.o -L/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0 -L/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../.. -rpath /opt/wandbox/gcc-7.1.0/lib64 /tmp/cc0c1aeA.o -lgcc --as-needed -lgcc_s --
[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-31 Ever confirmed|0 |1 --- Comment #2 from Bill Schmidt --- Never mind, it fails that way as well. Confirmed. I had thought we had seen and fixed this scenario some time ago...
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #2 from Ben Barrowes --- Then how does one get a preprocessed/savetemp file from an existing *.f90 file? In the case of C, preprocessed and temp files have different extensions and are thus easily identified after compiling. For gfortran, preprocessing/saveingtemps of *.f files produces *.f90 files which is confusing, and preprocessing/savetemps of *.f90 files produces no output. Gfortran needs to produce preprocessed/savetemps that have unique and easily identifiable extensions. If not *.i and *.i90, then something else like *.t and *.t90 or similar.
[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622 Bill Schmidt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #3 from Bill Schmidt --- Mine, need to avoid an optimization when we don't have a pointer/array type.
[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622 --- Comment #4 from Bill Schmidt --- Created attachment 41874 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41874&action=edit Patch under test
[Bug testsuite/81626] Need effective target omp_target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81626 Thomas Schwinge changed: What|Removed |Added Keywords|openacc | Status|UNCONFIRMED |WAITING Last reconfirmed||2017-07-31 Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Thomas Schwinge --- Yeah, I suppose you just need to remove a "--disable-multilib" from your nvptx offloading GCC build configuration, so that the "mgomp" multilib gets built in addition to the "default" one?
[Bug c++/81618] Warn for unused functions declared in local scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81618
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-07-31
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Martin Sebor ---
This request makes sense to me as an enhancement to -Wunused-function. With
all the different forms of initialization in C++, it's not rare to accidentally
declare a function when a variable is intended, e.g., like so:
template
void f ()
{
T x (); // declares an external function
T y (T ()); // ditto
}
These mistakes are usually exposed when the symbol is used in a context where
an object is expected but extending -Wunused-function to diagnose locally
declared functions would help detect those that are not.
[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Created attachment 41875
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41875&action=edit
gcc8-pr81622.patch
There are many other issues in that function.
As for ARRAY_TYPE, do you have a testcase that would show how you could end up
with ARRAY_TYPE there? I mean, C/C++ array-to-pointer conversion should happen
already before this function is called. Or can say passing reference-to-array
result in that?
There is another issue I haven't fixed, because it means adjusting hundreds of
tests:
error ("Builtin function %s not supported in this compiler configuration",
should not use capital letter in Builtin, that is against GCC diagnostic
conventions.
[Bug c++/81634] New: Some types are incorrectly detected as not standard layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81634
Bug ID: 81634
Summary: Some types are incorrectly detected as not standard
layout
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raskolnikov at gnu dot org
Target Milestone: ---
The following code fails to compile with GCC 7.1.0 when passing -std=c++17:
```
#include
struct a {};
struct b { int x; };
struct ca : a {};
struct cb : ca { b x; };
static_assert(std::is_standard_layout::value, "");
```
https://wandbox.org/permlink/DjuHERFFvgJg84ub
Instead of using `is_standard_layout`, we can detect the bug by using
`offsetof(cb, b)`, which incorrectly rises a warning about `cb` not being
standard layout.
It does work as expected, with -std=c++14 or with other versions of GCC.
[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622 --- Comment #6 from Jakub Jelinek --- The aligned computation also looks like invalid IL, BIT_AND_EXPR should not have pointer arguments I believe (though please double check with Richard), so it should be first cast to corresponding integral type with the same precision, then masked and then cast back to the pointer type.
[Bug testsuite/81626] Need effective target omp_target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81626 --- Comment #4 from Tom de Vries --- (In reply to Thomas Schwinge from comment #3) > Yeah, I suppose you just need to remove a "--disable-multilib" from your > nvptx offloading GCC build configuration, so that the "mgomp" multilib gets > built in addition to the "default" one? It would be great if it is that simple. Have you ever tried that? I see you're the one who's added the "--disable-multilib" in our nvptx offloading GCC build configuration (which is what I'm using). What was the reason for that?
[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #15 from Uroš Bizjak ---
I'm testing the following patch:
--cut here--
Index: i386.c
===
--- i386.c (revision 250745)
+++ i386.c (working copy)
@@ -19421,8 +19421,10 @@ ix86_print_operand_address_as (FILE *file, rtx add
fputs (string, file);
}
- /* Use one byte shorter RIP relative addressing for 64bit mode. */
- if (TARGET_64BIT && !base && !index && !no_rip)
+ /* Use one byte shorter RIP relative addressing for
+ symbols in the generic address space. */
+ if (TARGET_64BIT && !base && !index
+ && ADDR_SPACE_GENERIC_P (as) && !no_rip)
{
rtx symbol = disp;
@@ -19442,7 +19444,7 @@ ix86_print_operand_address_as (FILE *file, rtx add
/* Displacement only requires special attention. */
if (CONST_INT_P (disp))
{
- if (ASSEMBLER_DIALECT == ASM_INTEL && parts.seg ==
ADDR_SPACE_GENERIC)
+ if (ASSEMBLER_DIALECT == ASM_INTEL && ADDR_SPACE_GENERIC_P (as))
fputs ("ds:", file);
fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (disp));
}
--cut here--
The patched compiler compiles following testcase:
--cut here--
int __seg_gs a;
void test_as (void)
{
a += 1;
}
__thread int b;
void test_thr (void)
{
b += 2;
}
--cut here--
to:
test_as:
addl$1, %gs:a
ret
test_thr:
addl$2, %fs:b@tpoff
ret
[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81633 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-31 CC||alahay01 at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |7.2 Summary|Incorrect floating point|[7/8 Regression] Incorrect |result with tree vectoriser |floating point result with ||tree vectoriser Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r239542.
[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81633 --- Comment #2 from Jakub Jelinek --- In -fdump-tree-vect-details, the difference with this commit is: --- pr81633.c.149t.vect.239539 2017-07-31 12:00:11.0 -0400 +++ pr81633.c.149t.vect.239542 2017-07-31 12:00:33.0 -0400 @@ -1721,8 +1721,8 @@ pr81633.c:10:5: note: vect_is_simple_use pr81633.c:10:5: note: def_stmt: _69 = identity[j_31][0]; pr81633.c:10:5: note: type of def: internal pr81633.c:10:5: note: transform binary/unary operation. -pr81633.c:10:5: note: add new stmt: vect__71.20_33 = vect__69.14_23 * vect__69.18_14; -pr81633.c:10:5: note: add new stmt: vect__71.20_19 = vect__69.15_22 * vect__69.19_18; +pr81633.c:10:5: note: add new stmt: vect__71.20_33 = vect__69.14_23 * vect__69.14_23; +pr81633.c:10:5: note: add new stmt: vect__71.20_19 = vect__69.15_22 * vect__69.15_22; pr81633.c:10:5: note: -->vectorizing SLP node starting from: tmp[j_31][0] = _71; pr81633.c:10:5: note: vect_is_simple_use: operand _71 pr81633.c:10:5: note: def_stmt: _71 = _69 * _69; @@ -1753,8 +1753,8 @@ pr81633.c:10:5: note: -->vectorizing pr81633.c:10:5: note: -->vectorizing statement: vectp_identity.16_5 = vectp_identity.16_17 + 16; pr81633.c:10:5: note: -->vectorizing statement: vect__69.19_18 = MEM[(double *)vectp_identity.16_5]; pr81633.c:10:5: note: -->vectorizing statement: _91 = identity[j_31][3]; -pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_33 = vect__69.14_23 * vect__69.18_14; -pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_19 = vect__69.15_22 * vect__69.19_18; +pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_33 = vect__69.14_23 * vect__69.14_23; +pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_19 = vect__69.15_22 * vect__69.15_22; pr81633.c:10:5: note: -->vectorizing statement: _92 = _69 * _91; pr81633.c:10:5: note: -->vectorizing statement: MEM[(double *)vectp_tmp.21_16] = vect__71.20_33; pr81633.c:10:5: note: -->vectorizing statement: vectp_tmp.21_87 = vectp_tmp.21_16 + 16; @@ -1864,8 +1864,8 @@ main () vectp_identity.16_5 = vectp_identity.16_17 + 16; vect__69.19_18 = MEM[(double *)vectp_identity.16_5]; _91 = identity[j_31][3]; - vect__71.20_33 = vect__69.14_23 * vect__69.18_14; - vect__71.20_19 = vect__69.15_22 * vect__69.19_18; + vect__71.20_33 = vect__69.14_23 * vect__69.14_23; + vect__71.20_19 = vect__69.15_22 * vect__69.15_22; _92 = _69 * _91; MEM[(double *)vectp_tmp.21_16] = vect__71.20_33; vectp_tmp.21_87 = vectp_tmp.21_16 + 16; The multiplication has different operands, so the newer output looks clearly wrong.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Thomas Koenig --- I agree that the current handling of *.f90 and *.f with -cpp and -save-temps is undocumented and partially broken. Consider creating a *.f90 file from a *.f file: $ cat foo.f programme main end $ gfortran -cpp -save-temps foo.f $ cat foo.f90 # 1 "foo.f" # 1 "" # 1 "" # 1 "foo.f" programme main end $ gfortran foo.f90 foo.f90:1:13: # 1 "foo.f" 1 Fehler: Ungültige Form der PROGRAM-Anweisung bei (1) Here, we generate a fixed-form program source with an extension that is usually an indicator of fixed form. One possibility would be to disable -save-temps together with -cpp when the source file is *.f or *.f90 (or *.f03). Creating *.f90 from *.F90 is also dangerous on Windows systems. I think creating *.i and *.i90 files, respectively, would be a better option. ifort does so, so there is at least some precedent.
[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81633 --- Comment #3 from Jakub Jelinek --- In *.ifcvt dump we have _69 = identity[j_31][0]; _71 = _69 * _69; tmp[j_31][0] = _71; _77 = identity[j_31][1]; _78 = _69 * _77; tmp[j_31][1] = _78; _84 = identity[j_31][2]; _85 = _69 * _84; tmp[j_31][2] = _85; _91 = identity[j_31][3]; _92 = _69 * _91; tmp[j_31][3] = _92; but the fact that the first stmt is _69 * _69 doesn't mean the whole SLP is a square of another vector.
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-31 Ever confirmed|0 |1 --- Comment #60 from Dominique d'Humieres --- At revision r250610 I still see WARNING: Could not generate /opt/gcc/build_w/gcc/testsuite/gcc/ms-sysv/ms-sysv-generated.h WARNING: Could not generate /opt/gcc/build_w/gcc/testsuite/gcc/ms-sysv/ms-sysv-generated.h WARNING: Could not generate /opt/gcc/build_w/gcc/testsuite/gcc/ms-sysv/ms-sysv-generated.h WARNING: Could not generate /opt/gcc/build_w/gcc/testsuite/gcc/ms-sysv/ms-sysv-generated.h WARNING: Could not generate /opt/gcc/build_w/gcc/testsuite/gcc5/ms-sysv/ms-sysv-generated.h WARNING: Could not generate /opt/gcc/build_w/gcc/testsuite/gcc5/ms-sysv/ms-sysv-generated.h WARNING: Could not generate /opt/gcc/build_w/gcc/testsuite/gcc5/ms-sysv/ms-sysv-generated.h WARNING: Could not generate /opt/gcc/build_w/gcc/testsuite/gcc5/ms-sysv/ms-sysv-generated.h FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O0 -g3 "-DGEN_ARGS=-p0\\ --omit-rbp-clobbers" (test for excess errors) UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O0 -g3 "-DGEN_ARGS=-p0\\ --omit-rbp-clobbers" compilation failed to produce executable FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O2 "-DGEN_ARGS=-p0" (test for excess errors) UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O2 "-DGEN_ARGS=-p0" compilation failed to produce executable FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O2 "-DGEN_ARGS=-p1" (test for excess errors) UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O2 "-DGEN_ARGS=-p1" compilation failed to produce executable FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O2 "-DGEN_ARGS=-p5" (test for excess errors) UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O2 "-DGEN_ARGS=-p5" compilation failed to produce executable FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O0 -g3 "-DGEN_ARGS=-p0\\ --omit-rbp-clobbers" (test for excess errors) UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O0 -g3 "-DGEN_ARGS=-p0\\ --omit-rbp-clobbers" compilation failed to produce executable FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2 "-DGEN_ARGS=-p0" (test for excess errors) UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2 "-DGEN_ARGS=-p0" compilation failed to produce executable FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2 "-DGEN_ARGS=-p1" (test for excess errors) UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2 "-DGEN_ARGS=-p1" compilation failed to produce executable FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2 "-DGEN_ARGS=-p5" (test for excess errors) UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2 "-DGEN_ARGS=-p5" compilation failed to produce executable with -m64 (see https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg02582.html). Looking at the log file, I see spawn -ignore SIGHUP /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ /opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -m64 -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -DGEN_ARGS=-p1 -I/opt/gcc/build_w/gcc/testsuite/gcc1/ms-sysv -I/opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv -Wall -Wall /opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S -lm -o ./ms-sysv.exe^M /opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:136:37: warning: 'do_tests' used but never defined^M /opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:345:39: warning: 'check_results' defined but not used [-Wunused-function]^M /opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:227:1: warning: 'init_test' defined but not used [-Wunused-function]^M Undefined symbols for architecture x86_64:^M "_do_tests", referenced from:^M _main in cciP9N43.o^M ld: symbol(s) not found for architecture x86_64^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O2 "-DGEN_ARGS=-p1" (test for excess errors) but the test compiles if I compile it manually.
