[Bug preprocessor/70518] Conditional compilation of #line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70518 --- Comment #1 from Kyle Guinn --- Created attachment 38168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38168&action=edit generated code
[Bug preprocessor/70518] New: Conditional compilation of #line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70518
Bug ID: 70518
Summary: Conditional compilation of #line directives
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: elyk03 at gmail dot com
Target Milestone: ---
Created attachment 38167
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38167&action=edit
template file
I am generating C code based on a template file. The result has #line
directives that switch between the template and the generated code. If any of
those #line directives appear within a disabled #if-block, then they are
currently being skipped. This leads to weird behavior and misleading error
messages.
Let me explain my setup. (It's actually from an old fork of Bison.) The
template file consists of blocks of text delimited by "$". These blocks are
inserted into the generated code, with #line directives before and after.
Block 1 contains an #if. Block 2 contains the matching #endif, followed by
something that depends on the line number. I've added two examples, one that
causes a compile error (for the file:line in the error message), and one that
uses __FILE__ and __LINE__. Block 3 is extra padding.
Here is main.c (generated) with the first two blocks inserted from the
template, and the #if disabled:
#include
#define FOO 0
int main(int argc, char *argv[])
{
#line 2 "template.c" /* start block 1 */
#if FOO
#line 8 "main.c" /* end block 1 */
int foo;
int bar;
#line 4 "template.c" /* start block 2 */
#endif
int oops[-1];
printf("%s:%d\n", __FILE__, __LINE__);
#line 15 "main.c" /* end block 2 */
return 0;
}
Because the #if is disabled, it is interpreting the location of "oops" to be
template.c:8 (from "start block 1" plus 6 lines) instead of its actual location
at template.c:5 (equal to "start block 2" plus 1 line)
And consistent with that, __FILE__ and __LINE__ on the next line are
template.c:9 instead of template.c:6.
Should #line be processed unconditionally? I know the preprocessor has to keep
track of nested #if blocks so that it can find the matching #endif when the
block is disabled. This seems like a corner case that I don't know if the C
standard ever considers. If so, it may simplify the next part.
The bug: Misleading error messages. It opens template.c and prints line 8
from it (assuming this file exists and has at least 8 lines). It's not the
offending line; it could be any text:
template.c: In function ‘main’:
template.c:8:6: error: size of array ‘oops’ is negative
/* template.c line 8 */
^
Also note the "In function ‘main’" message is using template.c instead of the
actual file that main appears in (main.c) and that __FILE__ is set to at the
start of its definition.
Somehow clang prints out the right offending statement but keeps the
"template.c:8" text:
template.c:8:11: error: 'oops' declared as an array with a negative size
int oops[-1];
^~
[Bug target/67391] [SH] Convert clrt addc to normal add insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #34 from Oleg Endo --- The patches for this PR (r228176, r228201) have triggered PR 70416.
[Bug tree-optimization/70509] wrong code with extract from a v64qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70509 --- Comment #3 from Marc Glisse --- (In reply to Zdenek Sojka from comment #2) > (In reply to Zdenek Sojka from comment #0) > > First broken dump seems to be .forwprop, where is: > > .forwprop4 , that is. The problem might be that simplify_bitfield_ref() does: > tree-ssa-forwprop.c > ... > 1793: index = build_int_cst (TREE_TYPE (TREE_TYPE (m)), idx * size); > ... > > which builds the index of type "unsigned char", which wraps around from 256 > to 0. > Is there any reason to have index of type "TREE_TYPE (TREE_TYPE (m))" in > that statement? Rereading this a few years later, I have no idea why I used that type. bitsize_int would make more sense...
[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70416 --- Comment #23 from Oleg Endo --- (In reply to Oleg Endo from comment #21) > I'll see if there's some other way... With the patch below, I get sum: 3342539 -> 3342639+100 / +0.002992 % for the CSiBE set. The increases are because r14 is used as an alias for r15 and the extra checks in the pattern only look for r15. However, it seems that for most cases it's good enough the code size increases as mentioned in comment #18. I guess the proper solution for this issue would be running an address-mode-selection optimization pass after reload to fix up the reload choices. Probably it would also be beneficial when using LRA. I'm now re-testing the patch on sh-elf. Index: gcc/config/sh/sh.md === --- gcc/config/sh/sh.md (revision 234506) +++ gcc/config/sh/sh.md (working copy) @@ -2242,14 +2242,23 @@ [(set_attr "type" "arith")]) ;; Old reload might generate add insns directly (not through the expander) for -;; the memory address of complex insns like atomic insns when reloading. +;; address register calculations when reloading, in which case it won't try +;; the addsi_scr pattern. Because reload will sometimes try to validate +;; the generated insns and their constraints, this pattern must be +;; recognizable during and after reload. However, when reload generates +;; address register calculations for the stack pointer, we don't allow this +;; pattern. This will make reload prefer using indexed @(reg + reg) address +;; modes when the displacement of a @(disp + reg) doesn't fit. (define_insn_and_split "*addsi3" [(set (match_operand:SI 0 "arith_reg_dest" "=r") (plus:SI (match_operand:SI 1 "arith_reg_operand" "r") (match_operand:SI 2 "arith_or_int_operand" "rn")))] "TARGET_SH1 && !sh_lra_p () - && reload_completed - && !reg_overlap_mentioned_p (operands[0], operands[1])" + && (reload_completed || reload_in_progress) + && !reg_overlap_mentioned_p (operands[0], operands[1]) + && (!reload_in_progress + || ((!REG_P (operands[1]) || REGNO (operands[1]) != SP_REG) + && (!REG_P (operands[2]) || REGNO (operands[2]) != SP_REG)))" "#" "&& 1" [(set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))]
[Bug bootstrap/70173] make distclean: leaves stage_final and libcc1/compiler-name.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70173 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-03 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- It also leaves gnattools/config.cache and an empty gotools/ . Confirmed.
[Bug tree-optimization/70509] wrong code with extract from a v64qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70509 --- Comment #2 from Zdenek Sojka --- (In reply to Zdenek Sojka from comment #0) > First broken dump seems to be .forwprop, where is: .forwprop4 , that is. The problem might be that simplify_bitfield_ref() does: tree-ssa-forwprop.c ... 1793: index = build_int_cst (TREE_TYPE (TREE_TYPE (m)), idx * size); ... which builds the index of type "unsigned char", which wraps around from 256 to 0. Is there any reason to have index of type "TREE_TYPE (TREE_TYPE (m))" in that statement? or am I reading the code incorrectly?
[Bug c++/70514] Variable length arrays lead to garbage in another array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70514
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||msebor at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Martin Sebor ---
There are known problems with VLAs in G++ (see bug 16994) but I don't think
this is one of them. I suspect the problem you are seeing is due to the
sort_of_sieve() function writing past the end of the variable length array
allocated in factorize() as underlined below. With that fixed, the output is
as expected. I'm going to close this report as invalid but feel free to reopen
it if you think I missed something.
As an aside, even though I would expect Address Sanitizer to find the bug in
the program, it doesn't (or at least not reliably and it when it does catch it,
it fails to indicate what caused it). I would view that as a bug in the
sanitizer and suggest opening one for it.
void sort_of_sieve(bool primes[], int n) {
for (int i = 2; i <= n; i++) {
^^
primes[i] = true;
}
}
void factorize(int n, int OUT[]) {
bool primes[n];
^
int factors = 0;
sort_of_sieve(primes, n);
^
With -fsanitize=address, when the program does crash (it doesn't always), I get
one of the following two reports:
ASAN:DEADLYSIGNAL
=
==20465==ERROR: AddressSanitizer: stack-overflow on address 0x7fffdeac (pc
0x00400be7 bp 0x7fffdeabd330 sp 0x7fffdeabd2e0 T0)
#0 0x400be6 in factorize(int, int*) (/home/msebor/build/tmp/a.out+0x400be6)
#1 0x400d19 in main (/home/msebor/build/tmp/a.out+0x400d19)
#2 0x7fbd9661157f in __libc_start_main (/lib64/libc.so.6+0x2057f)
#3 0x4009a8 in _start (/home/msebor/build/tmp/a.out+0x4009a8)
SUMMARY: AddressSanitizer: stack-overflow
(/home/msebor/build/tmp/a.out+0x400be6) in factorize(int, int*)
==20465==ABORTING
or this one:
=
==20463==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7fff54492d01 at pc 0x00400be4 bp 0x7fff54492c80 sp 0x7fff54492c78
WRITE of size 4 at 0x7fff54492d01 thread T0
#0 0x400be3 in factorize(int, int*) (/home/msebor/build/tmp/a.out+0x400be3)
#1 0x400d19 in main (/home/msebor/build/tmp/a.out+0x400d19)
#2 0x7faa9866c57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
#3 0x4009a8 in _start (/home/msebor/build/tmp/a.out+0x4009a8)
Address 0x7fff54492d01 is located in stack of thread T0 at offset 1 in frame
#0 0x400c8c in main (/home/msebor/build/tmp/a.out+0x400c8c)
This frame has 1 object(s):
[32, 232) 'fact'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
(/home/msebor/build/tmp/a.out+0x400be3) in factorize(int, int*)
Shadow bytes around the buggy address:
0x10006a88a550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006a88a560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006a88a570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006a88a580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006a88a590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10006a88a5a0:[f1]f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 00
0x10006a88a5b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 f4 f4 f4
0x10006a88a5c0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
0x10006a88a5d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006a88a5e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006a88a5f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==20463==ABORTING
[Bug fortran/61627] specification expression ICE with version 4.7.1 and 4.8.2, incorrect output with 4.4.7 and 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61627 Dominique d'Humieres changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #3 from Dominique d'Humieres --- Compiling the test in comment 0 gives an ICE after revision r234636 pr61627.f90:4:0: end program internal compiler error: in output_constructor_regular_field, at varasm.c:4968
[Bug c++/70228] insufficient detail in diagnostics for a constexpr out of bounds array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70228 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed in r234698.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 70172, which changed state. Bug 70172 Summary: incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70172 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 70170, which changed state. Bug 70170 Summary: [6 regression] bogus not a constant expression error comparing pointer to array to null https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/70172] incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70172 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Sebor --- Fixed by r234698.
[Bug c++/70170] [6 regression] bogus not a constant expression error comparing pointer to array to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Sebor --- Fixed by r234698.
[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67376 --- Comment #18 from Martin Sebor --- The outstanding problems mentioned in comment #10 have been fixed in 6.0 via r234698.
[Bug c++/70170] [6 regression] bogus not a constant expression error comparing pointer to array to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170 --- Comment #12 from Martin Sebor --- Author: msebor Date: Sat Apr 2 17:14:48 2016 New Revision: 234698 URL: https://gcc.gnu.org/viewcvs?rev=234698&root=gcc&view=rev Log: PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression PR c++/70170 - [6 regression] bogus not a constant expression error comparing pointer to array to null PR c++/70172 - incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization PR c++/70228 - insufficient detail in diagnostics for a constexpr out of bounds array subscript gcc/testsuite/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 PR c++/70170 PR c++/70172 PR c++/70228 * g++.dg/cpp0x/constexpr-array-ptr10.C: New test. * g++.dg/cpp0x/constexpr-array-ptr9.C: New test. * g++.dg/cpp0x/constexpr-nullptr-1.C: New test. * g++.dg/cpp0x/constexpr-array5.C: Adjust text of expected diagnostic. * g++.dg/cpp0x/constexpr-string.C: Same. * g++.dg/cpp0x/constexpr-wstring2.C: Same. * g++.dg/cpp0x/pr65398.C: Same. * g++.dg/ext/constexpr-vla1.C: Same. * g++.dg/ext/constexpr-vla2.C: Same. * g++.dg/ext/constexpr-vla3.C: Same. * g++.dg/ubsan/pr63956.C: Same. gcc/cp/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 PR c++/70170 PR c++/70172 PR c++/70228 * constexpr.c (diag_array_subscript): New function. (cxx_eval_array_reference): Detect out of bounds array indices. gcc/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 * fold-const.c (maybe_nonzero_address): New function. (fold_comparison): Call it. Fold equality and relational expressions involving null pointers. (tree_single_nonzero_warnv_p): Call maybe_nonzero_address. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array-ptr10.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array-ptr9.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array5.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-string.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-wstring2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr65398.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla1.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla2.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla3.C trunk/gcc/testsuite/g++.dg/ubsan/pr63956.C
[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67376 --- Comment #17 from Martin Sebor --- Author: msebor Date: Sat Apr 2 17:14:48 2016 New Revision: 234698 URL: https://gcc.gnu.org/viewcvs?rev=234698&root=gcc&view=rev Log: PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression PR c++/70170 - [6 regression] bogus not a constant expression error comparing pointer to array to null PR c++/70172 - incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization PR c++/70228 - insufficient detail in diagnostics for a constexpr out of bounds array subscript gcc/testsuite/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 PR c++/70170 PR c++/70172 PR c++/70228 * g++.dg/cpp0x/constexpr-array-ptr10.C: New test. * g++.dg/cpp0x/constexpr-array-ptr9.C: New test. * g++.dg/cpp0x/constexpr-nullptr-1.C: New test. * g++.dg/cpp0x/constexpr-array5.C: Adjust text of expected diagnostic. * g++.dg/cpp0x/constexpr-string.C: Same. * g++.dg/cpp0x/constexpr-wstring2.C: Same. * g++.dg/cpp0x/pr65398.C: Same. * g++.dg/ext/constexpr-vla1.C: Same. * g++.dg/ext/constexpr-vla2.C: Same. * g++.dg/ext/constexpr-vla3.C: Same. * g++.dg/ubsan/pr63956.C: Same. gcc/cp/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 PR c++/70170 PR c++/70172 PR c++/70228 * constexpr.c (diag_array_subscript): New function. (cxx_eval_array_reference): Detect out of bounds array indices. gcc/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 * fold-const.c (maybe_nonzero_address): New function. (fold_comparison): Call it. Fold equality and relational expressions involving null pointers. (tree_single_nonzero_warnv_p): Call maybe_nonzero_address. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array-ptr10.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array-ptr9.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array5.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-string.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-wstring2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr65398.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla1.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla2.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla3.C trunk/gcc/testsuite/g++.dg/ubsan/pr63956.C
[Bug c++/70172] incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70172 --- Comment #5 from Martin Sebor --- Author: msebor Date: Sat Apr 2 17:14:48 2016 New Revision: 234698 URL: https://gcc.gnu.org/viewcvs?rev=234698&root=gcc&view=rev Log: PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression PR c++/70170 - [6 regression] bogus not a constant expression error comparing pointer to array to null PR c++/70172 - incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization PR c++/70228 - insufficient detail in diagnostics for a constexpr out of bounds array subscript gcc/testsuite/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 PR c++/70170 PR c++/70172 PR c++/70228 * g++.dg/cpp0x/constexpr-array-ptr10.C: New test. * g++.dg/cpp0x/constexpr-array-ptr9.C: New test. * g++.dg/cpp0x/constexpr-nullptr-1.C: New test. * g++.dg/cpp0x/constexpr-array5.C: Adjust text of expected diagnostic. * g++.dg/cpp0x/constexpr-string.C: Same. * g++.dg/cpp0x/constexpr-wstring2.C: Same. * g++.dg/cpp0x/pr65398.C: Same. * g++.dg/ext/constexpr-vla1.C: Same. * g++.dg/ext/constexpr-vla2.C: Same. * g++.dg/ext/constexpr-vla3.C: Same. * g++.dg/ubsan/pr63956.C: Same. gcc/cp/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 PR c++/70170 PR c++/70172 PR c++/70228 * constexpr.c (diag_array_subscript): New function. (cxx_eval_array_reference): Detect out of bounds array indices. gcc/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 * fold-const.c (maybe_nonzero_address): New function. (fold_comparison): Call it. Fold equality and relational expressions involving null pointers. (tree_single_nonzero_warnv_p): Call maybe_nonzero_address. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array-ptr10.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array-ptr9.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array5.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-string.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-wstring2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr65398.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla1.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla2.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla3.C trunk/gcc/testsuite/g++.dg/ubsan/pr63956.C
[Bug c++/70228] insufficient detail in diagnostics for a constexpr out of bounds array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70228 --- Comment #3 from Martin Sebor --- Author: msebor Date: Sat Apr 2 17:14:48 2016 New Revision: 234698 URL: https://gcc.gnu.org/viewcvs?rev=234698&root=gcc&view=rev Log: PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression PR c++/70170 - [6 regression] bogus not a constant expression error comparing pointer to array to null PR c++/70172 - incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization PR c++/70228 - insufficient detail in diagnostics for a constexpr out of bounds array subscript gcc/testsuite/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 PR c++/70170 PR c++/70172 PR c++/70228 * g++.dg/cpp0x/constexpr-array-ptr10.C: New test. * g++.dg/cpp0x/constexpr-array-ptr9.C: New test. * g++.dg/cpp0x/constexpr-nullptr-1.C: New test. * g++.dg/cpp0x/constexpr-array5.C: Adjust text of expected diagnostic. * g++.dg/cpp0x/constexpr-string.C: Same. * g++.dg/cpp0x/constexpr-wstring2.C: Same. * g++.dg/cpp0x/pr65398.C: Same. * g++.dg/ext/constexpr-vla1.C: Same. * g++.dg/ext/constexpr-vla2.C: Same. * g++.dg/ext/constexpr-vla3.C: Same. * g++.dg/ubsan/pr63956.C: Same. gcc/cp/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 PR c++/70170 PR c++/70172 PR c++/70228 * constexpr.c (diag_array_subscript): New function. (cxx_eval_array_reference): Detect out of bounds array indices. gcc/ChangeLog: 2016-04-02 Martin Sebor PR c++/67376 * fold-const.c (maybe_nonzero_address): New function. (fold_comparison): Call it. Fold equality and relational expressions involving null pointers. (tree_single_nonzero_warnv_p): Call maybe_nonzero_address. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array-ptr10.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array-ptr9.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array5.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-string.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-wstring2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr65398.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla1.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla2.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla3.C trunk/gcc/testsuite/g++.dg/ubsan/pr63956.C
Re: [BUG] Crash when demangling with libiberty
Filed here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 On 2016-03-31 15:52, Ian Lance Taylor wrote: Philippe Daouadi writes: I have been given these e-mail addresses by Nick Clifton after reporting a bug on binutils here: https://sourceware.org/bugzilla/show_bug.cgi?id=19877 . The bug is in libiberty, according to him. The bug boils down to this command (and objdump, and lldb) crashing: c++filt _ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_INSt5decayIDTclfp_defpTEEE4typeEEES7_EUlvE_EONSt16remove_referenceIS6_E4typeES7_ I'm using c++filt from binutils 2.26 and have gcc 5.3.1-8 on a debian unstable if it is of any matter. Please refile your bug report at https://gcc.gnu.org/bugzilla . If at all possible, please include the preprocessed source code that produces the symbol (you can get this by passing the --save-temps option to the compiler; we want the .ii file) and please include complete details on the compiler that produced the symbol. Thanks. Ian
[Bug other/70517] c++filt crashes when demangling a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 --- Comment #2 from blastrock at free dot fr --- Created attachment 38166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38166&action=edit preprocessed file by gcc 5.3.1
[Bug other/70517] c++filt crashes when demangling a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 --- Comment #1 from blastrock at free dot fr --- Created attachment 38165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38165&action=edit preprocessed file by clang 3.8
[Bug other/70517] New: c++filt crashes when demangling a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 Bug ID: 70517 Summary: c++filt crashes when demangling a symbol Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: blastrock at free dot fr Target Milestone: --- The following command always crashes: c++filt _ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_INSt5decayIDTclfp_defpTEEE4typeEEES7_EUlvE_EONSt16remove_referenceIS6_E4typeES7_ I have been told to report the bug here. This may be a duplicate of #67375. I am attaching the preprocessed file (by clang) that generates the symbol which triggers the bug. Compile it with: clang++ test_coroutine2.ii -c -std=c++14 with clang 3.8 (I haven't tested other versions). You can then trigger the bug with: objdump -C -t test_coroutine2.o The bug does not appear when the file is compiled with GCC. I am attaching the .ii generated by GCC too in case you need it. I am not sure, but shouldn't clang and gcc generate the same symbol names? Does this hide another bug in one of these compilers?
[Bug c++/70514] Variable length arrays lead to garbage in another array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70514 --- Comment #1 from Andrew Pinski --- This works for me on aarch64-linux-gnu with the trunk as of two days ago.
[Bug target/70464] [arch64] create a self hosting compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70464 ge...@schorsch-tech.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #15 from ge...@schorsch-tech.de --- A gentoo comunity member found the solution. It was related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164 The solution was found here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02505.html
[Bug testsuite/70516] [4.9/5/6 Regression] Regtesting acats hangs on x86_64-apple-darwin15.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70516 Dominique d'Humieres changed: What|Removed |Added Summary|[4.9/5/6 Regression]|[4.9/5/6 Regression] |Regtesting acts hangs on|Regtesting acats hangs on |x86_64-apple-darwin15.4 |x86_64-apple-darwin15.4 --- Comment #1 from Dominique d'Humieres --- Fixing the summary.
[Bug testsuite/70516] New: [4.9/5/6 Regression] Regtesting acts hangs on x86_64-apple-darwin15.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70516 Bug ID: 70516 Summary: [4.9/5/6 Regression] Regtesting acts hangs on x86_64-apple-darwin15.4 Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: charlet at gcc dot gnu.org, howarth.at.gcc.testresults at gmail dot com, iains at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin15.4 Target: x86_64-apple-darwin15.4 Build: x86_64-apple-darwin15.4 Starting after revision r234210 (OK) regtesting with acats never finish unless I kill the most recent make. I see this behavior at r234234 (Mar 16). This affects the number of acats tests that are run (see https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg00147.html and https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg00055.html). Note that after killing the make I have also to kill several expect. Tcl is 8.6.5, but using 8.5 does not help; dejagnu is 1.5.3.
[Bug c++/70515] Nested lambdas causing invalid captured pointers on some platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70515 --- Comment #1 from Norgg --- Created attachment 38164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38164&action=edit Preprocessed file
[Bug c++/70515] New: Nested lambdas causing invalid captured pointers on some platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70515 Bug ID: 70515 Summary: Nested lambdas causing invalid captured pointers on some platforms Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at norgg dot org Target Milestone: --- Created attachment 38163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38163&action=edit Minimal testcase The attached code causes a segfault at runtime due to an invalid read when trying to dereference j on some platforms but not others across multiple versions of GCC. We can replicate this on various machines with: Ubuntu g++ 5.3.1 / 5.1.1 / 4.8.4 Gentoo g++ 5.3.0 But not on: OSX g++ 5.3.0 / 6.0.0 Debian g++ 5.3.1 The command line used to compile and run was: g++ -std=c++11 lambdabug.cpp -o lambdabug && ./lambdabug
[Bug c++/70514] New: Variable length arrays lead to garbage in another array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70514 Bug ID: 70514 Summary: Variable length arrays lead to garbage in another array Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kwpolska at gmail dot com Target Milestone: --- Created attachment 38162 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38162&action=edit The broken code. I’m writing a really simple algorithm to find all prime factors of a compound integer n. factorize() needs to know primes, so it uses a variable-length array that it passes to the sort_of_sieve() function. It should also make its results easy to modify, so an array OUT[50] for results is passed. Desired output of the program: 2 2 2 2 The output of the program is random and might be one of: a) four twos b) four twos and a segfault c) four numbers that are some random stack garbage (and maybe a segfault) d) a segfault, without any output e) a floating point exception (?!) Replacing the primes VLA with bool *primes = new bool[n]; works. Compiled with (no error/warning output): $ g++ -Wall -Wextra vla-bug.cpp -o vla -save-temps This program compiles with clang++ v3.7.1. MSVC++ does not support VLAs and thus refuses to compile. Running on Arch Linux. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-5-20160209/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 5.3.0 (GCC)
[Bug libstdc++/70511] tuple constructor from elements hides copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70511
--- Comment #1 from Ivan Le Lann ---
After a quick look, I'm not sure this can be called a bug.
It looks like a very unfortunate consequence of library specification.
From the mess here
http://en.cppreference.com/w/cpp/utility/tuple/tuple
I understand that
template< class... UTypes > explicit tuple( UTypes&&... args );
is legally selected above copy construction, because it does not add "const".
Just adding "const" to original tuple declaration like this :
const std::tuple tuple_test {val};
makes GCC print intuitive output :
d
d
