[Bug middle-end/64463] New: Add warning: returns_nonnull attribute on a function compared against NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64463
Bug ID: 64463
Summary: Add warning: returns_nonnull attribute on a function
compared against NULL
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rur...@x-ray.at
feature request:
Working on gcc.gnu.org/bugzilla/show_bug.cgi?id=64459 I find it difficult to
find all occurrences of wrong returns_nonnull attributes.
We get those errors, which are fine:
error: returns_nonnull attribute on a function not returning a pointer
But I'm missing the diagnosis of nonnull return values when they are being
wrongly used.
Such as:
__attribute__((returns_nonnull))
char *myfunc() { ...}
if (!myfunc()) {
... /* optimized away */
}
I would like to see a warning when a returns_nonnull function is compared
against a NULL value, and then actual code is removed or skipped based on that
attribute. Which is either a difficult to diagnose declaration error, or a
logical error in the usage.
warning: returns_nonnull attribute on a function compared against NULL
Complete your MBA/E-MBA in one year with Online Exams !!!!! Apply now
Get MBA, E-MBA , MMS, DMS, PGDBM ,DBM etc done without disturbing your job... Any Certificate NO Donation / Percentage Barrier International Attestations by Ministry of External Affairs and Foreign Affairs (Charges apply*) GIVE US AN OPPORTUNITY TO MAKE YOUR CAREER: Please reply to this mail providing following details to obtain detail information about our Institute, Course, Exams etc. Name: Contact No.: Email id : Course of Interest: Specialization: Query: Qualifications Work Experience : Address Details: When you're ready to make the time, my help is just a phone call or e-mail away. With your success in mind, For ISMS Indian School of Management Studies, Nirali ISMS Email :- nir...@ismsedu.net Website :- www.ismsedu.com
[Bug c++/59354] Unexpected result in g++ when casting int to char from an stl vector to an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354
Eelis gcc-bugzilla at contacts dot eelis.net changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
||.net
--- Comment #1 from Eelis gcc-bugzilla at contacts dot eelis.net ---
This is not specific to std::vector and not specific to C++.
C testcase:
#include stdio.h
#include stdint.h
int main()
{
uint32_t a[256] = {};
uint8_t b[1000] = {};
for(int i = 0; i != 256; ++i)
a[i] = i % 5;
for (int z = 0 ; z 16; z++)
for (int y = 0 ; y 4; y++)
for (int x = 0 ; x 4; x++)
b[y * 64 + z*4 + x] = a[z * 16 + y * 4 + x];
printf(%d\n, b[4]);
return 0;
}
Prints '4' without -mno-sse, prints '1' with -mno-sse.
[Bug fortran/64426] Unnecessary string temporary for array assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64426 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-01 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed. Note that the line if (c(3) .ne. '23yz') call abort should be replaced with if (c(3) .ne. '34yz') call abort I am also refraining to mark the PR as a [5 Regression]: with the above change the code passes the test with 4.9.2.
[Bug c++/64455] A constexpr variable template can't be used with enable_if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64455
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Btw, this problem prevents using the C++14 trait aliases with the forthcoming
trait variable templates as they were intended, because
template class T enable_if_tis_same_vT, int f() {}
is also erroneously rejected with the diagnostic that is_same_vT, int
is not usable in a constant expression.
[Bug c++/64382] ICE due to use of `this` inside a lambda that captures everything by ref inside a member function of a class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64382 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-01 Ever confirmed|0 |1 --- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com --- Clang accepts the code.
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-01 CC||redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (Fumble-fingered the committer-add to the CC list.)
[Bug c++/64466] A generic lambda in a class template causes an ICE in gimplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64466 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com --- Dup. *** This bug has been marked as a duplicate of bug 64382 ***
[Bug c++/64382] ICE due to use of `this` inside a lambda that captures everything by ref inside a member function of a class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64382 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com --- *** Bug 64466 has been marked as a duplicate of this bug. ***
[Bug c/64459] __attribute__((returns_nonnull)) creates wrong code on amd64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64459 --- Comment #4 from Reini Urban rur...@x-ray.at --- maybe the script is of value to anyone: https://gist.github.com/rurban/b8b951d03ff22734f05b
[Bug target/63949] Aarch64 instruction combiner does not optimize subsi_sxth function as expected (gcc.target/aarch64/extend.c fails)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949 --- Comment #6 from vekumar at gcc dot gnu.org --- In the function make_compound_operation, there a check /* See if we have operations between an ASHIFTRT and an ASHIFT. If so, try to merge the shifts into a SIGN_EXTEND. We could also do this for some cases of SIGN_EXTRACT, but it doesn't seem worth the effort; the case checked for occurs on Alpha. */ if (!OBJECT_P (lhs) ! (GET_CODE (lhs) == SUBREG (OBJECT_P (SUBREG_REG (lhs CONST_INT_P (rhs) INTVAL (rhs) HOST_BITS_PER_WIDE_INT INTVAL (rhs) mode_width (new_rtx = extract_left_shift (lhs, INTVAL (rhs))) != 0) new_rtx = make_extraction (mode, make_compound_operation (new_rtx, next_code), 0, NULL_RTX, mode_width - INTVAL (rhs), code == LSHIFTRT, 0, in_code == COMPARE); break; Our input RTL actually matches this case. For (int)i 1 we are getting incomming RTX as (ashiftrt:SI (ashift:SI (reg:SI 1 x1 [ i ]) (const_int 16 [0x10])) (const_int 15 [0xf])) LHS is ashift:SI (reg:SI 1 x1 [ i ]) (const_int 16 [0x10]) RHS is ashiftrt with a value of 15. So bacially we get (i16)15, we can merge these shifts to sign_extends. With extract_left_shift we get (ashift:SI (reg:SI 1 x1 [ i ]) (const_int 1 [0x1])) or x11 When we do make_extraction with this shift pattern we get (ashift:SI (sign_extend:SI (reg:HI 1 x1 [ i ])) (const_int 1 [0x1]))) But instead this we are the shift RTX, we are actually passing MULT RTX to make_extraction via another make_compound_operation. p make_compound_operation(new_rtx,MEM) $3 = (rtx_def *) 0x777fd420 (gdb) pr (mult:SI (reg:SI 1 x1 [ i ]) (const_int 2 [0x2])) Which results in (subreg:SI (sign_extract:DI (mult:DI (reg:DI 1 x1 [ i ]) (const_int 2 [0x2])) (const_int 17 [0x11]) (const_int 0 [0])) 0) When I changed the original check to --- a/gcc/combine.c +++ b/gcc/combine.c @@ -7896,7 +7896,7 @@ make_compound_operation (rtx x, enum rtx_code in_code) INTVAL (rhs) HOST_BITS_PER_WIDE_INT INTVAL (rhs) mode_width (new_rtx = extract_left_shift (lhs, INTVAL (rhs))) != 0) - new_rtx = make_extraction (mode, make_compound_operation (new_rtx, next_ + new_rtx = make_extraction (mode, new_rtx, 0, NULL_RTX, mode_width - INTVAL (rhs), code == LSHIFTRT, 0, in_code == COMPARE) Combiner was able to match the pattern successfully. Trying 8 - 13: Successfully matched this instruction: (set (reg/i:SI 0 x0) (minus:SI (reg:SI 0 x0 [ a ]) (ashift:SI (sign_extend:SI (reg:HI 1 x1 [ i ])) (const_int 1 [0x1] (minus:SI (reg:SI 0 x0 [ a ]) (ashift:SI (sign_extend:SI (reg:HI 1 x1 [ i ])) Any comments about this change? (const_int 1 [0x1])))
[Bug c++/64466] New: A generic lambda in a class template causes an ICE in gimplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64466
Bug ID: 64466
Summary: A generic lambda in a class template causes an ICE in
gimplify
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com
templatetypename T struct my_queue {
void push(T){ }
void ice(){ trav([](auto v){ push(v); }); }
templatetypename F void trav(F f){ f(T()); }
};
template class my_queueint;
Clang accepts the code. gcc ICEs:
lhmouse2.cpp: In lambda function:
lhmouse2.cpp:3:41: internal compiler error: Segmentation fault
void ice(){ trav([](auto v){ push(v); }); }
^
0xca552f crash_signal
../../gcc/toplev.c:358
0xa009f8 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:2892
0xa009f8 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/fold-const.c:1735
0xabfa04 gimplify_compound_lval
../../gcc/gimplify.c:2012
0xab7619 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7686
0xac19af gimplify_call_expr
../../gcc/gimplify.c:2449
0xab790f gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7705
0xabbe16 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5473
0xab80ee gimplify_cleanup_point_expr
../../gcc/gimplify.c:5249
0xab80ee gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:8097
0xabbe16 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5473
0xabccb5 gimplify_bind_expr
../../gcc/gimplify.c:1110
0xab78ed gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7931
0xabbe16 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5473
0xabd775 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:8843
0xabdd76 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:8996
0x903397 cgraph_node::analyze()
../../gcc/cgraphunit.c:613
0x905c57 analyze_functions
../../gcc/cgraphunit.c:1001
0x906855 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2351
0x6e3a8b cp_write_global_declarations()
../../gcc/cp/decl2.c:4742
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug ada/60078] acats c761007 fails on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #14 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Well, that happened only once. and the problem did never ever repeat. But my gut feeling is still that there is a race conditition. However I have been recently working on TSAN a bit, and I have an experimental tsan version that I played with. Initially it ICE'd on Ada's VIEW_CONVERT_EXPRs, but when I fixed that I got: gnatmake -g -fsanitize=thread c761007 ./c761007 ,.,. C761007 ACATS 2.5 15-01-01 15:29:05 C761007 Check that if a finalize procedure invoked by a transfer of control or selection of a terminate alternative attempts to propagate an exception, the exception is ignored, but any other finalizations due to be performed are performed. == WARNING: ThreadSanitizer: data race (pid=27044) Read of size 4 at 0x00657764 by thread T5: #0 c761007_1__finalize /home/ed/gnu/gcc-test/c761007_1.adb:10 (c761007+0x0040c749) #1 c761007_1__containerDF null (c761007+0x0040bc3b) #2 c761007_2__prot_w_fin_objVDF null (c761007+0x00404364) #3 c761007__subtest_3__check_atc_operation___finalizer.5515 null (c761007+0x0040efd2) #4 c761007__subtest_3__check_atc_operation.5508 null (c761007+0x0040f1ec) #5 c761007__subtest_3__subtest_3_taskTKB.5506 null (c761007+0x0040f5de) #6 system__tasking__stages__task_wrapper /home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x00418800) Previous write of size 4 at 0x00657764 by thread T6: #0 c761007_1__finalize /home/ed/gnu/gcc-test/c761007_1.adb:17 (c761007+0x0040c859) #1 c761007_1__containerDF null (c761007+0x0040bc3b) #2 c761007_2__prot_w_fin_objVDF null (c761007+0x00404364) #3 c761007__subtest_3__subtest_3_taskTK__nestingTK___finalizer.5573 null (c761007+0x0040f854) #4 c761007__subtest_3__subtest_3_taskTK__nestingTKB.5565 null (c761007+0x0040fa2a) #5 system__tasking__stages__task_wrapper /home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x00418800) Location is global 'c761007_1__side_effect_finger' of size 4 at 0x00657764 (c761007+0x00657764) Thread T5 'subtest_3_task' (tid=27050, running) created by main thread at: #0 pthread_create ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:895 (libtsan.so.0+0x000272f4) #1 system__task_primitives__operations__create_task /home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:1016 (c761007+0x00411d72) #2 _ada_c761007 /home/ed/gnu/gcc-test/c761007.adb:228 (c761007+0x0040d551) #3 main /home/ed/gnu/gcc-test/b~c761007.adb:331 (c761007+0x004042e4) Thread T6 'nesting' (tid=27051, running) created by thread T5 at: #0 pthread_create ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:895 (libtsan.so.0+0x000272f4) #1 system__task_primitives__operations__create_task /home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:1016 (c761007+0x00411d72) #2 system__tasking__stages__task_wrapper /home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x00418800) SUMMARY: ThreadSanitizer: data race /home/ed/gnu/gcc-test/c761007_1.adb:10 c761007_1__finalize == == WARNING: ThreadSanitizer: data race (pid=27044) Read of size 1 at 0x0065a343 by thread T5: #0 c761007_1__finalize /home/ed/gnu/gcc-test/c761007_1.adb:12 (c761007+0x0040c7d4) #1 c761007_1__containerDF null (c761007+0x0040bc3b) #2 c761007_2__prot_w_fin_objVDF null (c761007+0x00404364) #3 c761007__subtest_3__check_atc_operation___finalizer.5515 null (c761007+0x0040efd2) #4 c761007__subtest_3__check_atc_operation.5508 null (c761007+0x0040f1ec) #5 c761007__subtest_3__subtest_3_taskTKB.5506 null (c761007+0x0040f5de) #6 system__tasking__stages__task_wrapper /home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x00418800) Previous write of size 1 at 0x0065a343 by thread T6: #0 c761007_1__finalize /home/ed/gnu/gcc-test/c761007_1.adb:18 (c761007+0x0040c902) #1 c761007_1__containerDF null (c761007+0x0040bc3b) #2 c761007_2__prot_w_fin_objVDF null (c761007+0x00404364) #3 c761007__subtest_3__subtest_3_taskTK__nestingTK___finalizer.5573 null (c761007+0x0040f854) #4 c761007__subtest_3__subtest_3_taskTK__nestingTKB.5565 null (c761007+0x0040fa2a) #5 system__tasking__stages__task_wrapper /home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x00418800) Location is global 'c761007_1__side_effect' of size 80 at 0x0065a340 (c761007+0x0065a343) Thread T5 'subtest_3_task' (tid=27050, running) created by main thread at: #0 pthread_create ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:895 (libtsan.so.0+0x000272f4) #1 system__task_primitives__operations__create_task
[Bug libstdc++/64467] New: [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467
Bug ID: 64467
Summary: [5 Regression] 28_regex/traits/char/isctype.cc and
wchar_t/isctype.cc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
Host: x86_64-linux
Target: cris-elf
These tests used to pass for cris-elf, but has feiled since a commit in the
range (217057:217069] (I'm behind on regression-bug-reporting):
Running
/tmp/hpautotest-gcc0/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
[...]
FAIL: 28_regex/traits/char/isctype.cc execution test
FAIL: 28_regex/traits/wchar_t/isctype.cc execution test
In libstdc++.log (compile-line only quoted for completeness):
Executing on host: /tmp/hpautotest-gcc0/cris-elf/gccobj/./gcc/xg++
-shared-libgcc -B/tmp/hpautotest-gcc0/cris-elf/gccobj/./gcc -nostdinc++
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/src
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/src/.libs
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/libsupc++/.libs
-nostdinc -B/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/newlib/ -isystem
/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem
/tmp/hpautotest-gcc0/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libgloss/cris
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libgloss/libnosys
-L/tmp/hpautotest-gcc0/gcc/libgloss/cris
-B/tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/bin/
-B/tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/lib/ -isystem
/tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/include -isystem
/tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/sys-include
-B/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./libgloss/cris/
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./libgloss/cris
-L/tmp/hpautotest-gcc0/gcc/libgloss/cris
-B/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-DLOCALEDIR=. -nostdinc++
-I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf
-I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include
-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/libsupc++
-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/include/backward
-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/testsuite/util
/tmp/hpautotest-gcc0/gcc/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc
-std=gnu++11 ./libtestc++.a-isystem
/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpautotest-gcc0/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./libgloss/cris/
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./libgloss/cris
-L/tmp/hpautotest-gcc0/gcc/libgloss/cris
-B/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./newlib/
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./newlib -sim3 -lm -o
./isctype.exe(timeout = 600)
PASS: 28_regex/traits/char/isctype.cc (test for excess errors)
assertion !t.isctype('\n', t.lookup_classname(blank,
blank+sizeof(blank)/sizeof(blank[0])-1)) failed: file
/tmp/hpautotest-gcc0/gcc/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc,
line 56, function: void test01()
program stopped with signal 6 (Aborted).
FAIL: 28_regex/traits/char/isctype.cc execution test
and also:
PASS: 28_regex/traits/wchar_t/isctype.cc (test for excess errors)
assertion !t.isctype(L'\n', t.lookup_classname(blank,
blank+sizeof(blank)/sizeof(blank[0])-1)) failed: file
/tmp/hpautotest-gcc0/gcc/libstdc++-v3/testsuite/28_regex/traits/wchar_t/isctype.cc,
line 53, function: void test01()
program stopped with signal 6 (Aborted).
FAIL: 28_regex/traits/wchar_t/isctype.cc execution test
(same fail message still at r219089).
Committer of libstdc++ changes in the indicated revision range CC:ed.
Unexpectedly, I don't see this for other non-linux and/or newlib targets with
libstdc++ results posted to gcc-testresults@. There was also a commit to
gcc/ifcvt.c in this range, I'll triage the revision range to exclude that.
[Bug middle-end/64464] New: Optimization for reusing values in loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64464 Bug ID: 64464 Summary: Optimization for reusing values in loops Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org This is against gcc version 5.0.0 20141222 (experimental) (GCC), on x86_64-unknown-linux-gnu. Consider the following two program snippets: ig25@linux-fd1f:~/Krempel/Mandelbrot/Bug cat m1.f90 module foo implicit none integer, parameter :: prec = selected_real_kind(15) integer, parameter :: n_iter = 1 contains integer function iter_p(cx, cy) real(kind=prec), value :: cx, cy real(kind=prec) :: x, y, xn, yn integer :: k x = cx y = cy do k=1, n_iter xn = x*x - y*y + cx yn = 2*x*y + cy if (xn*xn + yn*yn 4._prec) exit x = xn y = yn end do iter_p = k end function iter_p end module foo ig25@linux-fd1f:~/Krempel/Mandelbrot/Bug cat m2.f90 module foo implicit none integer, parameter :: prec = selected_real_kind(15) integer, parameter :: n_iter = 1 contains integer function iter_p(cx, cy) real(kind=prec), value :: cx, cy real(kind=prec) :: x, y, xn, yn, x2, y2 integer :: k x = cx y = cy x2 = x*x y2 = y*y do k=1, n_iter xn = x2 - y2 + cx yn = 2*x*y + cy x2 = xn * xn y2 = yn * yn if (x2 + y2 4._prec) exit x = xn y = yn end do iter_p = k end function iter_p end module foo With -O3, the tight loop for m1.f90 is translated into .L6: addl$1, %eax movapd %xmm2, %xmm3 cmpl$10001, %eax je .L2 .L3: movapd %xmm3, %xmm2 mulsd %xmm3, %xmm2 addsd %xmm3, %xmm3 mulsd %xmm4, %xmm3 subsd %xmm5, %xmm2 movapd %xmm3, %xmm4 addsd %xmm0, %xmm2 addsd %xmm1, %xmm4 movapd %xmm2, %xmm3 movapd %xmm4, %xmm5 mulsd %xmm2, %xmm3 mulsd %xmm4, %xmm5 addsd %xmm5, %xmm3 ucomisd %xmm6, %xmm3 jbe .L6 and for m2.f90 into .L6: addl$1, %eax movapd %xmm5, %xmm4 cmpl$10001, %eax je .L2 .L3: subsd %xmm6, %xmm3 addsd %xmm4, %xmm4 movapd %xmm3, %xmm5 mulsd %xmm4, %xmm2 addsd %xmm0, %xmm5 addsd %xmm1, %xmm2 movapd %xmm5, %xmm3 mulsd %xmm5, %xmm3 movapd %xmm2, %xmm6 mulsd %xmm2, %xmm6 movapd %xmm3, %xmm4 addsd %xmm6, %xmm4 ucomisd %xmm7, %xmm4 jbe .L6 For m1.f90, this is 5 moves, 5 adds, 1 sub and 4 muls. For m2.f80, this is 5 moves, 5 adds, 1 sub and 3 muls. I would expect the same number of operations for m2.f90 as for m1.f90. Same result for 4.8, so this is (very probably) not a regression.
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-01-01
CC||hubicka at ucw dot cz
Target Milestone|--- |5.0
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com ---
It is caused by r219108. The updated testcase:
[hjl@gnu-mic-2 gcc-regression]$ cat pr64465.c
typedef void (*__sighandler_t) (int);
struct sigaction
{
__sighandler_t sa_handler;
};
extern int sigaction (const struct sigaction *__restrict __act);
extern int __open_alias (const char *__path, int __oflag, ...) __asm__ (
open)
;
static __inline
__attribute__ ((__always_inline__))
int
open (const char *__path, int __oflag, ...)
{
if (__builtin_constant_p (__oflag))
return __open_alias (__path, __oflag, __builtin_va_arg_pack ());
return __open_alias (__path, __oflag, __builtin_va_arg_pack ());
}
extern int close(int fd);
static void
set_fortify_handler (void (*handler) (int sig))
{
struct sigaction sa;
sigaction (sa);
int fd = open (/dev/null, 3);
if (fd == -1)
close (1);
}
extern void handler (int sig);
void
do_test (void)
{
set_fortify_handler (handler);
}
[hjl@gnu-mic-2 gcc-regression]$
/export/project/git/gcc-regression/master/219108/usr/bin/gcc -O2 -S
-fexceptions pr64465.c
pr64465.c: In function \u2018set_fortify_handler\u2019:
pr64465.c:34:1: error: BB 5 last statement has incorrectly set lp
}
^
pr64465.c:34:1: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[hjl@gnu-mic-2 gcc-regression]$
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- I get different ICE as attached. it is previously semi-latent bug exposed by different inlining decisions. /aux/hubicka/t.c: In function �do_test�: /aux/hubicka/t.c:25:7: internal compiler error: in gimple_op_ptr, at gimple.h:2276 int fd = open (/dev/null, 3); ^ 0xdc53bf gimple_op_ptr ../../gcc/gimple.h:2276 0xdc5dc6 gimple_call_arg_ptr ../../gcc/gimple.h:2858 0xdcf898 copy_bb ../../gcc/tree-inline.c:1889 0xdd2416 copy_cfg_body ../../gcc/tree-inline.c:2710 0xdd2f22 copy_body ../../gcc/tree-inline.c:2947 0xdd72e6 expand_call_inline ../../gcc/tree-inline.c:4616 0xdd7a08 gimple_expand_calls_inline ../../gcc/tree-inline.c:4752 0xdd7fff optimize_inline_calls(tree_node*) ../../gcc/tree-inline.c:4893 0x16ace2c inline_transform(cgraph_node*) ../../gcc/ipa-inline-transform.c:507 0xc45c50 execute_one_ipa_transform_pass ../../gcc/passes.c:2176 0xc45db9 execute_all_ipa_transforms() ../../gcc/passes.c:2217 0x86c8d6 cgraph_node::expand() ../../gcc/cgraphunit.c:1791 0x86cf43 expand_all_functions ../../gcc/cgraphunit.c:1934 0x86da7c symbol_table::compile() ../../gcc/cgraphunit.c:2284 0x86dc2d symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2361 0x6c751d c_write_global_declarations() ../../gcc/c/c-decl.c:10778
[Bug web/64468] New: Incorrect indentation in Doxygen-generated sources of libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64468 Bug ID: 64468 Summary: Incorrect indentation in Doxygen-generated sources of libstdc++ Product: gcc Version: 5.0 URL: https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxyge n/a00971_source.html Status: UNCONFIRMED Severity: trivial Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: maltsevm at gmail dot com See the attached URL. The indentation is broken (it is best visible near line 150 and further). The URL is given as an example, the problem affects other sources and versions (at least, 4.9.2 and 4.6.4 are affected; previous versions don't include libstd++ docs). Probably the reason is incorrect configuration of Doxygen: libstdc++ sources use tab size equal to 8 spaces, and in libstdc++-v3/doc/doxygen/user.cfg.in this value is set to be equal to 4: TAB_SIZE = 4 Some parts of the library are indented using only spaces, without tabs.
[Bug web/64469] New: Broken link on main page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64469 Bug ID: 64469 Summary: Broken link on main page Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: schnetter at gmail dot com The link to https://gcc.gnu.org/gcc-5/ on the main page gcc.gnu.org is broken. It leads to the error message You don't have permission to access /gcc-5/ on this server..
[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #11 from Mikhail Maltsev maltsevm at gmail dot com --- Proposing a new patch: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html
[Bug c++/61135] It seems to be not able to call virtual method of literal object in lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61135 --- Comment #4 from Dinar Temirbulatov dtemirbulatov at gmail dot com --- I could not reproduce the error, the output looks correct on trunk
[Bug target/59551] ICE when compiling ImageMagick on hppa/linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59551 Aaro Koskinen aaro.koskinen at iki dot fi changed: What|Removed |Added Known to work||4.9.2 --- Comment #3 from Aaro Koskinen aaro.koskinen at iki dot fi --- No longer reproducible with GCC 4.9.2.
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug target/64180] PowerPC carry bit improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64180 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Segher Boessenkool segher at gcc dot gnu.org --- All done.
[Bug middle-end/64465] New: [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465
Bug ID: 64465
Summary: [5 Regression] internal compiler error:
verify_flow_info failed
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
On Linux/x86-64, r219127 gave:
[hjl@gnu-tools-1 tmp]$ cat foo.c
typedef void (*__sighandler_t) (int);
struct sigaction
{
__sighandler_t sa_handler;
};
extern int sigaction (const struct sigaction *__restrict __act);
extern int __open_alias (const char *__path, int __oflag, ...) __asm__ (
open)
;
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__artificial__)) int
open (const char *__path, int __oflag, ...)
{
if (__builtin_constant_p (__oflag))
return __open_alias (__path, __oflag, __builtin_va_arg_pack ());
return __open_alias (__path, __oflag, __builtin_va_arg_pack ());
}
extern int close(int fd);
static void
set_fortify_handler (void (*handler) (int sig))
{
struct sigaction sa;
sigaction (sa);
int fd = open (/dev/null, 3);
if (fd == -1)
close (1);
}
extern void handler (int sig);
void
do_test (void)
{
set_fortify_handler (handler);
}
[hjl@gnu-tools-1 tmp]$
/export/build/gnu/gcc-x32/release/usr/gcc-5.0.0-x32/bin/gcc -O2 foo.c -O2
-Wall -fexceptions
foo.c: In function ‘set_fortify_handler’:
foo.c:31:1: error: BB 5 last statement has incorrectly set lp
}
^
foo.c:31:1: internal compiler error: verify_flow_info failed
0x71e49b verify_flow_info()
/export/gnu/import/git/gcc/gcc/cfghooks.c:271
0xb33b39 cleanup_tree_cfg_noloop
/export/gnu/import/git/gcc/gcc/tree-cfgcleanup.c:753
0xb33b39 cleanup_tree_cfg()
/export/gnu/import/git/gcc/gcc/tree-cfgcleanup.c:802
0xa32b14 execute_function_todo
/export/gnu/import/git/gcc/gcc/passes.c:1893
0xa33603 execute_todo
/export/gnu/import/git/gcc/gcc/passes.c:1997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
