[Bug middle-end/79454] [7 Regression] c-c++-common/ubsan/overflow-vec-*.c FAILs on some 64-bit BE targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79454 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Feb 11 08:15:30 2017 New Revision: 245354 URL: https://gcc.gnu.org/viewcvs?rev=245354&root=gcc&view=rev Log: PR middle-end/79454 * internal-fn.c (expand_vector_ubsan_overflow): Use piece-wise result computation whenever lhs doesn't have vector mode, not just when it has BLKmode. Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c
[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-11 CC||jakub at gcc dot gnu.org Target Milestone|--- |7.0 Summary|sh: Stack smashing detected |[7 Regression] sh: Stack |when building __ashrdi3 in |smashing detected when |libgcc |building __ashrdi3 in ||libgcc Ever confirmed|0 |1
[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 40718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40718&action=edit gcc7-pr79462.patch Untested fix. I believe the bug has been introduced in r235698 aka PR52898 fix, when the clobbers have been removed from expanders calling expand_cbranchdi4. operands[4] used to be that clobber, but now when it has only 4 operands, it overwrites random memory after it. I don't have access to SH hw nor any experience with cross-compilers to SH, so I'd appreciate if somebody could actually test it.
[Bug target/52898] SH Target: Inefficient DImode comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- (In reply to Oleg Endo from comment #11) > Author: olegendo > Date: Mon May 2 05:25:46 2016 > New Revision: 235698 > > URL: https://gcc.gnu.org/viewcvs?rev=235698&root=gcc&view=rev > Log: > gcc/ > PR target/52898 > * config/sh/sh.c (sh_option_override): Remove TARGET_CBRANCHDI4, > TARGET_CMPEQDI_T. > (prepare_cbranch_operands): Don't use scratch register. Assume that > function is used when pseudos can be created. > (expand_cbranchdi4): Likewise. Remove unused TARGET_CMPEQDI_T paths. > * config/sh/sh.md (cbranchsi4): Allow only when pseudos can be created. > (cbranchdi4, cbranchdi4_i): Simplify to single cbranchdi4 > define_expand. Allow it only when pseudos can be created. > * config/sh/sh.opt (mcbranchdi, mcmpeqdi): Delete. > > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config/sh/sh.c > trunk/gcc/config/sh/sh.md > trunk/gcc/config/sh/sh.opt This caused PR79462.
[Bug middle-end/79454] [7 Regression] c-c++-common/ubsan/overflow-vec-*.c FAILs on some 64-bit BE targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79454 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79284 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #45 from Jakub Jelinek ---
deep-stack-uaf*.C failure is presumably because the fast unwind (one that
doesn't use .eh_frame unwind info) isn't working properly.
But I'm afraid I don't know enough about s390{,x} to debug that.
E.g. on following testcase with -O2 -fno-omit-frame-pointer I get:
void foo (char *);
int
bar (char *p)
{
foo (p);
return 1;
}
int
baz (char *p)
{
char a[64];
foo (a);
return 1;
}
stmg%r11,%r15,88(%r15)
aghi%r15,-160
lgr %r11,%r15
brasl %r14,foo
lg %r4,272(%r11)
lghi%r2,1
lmg %r11,%r15,248(%r11)
br %r4
for bar and
stmg%r11,%r15,88(%r15)
aghi%r15,-224
lgr %r11,%r15
la %r2,160(%r11)
brasl %r14,foo
lg %r4,336(%r11)
lghi%r2,1
lmg %r11,%r15,312(%r11)
br %r4
for baz. Frame pointer is $r15, stack pointer is $r11, if say in foo I ask for
frame pointer, I can easily get at $r15 from the caller (foo or bar), but how
do I get from there to the location where the outer function's $r15 is stored
at? It is at offset 160+120 in one function and 224+120 in another (and the
stored memory value doesn't tell much, it can be always computed from the
memory location where it is stored.
So, is non-unwind info backtrace not possible on s390{,x}? If yes, we should
disable the fast unwinding and maybe enable -fasynchronous-unwind-tables by
default on s390{,x}-linux at least when using -fsanitize=address?
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #46 from Jakub Jelinek ---
Or shall we use -mbackchain for -fsanitize=address by default and tweak the
unwinding code sanitizer_common/sanitizer_stacktrace.{cc,h} to use the
backchain?
AFAIK libsanitizer uses the .eh_frame unwinding for printing error dumps but
the fast unwinding (through frame pointer) by default when capturing backtraces
of malloc and free. Always using .eh_frame would be done by defining
SANITIZER_CAN_FAST_UNWIND to 0 in sanitizer_common/sanitizer_stacktrace.h if
__s390__ (e.g. sparc and mips do this). Wonder if LLVM emits backchain by
default or what.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #47 from Jakub Jelinek ---
Seems clang doesn't default to -mbackchain for -fsanitize=address, they just
force it on when testing:
if config.target_arch == 's390x':
clang_asan_static_cflags.append("-mbackchain")
So, if we just want to go that route, we could add to deep-stack-uaf-1.C
// { dg-additional-options "-mbackchain" { target { s390*-*-* } } }
It is of course not very kind to users that would need to add it manually if
they want accurate backtraces for malloc/free.
[Bug c++/79463] New: ice for -g with ./g++.dg/cpp1y/pr79435.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79463
Bug ID: 79463
Summary: ice for -g with ./g++.dg/cpp1y/pr79435.C
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
I tried to compile gcc/testsuite/g++.dg/cpp1y/pr79435.C
with compiler flag -g on current gcc trunk and got:
./g++.dg/cpp1y/pr79435.C:5:10: internal compiler error: Segmentation fault
extern A a; // { dg-error "'a' has incomplete type" }
^
0xeab417 crash_signal
../../trunk/gcc/toplev.c:333
0x734b77 check_abi_tags
../../trunk/gcc/cp/class.c:1616
0x874ea3 write_mangled_name
../../trunk/gcc/cp/mangle.c:770
0x881533 mangle_decl_string
../../trunk/gcc/cp/mangle.c:3757
This code seems ok on gcc revision 245132 and seems
to go wrong on gcc revision 245341.
[Bug c++/79464] New: new ice in ipa_modify_formal_ parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79464 Bug ID: 79464 Summary: new ice in ipa_modify_formal_ parameters Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I tried to compile gcc/testsuite/g++.dg/cpp1z/inh-ctor23.C with flag -O2 and recent gcc and it said this: ./g++.dg/cpp1z/inh-ctor23.C:10:7: internal compiler error: in ipa_modify_formal_parameters, at ipa-prop.c:3979 Z z(0); // OK: initialization of Y does not invoke default constructor of X ^ 0xc7c97b ipa_modify_formal_parameters(tree_node*, vec) ../../trunk/gcc/ipa-prop.c:3979 0xfa6f19 modify_function ../../trunk/gcc/tree-sra.c:5179 0xfb1acd ipa_early_sra ../../trunk/gcc/tree-sra.c:5410 0xfb1acd execute ../../trunk/gcc/tree-sra.c:5457 This bug seems to have appeared between gcc revision 245132 and 245341.
[Bug target/71017] libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71017 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dominique d'Humieres --- It should be fixed now. Closing.
[Bug middle-end/61225] [5/6/7 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 --- Comment #27 from Dominique d'Humieres --- AFAICT this PR seems fixed. Can I close it?
[Bug sanitizer/78267] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #58 from Dominique d'Humieres --- > > --- Comment #56 from Jakub Jelinek --- > > So, is this resolved now? > > The bootstrap failures are AFAIK, but perhaps we should keep it open for > the fixinclude fix backports discovered? Any need to keep this PR open?
[Bug middle-end/61225] [5/6/7 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 --- Comment #28 from Jakub Jelinek --- Don't we still XFAIL the gcc.target/i386/pr49095.c test?
[Bug tree-optimization/79460] gcc fails to optimise out a trivial additive loop for seemingly arbitrary numbers of iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-11 CC||segher at gcc dot gnu.org Ever confirmed|0 |1
[Bug preprocessor/79465] New: infinite #include cycle is not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79465 Bug ID: 79465 Summary: infinite #include cycle is not detected Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: valsiterb at gmail dot com Target Milestone: --- I was working on a 20 years old codebase and in order to increase compilation speed, I've converted all header guards to #ifdef ... #error to go on and change things around, but there was a cycle somewhere in the headers (a.h includes b.h but b.h also includes a.h) cpp does not detect this case and goes on unil it gets killed. I don't know if cycle detection is even supposed to part of the preprocessor, but I expected that #error would make it stop there. I know that there is -Wfatal-errors directive. Shouldn't #error be be fatal or am I missing something?
[Bug middle-end/61225] [5/6/7 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 --- Comment #29 from Jeffrey A. Law --- Right. I think the test is xfailed, but I don't think the issue has been resolved. It requires some rethinking of how the combiner works IIRC.
[Bug c++/79466] New: strange varargs warnings on superflous paranthesises
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79466 Bug ID: 79466 Summary: strange varargs warnings on superflous paranthesises Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Target Milestone: --- Created attachment 40719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40719&action=edit Simple example triggering the warning When compiled with g++ -std=gnu++14 the expression __builtin_va_start ((ap), (fmt)); triggers a strange warning: example.cc:4:37: warning: second parameter of 'va_start' not last named argument [-Wvarargs] __builtin_va_start ((ap), (fmt)); ^ Removing the extra paranthesis makes it work. This does not happen with -std=gnu++11. Sample attached, compile with: g++ -Wall -O2 -std=gnu++14 -c -o example.o example.cc (warning and optimization settings do not make a difference, only std= is important)
[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 --- Comment #7 from Jan Hubicka --- Author: hubicka Date: Sat Feb 11 16:11:57 2017 New Revision: 245357 URL: https://gcc.gnu.org/viewcvs?rev=245357&root=gcc&view=rev Log: PR ipa/79224 * ipa-inline-analysis.c (get_minimal_bb): New function. (record_modified): Use it. (remap_edge_change_prob): Handle also ancestor functions. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-analysis.c
[Bug middle-end/61225] [5/6/7 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 --- Comment #30 from Segher Boessenkool --- Trying to combine the load+add+store, combine is trying insns like Failed to match this instruction: (parallel [ (set (mem:SI (reg/v/f:SI 90 [ x ]) [1 *x_5(D)+0 S4 A32]) (plus:SI (mem:SI (reg/v/f:SI 90 [ x ]) [1 *x_5(D)+0 S4 A32]) (const_int -1 [0x]))) (set (reg:SI 88 [ _2 ]) (plus:SI (mem:SI (reg/v/f:SI 90 [ x ]) [1 *x_5(D)+0 S4 A32]) (const_int -1 [0x]))) ]) and it does not know how to split that into two (make the second SET just a load). If it could do that -- and costs work out for the target -- all would work fine as far as I see. Alternatively, the target could use a define_split for this pattern.
[Bug c++/77659] [5/6/7 Regression] internal compiler error: in gimplify_expr, at gimplify.c:8858
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77659 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/77790] [5/6/7 Regression] ICE on valid C++14 code when compiling with "-std=c++11": in push_access_scope, at cp/pt.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77790 --- Comment #6 from Jason Merrill --- Author: jason Date: Sat Feb 11 17:29:45 2017 New Revision: 245358 URL: https://gcc.gnu.org/viewcvs?rev=245358&root=gcc&view=rev Log: PR c++/77790 - ICE with auto function in C++11 mode * decl.c (undeduced_auto_decl): Remove C++14 limitation. (require_deduced_type): Add complain parm, return bool. * cp-tree.h: Adjust. * decl2.c (mark_used): Use require_deduced_type. Added: trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn35.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/testsuite/g++.dg/cpp0x/auto41.C
[Bug c++/77790] [5/6 Regression] ICE on valid C++14 code when compiling with "-std=c++11": in push_access_scope, at cp/pt.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77790 Jakub Jelinek changed: What|Removed |Added Priority|P2 |P4 Summary|[5/6/7 Regression] ICE on |[5/6 Regression] ICE on |valid C++14 code when |valid C++14 code when |compiling with |compiling with |"-std=c++11": in|"-std=c++11": in |push_access_scope, at |push_access_scope, at |cp/pt.c:227 |cp/pt.c:227 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727 --- Comment #15 from Jan Hubicka --- Author: hubicka Date: Sat Feb 11 17:56:02 2017 New Revision: 245359 URL: https://gcc.gnu.org/viewcvs?rev=245359&root=gcc&view=rev Log: PR tree-ssa/56727 * gcc.dg/tree-ssa/pr56727.c: New testcase. * ipa-utils.c (recursive_call_p): Be more careful about interposition. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr56727.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-utils.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #48 from Ulrich Weigand --- s390(x) has -fasynchronous-unwind-tables on by default anyway, and .eh_frame based DWARF unwinding is the only way to create stack backtraces that always works. However, I understood that asan deliberately doesn't want to use DWARF unwinding for the the malloc/free case since it can be slow. That's why Marcin actually added -mbackchain to LLVM in the first place. (We've had -mbackchain in GCC forever, but it has defaulted to off for a very long time.) I don't think we should switch to *always* using backchain unwinding in asan, since system libraries on s390 will be built without backchain. However, switching -mbackchain on by default when building for asan might make sense.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #49 from Jakub Jelinek --- On the other side, we don't turn -fno-omit-frame-pointer or -mno-omit-leaf-frame-pointer for -fsanitize=address on other targets either, perhaps this is just a documentation issue. I'll add -mbackchain to this testcase. Perhaps we should just mention those flags in -fsanitize=address documentation in invoke.texi.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #50 from Jakub Jelinek --- Author: jakub Date: Sat Feb 11 18:38:11 2017 New Revision: 245361 URL: https://gcc.gnu.org/viewcvs?rev=245361&root=gcc&view=rev Log: PR sanitizer/79341 * g++.dg/asan/deep-stack-uaf-1.C: New test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C
[Bug c++/79466] strange varargs warnings on superflous paranthesises
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79466 --- Comment #1 from Andrew Pinski --- C++14 changed the rules slightly about paranthesises which is why you are seeing the difference here.
[Bug libstdc++/79467] New: [7 Regression] incorrect static assertion in shared_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79467
Bug ID: 79467
Summary: [7 Regression] incorrect static assertion in
shared_ptr
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct X { };
struct D {
void operator()(X*&) {}
};
std::shared_ptr p(new X(), D());
Fails on trunk with:
/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr_base.h:1088:4: error:
static assertion failed: deleter expression d(p) is well-formed
static_assert(__is_callable<_Deleter(_Yp*)>::value,
The __is_callable expression should be using lvalues not rvalues.
[Bug libstdc++/79467] [7 Regression] incorrect static assertion in shared_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79467 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-11 Known to work||6.3.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.0.1
[Bug web/79468] New: Clarify createaccount.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79468 Bug ID: 79468 Summary: Clarify createaccount.cgi Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Hello, with the spam situation, bugzilla account creation currently consists in sending an email to overseers. However, createaccount.cgi does not reflect this, it says to fill in a one-field web form and only contact overseers if that doesn't work for some unspecified amount of time (sounds like contacting webmaster to report a bug, not like contacting an admin to create the account). I very regularly see people on stackoverflow give up on reporting bugs because of this.
[Bug web/79468] Clarify createaccount.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79468 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-11 CC||LpSolit at netscape dot net Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Also, it says: "User account creation has been restricted. Contact your administrator or the maintainer (overse...@gcc.gnu.org) for information about creating an account." This also confuses people, who wonder "who is my administrator"? Their local sysadmins can't help, so it's a confusing statement. It should just tell them to contact overseers.
[Bug libstdc++/79467] [7 Regression] incorrect static assertion in shared_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79467 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Sat Feb 11 21:08:11 2017 New Revision: 245363 URL: https://gcc.gnu.org/viewcvs?rev=245363&root=gcc&view=rev Log: PR libstdc++/79467 use lvalues in is_callable check PR libstdc++/79467 * include/bits/shared_ptr_base.h (__shared_ptr(_Yp*, _Deleter)) (__shared_ptr(_Yp*, _Deleter, _Alloc)): Use lvalue types in __is_callable check. * testsuite/20_util/shared_ptr/cons/79467.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/79467.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/shared_ptr_base.h
[Bug libstdc++/79467] [7 Regression] incorrect static assertion in shared_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79467 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #2 from Jonathan Wakely --- Fixed
[Bug c/79471] New: valgrind error for gcc.c-torture/compile/limits-fnargs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79471 Bug ID: 79471 Summary: valgrind error for gcc.c-torture/compile/limits-fnargs.c Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I just built a valgrind version of gcc trunk and tried out the gcc testsuite on it. For testcase gcc.c-torture/compile/limits-fnargs.c, I got ./gcc.c-torture/compile/limits-fnargs.c ==21687== Invalid write of size 8 ==21687==at 0x6F33B9: expand_call(tree_node*, rtx_def*, int) (calls.c:3266) ==21687==by 0x7DFF36: expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) (expr.c:10785) ==21687==by 0x703E54: expand_expr (expr.h:276) ==21687==by 0x703E54: expand_call_stmt (cfgexpand.c:2658) Admittedly an extreme case, but I think gcc shouldn't be doing invalid writes.
[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 --- Comment #8 from Jan Hubicka --- Author: hubicka Date: Sat Feb 11 21:49:51 2017 New Revision: 245366 URL: https://gcc.gnu.org/viewcvs?rev=245366&root=gcc&view=rev Log: PR ipa/79224 * params.def (inline-min-speedup) Change from 10 to 8. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def
[Bug testsuite/79427] g++.dg/tls/thread_local-order2.C fails starting with r245249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-11 CC||danglin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from John David Anglin --- Also fails on hppa*-*-hpux*.
[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 Kazumoto Kojima changed: What|Removed |Added CC||kkojima at gcc dot gnu.org --- Comment #3 from Kazumoto Kojima --- I've tested the patch with the top "make -k check" on sh4-unknown-linux-gnu and there are no regressions.
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 --- Comment #8 from gnzlbg --- Eric your concerns and suggestions make sense. Changing the signature of the functions using something like __ctfe__ and probably anything that would use those sounds like a major ABI breaking change though. I do not think we can find a better solution though, but it makes me reconsider whether we really need this. We do need something like this, but i don't know at what cost.
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 --- Comment #9 from Eric Fiselier --- I think it would be nice to be able to dispatch differently depending on being called at compile time or runtime. However the ability to dispatch on that condition doesn't have to be usable in "if constexpr". That way we don't run into any instantiation problems. If that behavior is desireable enough I think it could be simply implemented as an invented __ctfe__ function local variable that changes value.
[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 --- Comment #4 from Oleg Endo --- If the patch fixes the problem, it's OK. But please add a comment where the line is removed as a hint of what's going on there.
[Bug tree-optimization/79472] New: x86-64: Switch table generation fails if default case has different code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79472
Bug ID: 79472
Summary: x86-64: Switch table generation fails if default case
has different code
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yuriks at yuriks dot net
Target Milestone: ---
Consider the following code, compiled at -O2: (Compiler explorer link:
https://godbolt.org/g/GljuJt)
#include
#include
#include
void frobulate(uint32_t v) {
const char* s;
switch (v) {
case 0:
s = "foo";
break;
case 1:
s = "bar";
break;
case 2:
s = "spam";
break;
default:
abort();
break;
}
printf("%s\n", s);
}
void frobulate_for_gcc(uint32_t v) {
const char* s;
switch (v) {
case 0:
s = "foo";
break;
case 1:
s = "bar";
break;
case 2:
s = "spam";
break;
default:
s = nullptr;
break;
}
if (s == nullptr) {
abort();
}
printf("%s\n", s);
}
--
gcc 6.3 produces the following code. It fails to generate a data table in
"frobulate", even though it it doing a branch beforehand that could be used to
insert the abort into. If I add the indirection of checking for the null
pointer instead then the check is actually hoisted up into the range check for
the table:
frobulate(unsigned int):
cmp edi, 1
je .L3
jb .L4
cmp edi, 2
jne .L12
mov edi, OFFSET FLAT:.LC2
jmp puts
.L12:
sub rsp, 8
callabort
.L4:
mov edi, OFFSET FLAT:.LC0
jmp puts
.L3:
mov edi, OFFSET FLAT:.LC1
jmp puts
frobulate_for_gcc(unsigned int):
cmp edi, 2
jbe .L18
.L14:
sub rsp, 8
callabort
.L18:
mov edi, edi
mov rdi, QWORD PTR CSWTCH.2[0+rdi*8]
testrdi, rdi
je .L14
jmp puts
CSWTCH.2:
.quad .LC0
.quad .LC1
.quad .LC2
--
gcc 7 (20170211) appears to regress further, it fails to generate a table in
both cases:
frobulate(unsigned int):
cmp edi, 1
je .L3
jb .L4
cmp edi, 2
jne .L12
mov edi, OFFSET FLAT:.LC2
jmp puts
.L4:
mov edi, OFFSET FLAT:.LC0
jmp puts
.L3:
mov edi, OFFSET FLAT:.LC1
jmp puts
.L12:
sub rsp, 8
callabort
--
For comparison, clang 3.9.1 generates optimal code in both instances:
frobulate(unsigned int): # @frobulate(unsigned int)
cmp edi, 3
jae .LBB0_1
movsxd rax, edi
mov rdi, qword ptr [8*rax + .Lswitch.table.4]
jmp puts# TAILCALL
.LBB0_1:
pushrax
callabort
frobulate_for_gcc(unsigned int): # @frobulate_for_gcc(unsigned
int)
cmp edi, 3
jae .LBB1_1
movsxd rax, edi
mov rdi, qword ptr [8*rax + .Lswitch.table.4]
jmp puts# TAILCALL
.LBB1_1:
pushrax
callabort
[Bug c++/77659] [5/6/7 Regression] internal compiler error: in gimplify_expr, at gimplify.c:8858
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77659 --- Comment #6 from Jason Merrill --- Author: jason Date: Sun Feb 12 03:31:02 2017 New Revision: 245372 URL: https://gcc.gnu.org/viewcvs?rev=245372&root=gcc&view=rev Log: PR c++/77659 - ICE with new and C++14 aggregate NSDMI * init.c (build_new): Make backups of any CONSTRUCTORs in init. (build_new_1): Use replace_placeholders. * tree.c (replace_placeholders_t): Also track whether we've seen a placeholder. (replace_placeholders, replace_placeholders_r): Adjust. * cp-tree.h: Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/cp/tree.c
[Bug c++/78908] [6/7 Regression] template instantiation with bit-field type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78908 --- Comment #8 from Jason Merrill --- Author: jason Date: Sun Feb 12 03:34:11 2017 New Revision: 245373 URL: https://gcc.gnu.org/viewcvs?rev=245373&root=gcc&view=rev Log: PR c++/78908 - template ops and bitfields * tree.c (build_min_non_dep): Use unlowered_expr_type. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/template/bitfield3.C Modified: branches/gcc-6-branch/gcc/cp/ChangeLog branches/gcc-6-branch/gcc/cp/tree.c
[Bug c++/77659] [5/6 Regression] internal compiler error: in gimplify_expr, at gimplify.c:8858
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77659 Jason Merrill changed: What|Removed |Added Summary|[5/6/7 Regression] internal |[5/6 Regression] internal |compiler error: in |compiler error: in |gimplify_expr, at |gimplify_expr, at |gimplify.c:8858 |gimplify.c:8858 --- Comment #7 from Jason Merrill --- Fixed for GCC 7 so far.
[Bug c++/78908] [6/7 Regression] template instantiation with bit-field type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78908 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jason Merrill --- Fixed.
[Bug c++/36566] Cannot bind packed field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
--- Comment #9 from Marc Glisse ---
I was thinking that
struct __attribute__((packed)) A { int i; };
should be handled like
typedef int int_unaligned __attribute__((aligned(1)));
struct A { int_unaligned i; };
but it appears that for the aligned attribute as well we ignore the attribute
when forming pointers or references. Depending on the uses, the compiler can
print things like "int_unaligned* {aka int*}" or "ignoring attributes on
template argument" etc. It seems to me that we should not drop the
alignment-reducing attribute in those cases (it is still fine to remove it when
deducing a pass-by-copy type, as in templatevoid f(T);int_unaligned i;
f(i); which could safely deduce T=int. Return types may be more tricky when
they end up passed as invisible reference). The C/C++ standard only consider
_Alignas/alignas to increase alignment, so I don't think changes to the case
that decreases alignment would be a conformance issue.
