[Bug c/68378] Return value optimization does not fire iff in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68378 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from H.J. Lu --- This is related to PR 28831.
[Bug c/68378] New: Return value optimization does not fire iff in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68378
Bug ID: 68378
Summary: Return value optimization does not fire iff in C mode
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eyal.lotem at gmail dot com
Target Milestone: ---
struct Foo { int x[1000]; };
struct Foo f(void);
struct Foo g(void) {
struct Foo x = f();
return x;
}
When built with -O3 -xc this generates superfluous inefficient copying.
When built with -O3 -xc++ this generates an efficient call without copying.
Copying should not be generated here.
[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43996 --- Comment #18 from Steve Kargl --- On Tue, Nov 17, 2015 at 04:04:11AM +, kargl at gcc dot gnu.org wrote: > --- Comment #17 from kargl at gcc dot gnu.org --- > I have a patch testing as I type. > I had to fine tune the patch, but it regression tests cleanly.
[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66059 Daniel Frey changed: What|Removed |Added CC||d.frey at gmx dot de --- Comment #3 from Daniel Frey --- A better O(log N) library-only solution than the linked one is available at https://github.com/taocpp/sequences/blob/master/include/tao/seq/make_integer_sequence.hpp Jonathan, we already exchanged some mails a few weeks ago about std::tuple improvements. The above implementation can be used if the compiler-intrinsic still needs time to materialize, the rest should be independently implementable. If you are interested, let me know how to proceed.
[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43996 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #17 from kargl at gcc dot gnu.org --- I have a patch testing as I type.
[Bug target/53587] [manual] Option -mms-bitfields not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53587 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #1 from sandra at gcc dot gnu.org --- There is actually a fairly detailed description of what this option does in conjunction with the corresponding variable attributes in extend.texi. I'll hack up a patch to add some cross-references.
[Bug other/56036] Wrong indentation in multiple -O options explaination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56036 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from sandra at gcc dot gnu.org --- I've applied the suggested patch and confirmed it fixes the problem.
[Bug other/56036] Wrong indentation in multiple -O options explaination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56036 --- Comment #2 from sandra at gcc dot gnu.org --- Author: sandra Date: Tue Nov 17 01:56:17 2015 New Revision: 230452 URL: https://gcc.gnu.org/viewcvs?rev=230452&root=gcc&view=rev Log: 2015-11-16 Thomas Preud'homme PR 56036 * doc/invoke.texi (Optimize Options): Move @end table to the right place. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug c++/68377] New: [c++1z] "binary expression in operand of fold-expression" error when folding an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68377
Bug ID: 68377
Summary: [c++1z] "binary expression in operand of
fold-expression" error when folding an expression
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.burn at gmail dot com
Target Milestone: ---
The following code gives the error "binary expression in operand of
fold-expression"
#include
template
int f(Tx... xs) {
return ((sizeof(Tx) == sizeof(int)) && ...);
}
int main() {
std::cout << f(3,4,5) << "\n";
return 0;
}
It works fine with clang (http://melpon.org/wandbox/permlink/cqH0ENHFHNGLbkZW)
[Bug other/65129] gcc manual index entry of __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65129 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- Fixed on trunk.
[Bug other/65129] gcc manual index entry of __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65129 --- Comment #1 from sandra at gcc dot gnu.org --- Author: sandra Date: Tue Nov 17 01:19:59 2015 New Revision: 230451 URL: https://gcc.gnu.org/viewcvs?rev=230451&root=gcc&view=rev Log: 2015-11-16 Sandra Loosemore PR 65129 * doc/extend.texi (__builtin_assume_aligned): Fix formatting of return value. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #44 from H.J. Lu --- *** Bug 68355 has been marked as a duplicate of this bug. ***
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239 Bug 67239 depends on bug 68355, which changed state. Bug 68355 Summary: C++ constexpr is passed on stack https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68355 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug target/68355] C++ constexpr is passed on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68355 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 60336 ***
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |5.3 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch.
[Bug fortran/58027] "Arithmetic overflow converting ..." in PARAMETER triggers an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58027 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |5.3 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk and 5.3 branch.
[Bug fortran/58027] "Arithmetic overflow converting ..." in PARAMETER triggers an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58027 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Nov 17 00:07:55 2015 New Revision: 230445 URL: https://gcc.gnu.org/viewcvs?rev=230445&root=gcc&view=rev Log: 2015-11-16 Steven G. Kargl PR fortran/58027 PR fortran/60993 * expr.c (gfc_check_init_expr): Prevent a redundant check when a __convert_* function was inserted into an array constructor. (gfc_check_assign_symbol): Check for an initialization expression when a __convert_* was inserted. 2015-11-16 Steven G. Kargl PR fortran/58027 PR fortran/60993 * gfortran.dg/pr58027.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr58027.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Nov 17 00:07:55 2015 New Revision: 230445 URL: https://gcc.gnu.org/viewcvs?rev=230445&root=gcc&view=rev Log: 2015-11-16 Steven G. Kargl PR fortran/58027 PR fortran/60993 * expr.c (gfc_check_init_expr): Prevent a redundant check when a __convert_* function was inserted into an array constructor. (gfc_check_assign_symbol): Check for an initialization expression when a __convert_* was inserted. 2015-11-16 Steven G. Kargl PR fortran/58027 PR fortran/60993 * gfortran.dg/pr58027.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr58027.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 H.J. Lu changed: What|Removed |Added Attachment #36723|0 |1 is obsolete|| Attachment #36724|0 |1 is obsolete|| --- Comment #43 from H.J. Lu --- Created attachment 36730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36730&action=edit A patch to support LTO I am testing this patch.
[Bug libstdc++/67440] pretty-printing of a const set fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440 Doug Evans changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Doug Evans --- Patch committed to trunk and gcc-5-branch.
[Bug libstdc++/67440] pretty-printing of a const set fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440 --- Comment #4 from devans at gcc dot gnu.org --- Author: devans Date: Mon Nov 16 23:46:56 2015 New Revision: 230444 URL: https://gcc.gnu.org/viewcvs?rev=230444&root=gcc&view=rev Log: Backport from mainline: PR libstdc++/67440 * python/libstdcxx/v6/printers.py (find_type): Handle "const" in type name. * testsuite/libstdc++-prettyprinters/debug.cc: Add test for const set. * testsuite/libstdc++-prettyprinters/simple.cc: Ditto. * testsuite/libstdc++-prettyprinters/simple11.cc: Ditto. Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/python/libstdcxx/v6/printers.py branches/gcc-5-branch/libstdc++-v3/testsuite/libstdc++-prettyprinters/debug.cc branches/gcc-5-branch/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc branches/gcc-5-branch/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple11.cc
[Bug driver/65482] -mno-allow-movmisalign undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65482 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #1 from sandra at gcc dot gnu.org --- I see several options in config/rs6000/rs6000.opt that have the "Undocumented" attribute. I think we need a target maintainer to review this and decide which (if any) of these should be exposed to users, or perhaps consider removing them if they are not useful. The reference to -mno-allow-movmisalign in the testsuite is now in testsuite/lib/target-supports.exp, BTW.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #42 from H.J. Lu --- (In reply to H.J. Lu from comment #29) > (In reply to Andrew Pinski from comment #27) > > Comment on attachment 36720 [details] > > A patch > > > > How does this interact with LTO where lang_hooks.decls.empty_record_p is not > > defined? > > We can stream out empty record info and use it to in lto_empty_record_p. There are 7 bits we can use for LTO: /* These flags are available for each language front end to use internally. */ #define TYPE_LANG_FLAG_0(NODE) (TYPE_CHECK (NODE)->type_common.lang_flag_0) #define TYPE_LANG_FLAG_1(NODE) (TYPE_CHECK (NODE)->type_common.lang_flag_1) #define TYPE_LANG_FLAG_2(NODE) (TYPE_CHECK (NODE)->type_common.lang_flag_2) #define TYPE_LANG_FLAG_3(NODE) (TYPE_CHECK (NODE)->type_common.lang_flag_3) #define TYPE_LANG_FLAG_4(NODE) (TYPE_CHECK (NODE)->type_common.lang_flag_4) #define TYPE_LANG_FLAG_5(NODE) (TYPE_CHECK (NODE)->type_common.lang_flag_5) #define TYPE_LANG_FLAG_6(NODE) (TYPE_CHECK (NODE)->type_common.lang_flag_6)
[Bug other/61124] GCC manual has 68HC11/68HC12 info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61124 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from sandra at gcc dot gnu.org --- This was fixed by r221614: 2015-03-23 Sandra Loosemore gcc/ * doc/extend.texi (Function Attributes): Add @cindex entries for all attributes and regularize their format. Delete text about long-obsolete 68HC11 and 68HC12 targets. Move misplaced information about "eightbit_data", "tiny_data", and "model" variable attributes to the Variable Attributes section. Fix some obvious typos and copy-editing issues. (Variable Attributes, Type Attributes): Likewise add/fix @cindex entries for all attributes.
[Bug libstdc++/67440] pretty-printing of a const set fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440 --- Comment #3 from devans at gcc dot gnu.org --- Author: devans Date: Mon Nov 16 21:32:26 2015 New Revision: 230437 URL: https://gcc.gnu.org/viewcvs?rev=230437&root=gcc&view=rev Log: PR libstdc++/67440 * python/libstdcxx/v6/printers.py (find_type): Handle "const" in type name. * testsuite/libstdc++-prettyprinters/debug.cc: Add test for const set. * testsuite/libstdc++-prettyprinters/simple.cc: Ditto. * testsuite/libstdc++-prettyprinters/simple11.cc: Ditto. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/debug.cc trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple11.cc
[Bug c++/68362] [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Should be fixed now.
[Bug c++/68362] [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Mon Nov 16 20:16:57 2015 New Revision: 230435 URL: https://gcc.gnu.org/viewcvs?rev=230435&root=gcc&view=rev Log: PR c++/68362 * c-common.c (check_case_bounds): Fold low and high cases. * g++.dg/delayedfold/switch-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/delayedfold/switch-1.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED CC||msebor at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #9 from Martin Sebor --- Working on a patch.
[Bug rtl-optimization/68376] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68376 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-16 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.4 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started between r152040 and r152438.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #47 from Alexander Cherepanov --- On 2015-11-16 14:00, rguenther at suse dot de wrote: >> --- Comment #43 from Jeehoon Kang --- >> - Performance degradation due to "casted pointers as escaped" is >> insignificant. > > I think this is not true. For example with MatLab (might be sth else, > if I don't remember correctly) you are required to pass pointers to > arrays in two halves in double(!) values (I believe the only function > argument type they support). GCC happily makes points-to analysis work > through those. But this is invalid C. First, it breaks strict aliasing rules. Second, the representations of these doubles are free to change at any time given their values are kept intact (e.g. change one NaN to another). That is, unrelated improvements in other optimizations in gcc will break all of this in the future, right? > I also don't think doing the above would solve the cases of equality > compares of pointes themselves. (hopefully undefined) Hm, undefining comparisons between a pointer pointing past the end of an object and a pointer to another object could be a way forward. You propose to undefine it for any objects (similar to "<") or only when they are not parts (including recursively) of the same aggregate? In any case this will fix some theoretical problems, e.g. transitivity of == as described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502#c17 . OTOH, again in any case, it will not solve all problems. For instance, if you want to track bounds of arrays in runtime you still can get equal pointers with different additional info -- pointers to an object and a subobject. Granted, this is kinda hypothetical (IIUC UBSAN works a bit different right now). > I added the current handling of pointers vs. integers for a > missed-optimization bug that said a hand-written memcpy loop > didn't properly transfer points-to info (properly as in > optimially for optimization). GCC can now do that ;) Nice! Does gcc properly transfer effective type info too, over a hand-written memcpy loop? Just curious. On 2015-11-16 15:51, rguenther at suse dot de wrote: >> Thank you for giving me the information. I don't know the GCC internals, so I >> would like to ask how much it would cost to introduce the syntax for pointer >> subtractions. I hope it is not that huge, but I really don't have any idea. > > It would be quite some (mechanical) work but otherwise not too difficult. > There is the choice whether to embed the division implicitely here or > not. If you choose to fix it please fix pr45779 on the way (see pr67999 for a context).
[Bug rtl-optimization/68376] New: wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68376
Bug ID: 68376
Summary: wrong code at -O1 and above on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk mis-compiles the following code on x86_64-linux-gnu at
-O1 and above in both 32-bit and 64-bit modes.
It also seems to affect all earlier GCC releases since as early as 4.6.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151115 (experimental) [trunk revision 230395] (GCC)
$
$ gcc-trunk -O0 small.c; ./a.out
$
$ gcc-trunk -O1 small.c; ./a.out
Aborted (core dumped)
$ gcc-4.6 -O1 small.c; ./a.out
Aborted (core dumped)
$
int a, b, c = 1;
char d;
int
main ( )
{
for ( ; a < 1; a++ )
for ( ; b < 1; b++ )
{
char e = ~d;
if ( d < 1 )
e = d;
d = e;
if ( !c )
__builtin_abort ();
}
if ( d != 0 )
__builtin_abort ();
return 0;
}
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Nov 16 19:15:25 2015 New Revision: 230433 URL: https://gcc.gnu.org/viewcvs?rev=230433&root=gcc&view=rev Log: 2015-11-16 Steven G. Kargl PR fortran/58027 PR fortran/60993 * expr.c (gfc_check_init_expr): Prevent a redundant check when a __convert_* function was inserted into an array constructor. (gfc_check_assign_symbol): Check for an initialization expression when a __convert_* was inserted. 2015-11-16 Steven G. Kargl PR fortran/58027 PR fortran/60993 * gfortran.dg/pr58027.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr58027.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/58027] "Arithmetic overflow converting ..." in PARAMETER triggers an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58027 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Nov 16 19:15:25 2015 New Revision: 230433 URL: https://gcc.gnu.org/viewcvs?rev=230433&root=gcc&view=rev Log: 2015-11-16 Steven G. Kargl PR fortran/58027 PR fortran/60993 * expr.c (gfc_check_init_expr): Prevent a redundant check when a __convert_* function was inserted into an array constructor. (gfc_check_assign_symbol): Check for an initialization expression when a __convert_* was inserted. 2015-11-16 Steven G. Kargl PR fortran/58027 PR fortran/60993 * gfortran.dg/pr58027.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr58027.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 --- Comment #4 from joseph at codesourcery dot com --- On Mon, 16 Nov 2015, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 > > --- Comment #3 from Dominique d'Humieres --- > > Darwin defaults to -fno-math-errno, and tests for libm functions setting > > errno should be disabled there. > > Does this mean that the test should be skipped on darwin? Yes, or at least what's testing errno in it (which looks like pretty much the whole test). Or, better, add an effective-target keyword for math-errno support and restrict the test based on that (and convert any present skips of math-errno tests for Darwin to use the new effective-target keyword) - it's not the only system without math-errno support in its libm.
[Bug jit/68370] Pointer arithmetic in libgccjit seems to require an extra cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68370 --- Comment #3 from Roger Ferrer Ibanez --- Created attachment 36729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36729&action=edit Small reproducer
[Bug c++/68362] [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug middle-end/68375] New: [6 Regression] ICE in get_loop_body_in_bfs_order when dumping cfg with -fdump-tree-optimized-graph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68375
Bug ID: 68375
Summary: [6 Regression] ICE in get_loop_body_in_bfs_order when
dumping cfg with -fdump-tree-optimized-graph
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
I was investigating the testcase from PR 68194
int printf (const char *, ...);
int a, c, d, e, g, h;
short f;
short
fn1 ()
{
int j[2];
for (; e; e++)
if (j[0])
for (;;)
;
if (!g)
return f;
}
int
main ()
{
for (; a < 1; a++)
{
for (c = 0; c < 2; c++)
{
d && (f = 0);
h = fn1 ();
}
printf ("%d\n", (char) f);
}
return 0;
}
and hit an ICe when compiling with -fdump-tree-optimized-graph -O2:
internal compiler error: in get_loop_body_in_bfs_order, at cfgloop.c:944
fn1 ()
^~~
0x7114e8 get_loop_body_in_bfs_order(loop const*)
../../gcc/gcc/cfgloop.c:944
0x1166ce2 draw_cfg_nodes_for_loop
../../gcc/gcc/graph.c:220
0x1166cad draw_cfg_nodes_for_loop
../../gcc/gcc/graph.c:212
0x1166e64 draw_cfg_nodes
../../gcc/gcc/graph.c:242
0x1166e64 print_graph_cfg(char const*, function*)
../../gcc/gcc/graph.c:288
0xa17806 execute_function_dump
../../gcc/gcc/passes.c:1751
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
The assert "gcc_assert (i > vc);" triggers.
Changing it to "gcc_assert (i >= vc);" fixes it for me but it was explicitly
changed to i > vc from i >= vc with:
2015-06-09 Richard Biener
* cfgloop.c (get_loop_body_in_bfs_order): Fix assert.
so there must be something I'm missing?
[Bug c++/68374] New: G++ -Wshadow doesn't warn about static member shadowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68374
Bug ID: 68374
Summary: G++ -Wshadow doesn't warn about static member
shadowing
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xyzdragon at fastmail dot fm
Target Milestone: ---
This bug seems to be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45615 but the code example is a
bit different, so I'm not sure. Delete this if necessary.
This is the source code in question:
class f {
static int mVar;
int g(int x) { int mVar=3; return x+mVar; }
};
int f::mVar = 1;
The problem is, that I accidentally added int in front of mVar. When I compile
this with:
g++ -c -Wall -Wextra -Wshadow shadowtest.cpp
I don't get any warning, about the local mVar shadowing the static member mVar.
But if I don't declare the member variable to be static, then g++ correctly
issues a warning:
class f {
int mVar;
f(int rVar) : mVar(rVar) {};
int g(int x) { int mVar=3; return x+mVar; }
};
compile with g++ -c -Wall -Wextra -Wshadow shadowtest2.cpp gets:
shadowtest2.cpp:5:24: warning: declaration of ‘mVar’ shadows a member of ‘f’
[-Wshadow]
int g(int x) { int mVar=3; return x+mVar; }
^
shadowtest2.cpp:3:9: note: shadowed declaration is here
int mVar;
^
Note, as pointed out by other stack users
http://stackoverflow.com/questions/33739066/ and also tested myself clang++
behaves like I would have expected g++ to behave, that's why I'm filing this as
a bug.
The above behavior is the same in g++ 4.9.2 and g++ 5.2.1-17
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 --- Comment #3 from Dominique d'Humieres --- > Darwin defaults to -fno-math-errno, and tests for libm functions setting > errno should be disabled there. Does this mean that the test should be skipped on darwin?
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 --- Comment #2 from joseph at codesourcery dot com --- Darwin defaults to -fno-math-errno, and tests for libm functions setting errno should be disabled there.
[Bug c/68371] complex number will be initialized a NAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68371 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Marek Polacek --- Per above.
[Bug c/68371] complex number will be initialized a NAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68371 --- Comment #1 from joseph at codesourcery dot com --- Not a bug. GCC does not support imaginary types. Use __builtin_complex (GCC 4.7 or later) or the CMPLX macros implemented based on it, or assign to __real__ and __imag__ of a temporary.
[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66059 --- Comment #2 from rhalbersma --- Apparently VC and Clang have compiler hooks for this: https://www.reddit.com/r/cpp/comments/3t0nrc/true_story_efficient_packing_tales_of_c/cx26s02
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from cbaylis at gcc dot gnu.org --- Closed as this is now fixed on trunk and in gcc-5-branch
[Bug tree-optimization/68373] New: autopar fails on loop exit phi with argument defined outside loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68373
Bug ID: 68373
Summary: autopar fails on loop exit phi with argument defined
outside loop
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
First consider a parloops testcase test.c, with a use of the final value of the
iteration variable (return i):
...
unsigned int
foo (int *a, int n)
{
int i;
for (i = 0; i < n; ++i)
a[i] = 1;
return i;
}
...
Say we compile the testcase like this:
...
$ gcc -S -O2 test.c -ftree-parallelize-loops=2 -fdump-tree-all-details
...
We find in the parloops dump-file:
...
SUCCESS: may be parallelized
...
The autoparallelization is possible because -ftree-scev-cprop substitutes the
final iteration variable value, which eliminates the only loop exit phi:
...
final value replacement:
i_1 = PHI
with
i_1 = n_4(D);
...
Now consider a similar testcase test-2.c, but with loop counter and bound
unsigned:
...
unsigned int
foo (int *a, unsigned int n)
{
unsigned int i;
for (i = 0; i < n; ++i)
a[i] = 1;
return i;
}
...
Also here, we have -ftree-scev-cprop eliminating the only loop exit phi:
...
i_2 = PHI
with
i_2 = n_4(D);
...
But, in a subsequent pass_copy_prop, we manage to propagate i_2 (that didn't
happen in test.c because of signedness differences), eliminate the empty bb,
effectively reintroducing a new loop exit phi:
...
:
# i_12 = PHI <0(3), i_10(5)>
_5 = (long unsigned int) i_12;
_6 = _5 * 4;
_8 = a_7(D) + _6;
*_8 = 1;
i_10 = i_12 + 1;
if (n_4(D) > i_10)
goto ;
else
goto ;
:
goto ;
:
# i_14 = PHI
...
And in parloops during
gather_scalar_reductions/vect_analyze_loop_form/vect_analyze_loop_form_1 we
split the loop exit edge, which results in this exit phi:
...
:
# i_12 = PHI <0(3), i_10(5)>
_5 = (long unsigned int) i_12;
_6 = _5 * 4;
_8 = a_7(D) + _6;
*_8 = 1;
i_10 = i_12 + 1;
if (n_4(D) > i_10)
goto ;
else
goto ;
:
goto ;
:
# n_2 = PHI
...
And then parloops stumbles over that phi:
...
phi is n_2 = PHI
arg of phi to exit: value n_4(D) used outside loop
checking if it a part of reduction pattern:
FAILED: it is not a part of reduction.
...
In split_loop_exit_edge we preserve loop-closed ssa, which is why it introduces
phis. But we should be able to optimize
n_2 = PHI
into
n_2 = n_4(D)
without breaking loop-closed ssa form.
Alternatively, we could improve parloops to allow phis like this and handle
them.
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 --- Comment #22 from ktkachov at gcc dot gnu.org --- So in an attempt to make some progress on this, I've tried Jim's approach of changing PROMOTE_MODE to not convert the short modes to unsigned. Building SPEC2006 INT and looking at the generated assembly actually doesn't look too bad, with the codesize being a tiny bit smaller overall with this patch. Many load operations followed by extend are expressed as single ldrsh instructions. Then there's the ldrh+smullbb vs ldrsh+mla issue. I'm looking at the wmul-1.c testcase. The cse1 pass is the one that eliminates the sign-extends from the arms of the plus-mult. Before cse1 we have: (insn 41 40 43 3 (set (reg:SI 136 [ _12 ]) (sign_extend:SI (mem:HI (reg:SI 135 (insn 44 43 47 3 (set (reg:SI 138 [ _16 ]) (sign_extend:SI (mem:HI (reg:SI 144 (insn 47 44 49 3 (set (reg/v:SI 141 [ dotp ]) (plus:SI (mult:SI (sign_extend:SI (subreg/s/u:HI (reg:SI 136 [ _12 ]) 0)) (sign_extend:SI (subreg/s/u:HI (reg:SI 138 [ _16 ]) 0))) (reg/v:SI 141 [ dotp ] (insn 49 47 51 3 (set (reg/v:SI 153 [ sqr ]) (plus:SI (mult:SI (sign_extend:SI (subreg/s/u:HI (reg:SI 136 [ _12 ]) 0)) (sign_extend:SI (subreg/s/u:HI (reg:SI 136 [ _12 ]) 0))) (reg/v:SI 153 [ sqr ] and cse1 transforms this into: (insn 41 40 43 3 (set (reg:SI 136 [ _12 ]) (sign_extend:SI (mem:HI (reg:SI 135 [ ivtmp.10 ]) (insn 44 43 47 3 (set (reg:SI 138 [ _16 ]) (sign_extend:SI (mem:HI (reg:SI 144 [ ivtmp.13 ]) (insn 47 44 49 3 (set (reg/v:SI 141 [ dotp ]) (plus:SI (mult:SI (reg:SI 136 [ _12 ]) (reg:SI 138 [ _16 ])) (reg/v:SI 141 [ dotp ] (insn 49 47 51 3 (set (reg/v:SI 153 [ sqr ]) (plus:SI (mult:SI (reg:SI 136 [ _12 ]) (reg:SI 136 [ _12 ])) (reg/v:SI 153 [ sqr ] Notice how the extends on the loads remain but the extends from the plus-mult have disappeared. Before Jim's patch the same sequence is: (insn 41 40 43 3 (set (reg:SI 136 [ _12 ]) (zero_extend:SI (mem:HI (reg:SI 135 [ ivtmp.10 ]) (insn 44 43 47 3 (set (reg:SI 138 [ _16 ]) (zero_extend:SI (mem:HI (reg:SI 144 [ ivtmp.13 ]) (insn 47 44 49 3 (set (reg/v:SI 141 [ dotp ]) (plus:SI (mult:SI (sign_extend:SI (subreg/s/v:HI (reg:SI 136 [ _12 ]) 0)) (sign_extend:SI (subreg/s/v:HI (reg:SI 138 [ _16 ]) 0))) (reg/v:SI 141 [ dotp ] (insn 49 47 51 3 (set (reg/v:SI 153 [ sqr ]) (plus:SI (mult:SI (sign_extend:SI (subreg/s/v:HI (reg:SI 136 [ _12 ]) 0)) (sign_extend:SI (subreg/s/v:HI (reg:SI 136 [ _12 ]) 0))) (reg/v:SI 153 [ sqr ] So the sign-extends inside the plus-mult don't match the zero_extends from the loads, so it can't cse the sign-extends away. If the SImode mult-accumulate is indeed more expensive than extend-mult-accumulate on some cores, then cse and costs should have gated that transformation? Worth looking into IMO. If we fix these widening-mult-accumulate issues will Jim's arm backend patch be a valid patch correctness-wise?
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #32 from Gary Funck --- (In reply to Gary Funck from comment #17) > We're seeing this ICE on x86-64, while building the 32-bit libgfortran. > We're building the target libraries with -O3 with GCC compiler checks > enabled. The recent r230424 commit did *not* fix this regression. Note that we're building with CFLAGS_FOR_TARGET='-O3 -g'.
[Bug rtl-optimization/68330] [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl on alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68330 --- Comment #4 from Segher Boessenkool --- Author: segher Date: Mon Nov 16 15:51:33 2015 New Revision: 230429 URL: https://gcc.gnu.org/viewcvs?rev=230429&root=gcc&view=rev Log: simplify-rtx: Simplify sign_extend of lshiftrt to zero_extend (PR68330) Since r230164, in PR68330 combine ends up with a sign_extend of an lshiftrt by some constant, and it does not know to morph that into a zero_extract (the extend will always extend with zeroes). I think it is best to let simplify-rtx always replace such a sign_extend by a zero_extend, after which everything works as expected. 2015-11-15 Segher Boessenkool PR rtl-optimization/68330 * simplify-rtx.c (simplify_unary_operation_1): Simplify SIGN_EXTEND of LSHIFTRT by a non-zero constant integer. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 --- Comment #7 from Christophe Lyon --- (In reply to rguent...@suse.de from comment #6) > On Mon, 16 Nov 2015, clyon at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 > > > > --- Comment #5 from Christophe Lyon --- > > (In reply to Richard Biener from comment #3) > > > (In reply to Christophe Lyon from comment #2) > > > > (In reply to Richard Biener from comment #1) > > > > > Ok, so I assume this is after the fix for PR68306. > > > > > > > > Indeed: that was fixed at r230310, at which point my build still > > > > succeded. > > > > > > > > It started to fail at r230311. > > > > > > Hmm, in a tree with the fix for PR68306 I can't reproduce with a cross. > > > > > > Can you double-check please? > > > > I've just reproduced it again with an extract at r230402. > > > > Please make sure you use target armeb-none-linux-gnueabihf, not > > arm-none-linux-gnueabihf as Martin used. It works for > > arm-none-linux-gnueabihf, > > but not for armeb-none-linux-gnueabihf (big-endian) > > r230428? Build completed now, thanks!
[Bug tree-optimization/67326] [5/6 Regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326 --- Comment #4 from rguenther at suse dot de --- On Mon, 16 Nov 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #3 from Jakub Jelinek --- > Yeah, we could perhaps look at the other DRs and figure out that because v3[i] > has the same index as v2[i] or v1[i], those are accessed unconditionally and > v3 > has at least as many elements as v1 or v2, v3[i] will not trap if v2[i] will > not. That all to avoid relying on SCEV and niter analysis? Ok, I can see that it might catch some more cases that way.
[Bug tree-optimization/67326] [5/6 Regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Yeah, we could perhaps look at the other DRs and figure out that because v3[i] has the same index as v2[i] or v1[i], those are accessed unconditionally and v3 has at least as many elements as v1 or v2, v3[i] will not trap if v2[i] will not.
[Bug c++/67337] [4.9/5/6 Regression] Segmentation fault on a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67337 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Perhaps ping this again?
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Richard Biener --- Fixed.
[Bug c++/67354] [5/6 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67354 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- The problem is that first because of the -fabi-version=5 note_mangling_alias calls (at_eof) generate_mangling_alias, which for both base and comp ctors adds a same_comdat_group for the mangling alias. But then we want to put both those ctors into the same comdat group, but it is too late for that.
[Bug c++/67354] [5/6 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67354 --- Comment #8 from Jakub Jelinek --- Created attachment 36728 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36728&action=edit gcc6-pr67354.patch Untested hack that just defers generating mangling aliases if at_eof, until the fns are put into the same comdat group.
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
--- Comment #15 from rguenther at suse dot de ---
On Mon, 16 Nov 2015, uweigand at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
>
> --- Comment #14 from Ulrich Weigand ---
> Building the following reduced test case with
> -O2 -ftree-vectorize -fcx-fortran-rules
> with an spu-elf cross-cc1 shows the ICE.
>
> void
> test (_Complex float *dest,
> _Complex float scale, int count)
> {
> for (int x = 0; x < count; x++)
> dest[x] *= scale;
> }
Bah, too much copy&pasting. TRivial fix:
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c (revision 230421)
+++ gcc/tree-vect-data-refs.c (working copy)
@@ -967,13 +967,13 @@ vect_verify_datarefs_alignment (loop_vec
/* For interleaving, only the alignment of the first access
matters. */
if (STMT_VINFO_GROUPED_ACCESS (stmt_info)
&& GROUP_FIRST_ELEMENT (stmt_info) != stmt)
- return true;
+ continue;
/* Strided accesses perform only component accesses, alignment is
irrelevant for them. */
if (STMT_VINFO_STRIDED_P (stmt_info)
&& !STMT_VINFO_GROUPED_ACCESS (stmt_info))
- return true;
+ continue;
if (! verify_data_ref_alignment (dr))
return false;
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 --- Comment #8 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Mon Nov 16 15:01:01 2015 New Revision: 230427 URL: https://gcc.gnu.org/viewcvs?rev=230427&root=gcc&view=rev Log: backport of fix for PR67280 (r227407) 2015-11-16 Charles Baylis Backport from mainline r227407 PR ipa/67280 * cgraphunit.c (cgraph_node::create_wrapper): Set can_throw_external in new callgraph edge. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/cgraphunit.c
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 --- Comment #6 from rguenther at suse dot de --- On Mon, 16 Nov 2015, clyon at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 > > --- Comment #5 from Christophe Lyon --- > (In reply to Richard Biener from comment #3) > > (In reply to Christophe Lyon from comment #2) > > > (In reply to Richard Biener from comment #1) > > > > Ok, so I assume this is after the fix for PR68306. > > > > > > Indeed: that was fixed at r230310, at which point my build still succeded. > > > > > > It started to fail at r230311. > > > > Hmm, in a tree with the fix for PR68306 I can't reproduce with a cross. > > > > Can you double-check please? > > I've just reproduced it again with an extract at r230402. > > Please make sure you use target armeb-none-linux-gnueabihf, not > arm-none-linux-gnueabihf as Martin used. It works for > arm-none-linux-gnueabihf, > but not for armeb-none-linux-gnueabihf (big-endian) r230428?
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 --- Comment #16 from Richard Biener --- Author: rguenth Date: Mon Nov 16 15:04:00 2015 New Revision: 230428 URL: https://gcc.gnu.org/viewcvs?rev=230428&root=gcc&view=rev Log: 2015-11-16 Richard Biener PR tree-optimization/68306 * tree-vect-data-refs.c (vect_verify_datarefs_alignment): Fix bogus copying from verify_data_ref_alignment and use continue instead of return. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug target/65251] sh4: internal compiler error: Bus error when compiling cpp-netlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65251 --- Comment #8 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #7) > Ping? Please wait a few more days. I'm currently trying a new approach with qemu-sh4 as you have probably seen on the debian-superh mailing list. This will hopefully allow me to reduce compile time by large margin (first benchmarks showed a 100% performance increase), so I will be able to report back more quickly and actually don't have to abuse the buildds for the tests. I am currently test-building gtk+3.0, then I'll gcc-5 a shot. Once I have verified that these work without issues, I will help with the remaining issues in the SH backend. Adrian
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 --- Comment #5 from Christophe Lyon --- (In reply to Richard Biener from comment #3) > (In reply to Christophe Lyon from comment #2) > > (In reply to Richard Biener from comment #1) > > > Ok, so I assume this is after the fix for PR68306. > > > > Indeed: that was fixed at r230310, at which point my build still succeded. > > > > It started to fail at r230311. > > Hmm, in a tree with the fix for PR68306 I can't reproduce with a cross. > > Can you double-check please? I've just reproduced it again with an extract at r230402. Please make sure you use target armeb-none-linux-gnueabihf, not arm-none-linux-gnueabihf as Martin used. It works for arm-none-linux-gnueabihf, but not for armeb-none-linux-gnueabihf (big-endian)
[Bug target/65251] sh4: internal compiler error: Bus error when compiling cpp-netlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65251 --- Comment #7 from Oleg Endo --- Ping?
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Oleg Endo --- I think we can close this as fixed.
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #23 from Oleg Endo --- Ping?
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
--- Comment #14 from Ulrich Weigand ---
Building the following reduced test case with
-O2 -ftree-vectorize -fcx-fortran-rules
with an spu-elf cross-cc1 shows the ICE.
void
test (_Complex float *dest,
_Complex float scale, int count)
{
for (int x = 0; x < count; x++)
dest[x] *= scale;
}
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 --- Comment #7 from cbaylis at gcc dot gnu.org --- I am backporting the fix to GCC 5 now. I'll close it once committed.
[Bug rtl-optimization/68349] [6 regression] ice in decompose_normal_address with -O2 at rtlanal.c:6086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68349 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r228306.
[Bug c++/68362] [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- The problem here is that check_case_bounds is getting NOP_EXPRs: (const A) 0 introduced in convert_and_check called in c_add_case_label, and then it tries tree_int_cst_compare on that, oops. STRIP_NOPS-ing case_low and case_high would fix this...
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #14 from Oleg Endo --- Author: olegendo Date: Mon Nov 16 14:22:10 2015 New Revision: 230426 URL: https://gcc.gnu.org/viewcvs?rev=230426&root=gcc&view=rev Log: gcc/ Backport from mainline 2015-11-16 Oleg Endo Kaz Kojima PR target/68277 * config/sh/sh.md (addsi3_scr): Handle reg overlap of operands[0] and operands[2]. (*addsi3): Add another insn_and_split variant for reload. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sh/sh.md
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #13 from Oleg Endo --- Author: olegendo Date: Mon Nov 16 14:11:50 2015 New Revision: 230425 URL: https://gcc.gnu.org/viewcvs?rev=230425&root=gcc&view=rev Log: gcc/ PR target/68277 * config/sh/sh.md (addsi3_scr): Handle reg overlap of operands[0] and operands[2]. (*addsi3): Add another insn_and_split variant for reload. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68194 --- Comment #6 from ktkachov at gcc dot gnu.org --- Proposed patch at: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01953.html
[Bug middle-end/67653] [4.9/5/6 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67653
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Bet r140431. The issue seems to be that the FEs make the "m" operand
addressable:
if (parse_output_constraint (&constraint, i, ninputs, noutputs,
&allows_mem, &allows_reg, &is_inout))
{
/* If the operand is going to end up in memory,
mark it addressable. */
if (!allows_reg && !cxx_mark_addressable (operand))
operand = error_mark_node;
}
or:
if (!allows_reg && allows_mem)
{
input = c_fully_fold (input, false, NULL);
/* Strip the nops as we allow this case. FIXME, this really
should be rejected or made deprecated. */
STRIP_NOPS (input);
if (!c_mark_addressable (input))
input = error_mark_node;
}
but for the case of a statement expression that doesn't mark it addressable.
Then during gimplify_asm_expr we:
5281 tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
5282is_gimple_lvalue, fb_lvalue |
fb_mayfail);
5283 mark_addressable (TREE_VALUE (link));
5284 if (tret == GS_ERROR)
and in this case tref actually is not GS_ERROR, as it is gimplified to an
artificial decl from a TARGET_EXPR. But it marks addressable something that
has been already used.
No idea what to do here. For "=m" we require lvalue_or_else (after doing a
hack and stripping nops), but for the input operands we don't.
So perhaps just replace the mark_addressable call with something like:
tree x = TREE_VALUE (link);
while (handled_component_p (x))
x = TREE_OPERAND (x, 0);
if (TREE_CODE (x) == MEM_REF
&& TREE_CODE (TREE_OPERAND (x, 0)) == ADDR_EXPR)
x = TREE_OPERAND (TREE_OPERAND (x, 0), 0);
if ((TREE_CODE (x) == VAR_DECL
|| TREE_CODE (x) == PARM_DECL
|| TREE_CODE (x) == RESULT_DECL)
&& !TREE_ADDRESSABLE (x))
{
error ("memory input %d is not directly addressable", i);
ret = GS_ERROR;
}
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #31 from Richard Biener --- Author: rguenth Date: Mon Nov 16 14:06:08 2015 New Revision: 230424 URL: https://gcc.gnu.org/viewcvs?rev=230424&root=gcc&view=rev Log: 2015-11-16 Richard Biener PR middle-end/68117 * cfgexpand.c (pass_expand::execute): Destroy the edge redirection var map before setting RTL CFG hooks. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #6 from ktkachov at gcc dot gnu.org --- So can this be closed?
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Hi. I've just built cross-compiler (on x86_64-linux-pc as host system): ../configure --enable-languages=c,c++ --disable-bootstrap --target=arm-none-linux-gnueabihf and the test-case works for me: ./xgcc -B. /home/marxin/Programming/gcc3/libgfortran/generated/matmul_i4.c -I. -c -O2 -ftree-vectorize -I/usr/include -c I've tried your pre-processed file and also valgrind does not emit any error related to IPA ICF. Martin
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #12 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #10) > (In reply to Oleg Endo from comment #9) > > At the current (lack of) pace I don't know when all of that will be done. > > So my idea was to at least reduce the R0 problem for users by making LRA the > > default in GCC 6. If we have to add the 2nd postreload temporarily, so be > > it. When the other solutions become more mature and stable, we can remove > > the 2nd postreload thing again. > > I don't object. Please go ahead. OK. I would like to wait with that a bit though. I'm still trying to get some work done on AMS... (In reply to Kazumoto Kojima from comment #11) > > I've confirmed that there are no new failures with the new patch on > sh4-unknown-linux-gnu. > BTW, the ICE for gcc.dg/atomic/c11-atomic-exec-4.c -Os pops up again > even with the unmodified tree. So we have no regressions at all. Great, thanks! I'll commit it to trunk and GCC 5 branch.
[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68327 Ilya Enkovich changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ienkovich at gcc dot gnu.org
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #11 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #10) > I'll report back when the regression test currently running is done. I've confirmed that there are no new failures with the new patch on sh4-unknown-linux-gnu. BTW, the ICE for gcc.dg/atomic/c11-atomic-exec-4.c -Os pops up again even with the unmodified tree. So we have no regressions at all.
[Bug sanitizer/67941] [5/6 Regression] calls on function pointer from a captureless lambda cause ubsan warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67941 --- Comment #5 from Jakub Jelinek --- Created attachment 36727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36727&action=edit gcc6-pr67941.patch Random attempt to write some condition, but I really have no idea if it is at least anywhere close to the right one.
[Bug target/68365] gfortran test case showing performance loss with vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 --- Comment #4 from n8tm at aol dot com --- On 11/16/2015 7:13 AM, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 > > Richard Biener changed: > >What|Removed |Added > > Status|WAITING |NEW > > --- Comment #3 from Richard Biener --- > Hmm, there are many loops here. I looked at the following (assuming the > interesting loops are marked with safelen(1)) > > subroutine s111(ntimes,ld,n,ctime,dtime,a,b,c,d,e,aa,bb,cc) > use lcd_mod > C > C linear dependence testing > C no dependence - vectorizable > C > integer ntimes,ld,n,i,nl > real a(n),b(n),c(n),d(n),e(n),aa(ld,n),bb(ld,n),cc(ld,n) > real t1,t2,chksum,ctime,dtime,cs1d > call init(ld,n,a,b,c,d,e,aa,bb,cc,'s111 ') > call forttime(t1) > do nl= 1,2*ntimes > #ifndef __MIC__ > !$omp simd safelen(1) > #endif > do i= 2,n,2 > a(i)= a(i-1)+b(i) > enddo > call dummy(ld,n,a,b,c,d,e,aa,bb,cc,1.) > enddo > call forttime(t2) > > and current trunk doesn't consider this profitable unless -mavx is given > (it needs the larger vector size for profitability it seems). > > Because of the step 2 it ends up using strided stores. Instead of > doing interleaving on the loads and stores we could have just operated > on all elements (rather than only even ones) and then use a masked > store. That would waste half of the vector bandwidth but save all the > shuffles. > > .L8: > vmovups (%rdx), %xmm0 > addl$1, %r9d > addq$64, %rdx > addq$64, %r11 > vmovups -32(%rdx), %xmm2 > vinsertf128 $0x1, -48(%rdx), %ymm0, %ymm1 > vmovups -64(%r11), %xmm9 > vinsertf128 $0x1, -16(%rdx), %ymm2, %ymm3 > vmovups -32(%r11), %xmm11 > vinsertf128 $0x1, -48(%r11), %ymm9, %ymm10 > vinsertf128 $0x1, -16(%r11), %ymm11, %ymm12 > vshufps $136, %ymm3, %ymm1, %ymm4 > vshufps $136, %ymm12, %ymm10, %ymm13 > vperm2f128 $3, %ymm4, %ymm4, %ymm5 > vperm2f128 $3, %ymm13, %ymm13, %ymm14 > vshufps $68, %ymm5, %ymm4, %ymm6 > vshufps $238, %ymm5, %ymm4, %ymm7 > vshufps $68, %ymm14, %ymm13, %ymm15 > vshufps $238, %ymm14, %ymm13, %ymm0 > vinsertf128 $1, %xmm7, %ymm6, %ymm8 > vinsertf128 $1, %xmm0, %ymm15, %ymm1 > vaddps %ymm1, %ymm8, %ymm2 > vextractf128$0x1, %ymm2, %xmm4 > vmovss %xmm2, -60(%rdx) > vextractps $1, %xmm2, -52(%rdx) > vextractps $2, %xmm2, -44(%rdx) > vextractps $3, %xmm2, -36(%rdx) > vmovss %xmm4, -28(%rdx) > vextractps $1, %xmm4, -20(%rdx) > vextractps $2, %xmm4, -12(%rdx) > vextractps $3, %xmm4, -4(%rdx) > cmpl%r9d, %ecx > ja .L8 > > what we fail to realize here is that cross-lane interleaving isn't working > with AVX256 and thus the interleave for the loads is very much more expensive > than we think. > > That's a general vectorizer cost model issue: > > /* Uses an even and odd extract operations or shuffle operations > for each needed permute. */ > int nstmts = ncopies * ceil_log2 (group_size) * group_size; > inside_cost = record_stmt_cost (body_cost_vec, nstmts, vec_perm, > stmt_info, 0, vect_body); > > which 1) doesn't consider single-element interleaving differently, > 2) simply uses vec_perm cost which heavily depends on the actual > (constant) permutation used > Thanks for the interesting analysis. icc/icpc take safelen(1) as preventing vectorization for this case, but I found another stride 2 case where they still perform the unprofitable AVX vectorization. Maybe I'll submit an Intel PR (IPS).
[Bug rtl-optimization/68321] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68321 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW Depends on||68143 Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #6 from Richard Biener --- -fno-ree fixes this one as well. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68143 [Bug 68143] [5/6 Regression][ARM] Wrong code initialising struct member after zeroing out the whole struct
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #46 from rguenther at suse dot de --- On Mon, 16 Nov 2015, jeehoon.kang at sf dot snu.ac.kr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 > > --- Comment #45 from Jeehoon Kang --- > > I think this is not true. For example with MatLab (might be sth else, > > if I don't remember correctly) you are required to pass pointers to > > arrays in two halves in double(!) values (I believe the only function > > argument type they support). GCC happily makes points-to analysis work > > through those. > > Thank you for giving me an example. Yet, I think it is a little bit > unfortunate for MatLab (or sth else) to pass pointers by packing two into a > double, at least due to the readability problem. I think it is beyond the > intended usage of the C/C++ language, but I understand that GCC is the > time-honored compiler for various software and systems. > > > > > The other (unfortunate) thing is that in GCC pointer subtraction > > is always performed on integers, thus for the C source code > > > > int idx = ptr1 - ptr2; > > > > we internally have sth like > > > > int idx = ((long)ptr1 - (long)ptr2) / 4; > > > > so you can't really treat pointers as "escaped" here without loss. > > Thank you for giving me the information. I don't know the GCC internals, so I > would like to ask how much it would cost to introduce the syntax for pointer > subtractions. I hope it is not that huge, but I really don't have any idea. It would be quite some (mechanical) work but otherwise not too difficult. There is the choice whether to embed the division implicitely here or not. > > Note that we've had this (kind of) in the past and it tried to go > > without making pointers escaped at these points but only consider > > casts from integers to pointers as pointing to anything. But > > that's wrong correctness wise (not then treating the cast to integer > > as escape point). > > Treating the cast to integer as escape point is proven-correct by a > machine-checked proof (in Coq) for various standard optimization examples, > such > as CP, DCE, dead allocation elimination, etc. For more detail, please see the > paper above-mentioned. Yes, I agree that making this an escape point is enough.
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 --- Comment #13 from Richard Biener --- Can you attach preprocessed source? See also PR68367 which I can't reproduce with a cross.
[Bug sanitizer/67941] [5/6 Regression] calls on function pointer from a captureless lambda cause ubsan warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67941 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The UBSAN_NULL instrumentation is added in c-family/c-ubsan.c (ubsan_maybe_instrument_member_call), on stmt that is main()operator() (0B) i.e.: > side-effects nothrow protected fn unsigned DI size unit size align 64 symtab 0 alias set -1 canonical type 0x7187c888> constant arg 0 addressable used nothrow static tree_2 autoinline decl_3 decl_5 QI file pr67941.C line 1 col 18 align 16 context initial result full-name "main()::" pending-inline-info 0x77ff9d80 arguments struct-function 0x7187c738>> arg 0 constant 0> pr67941.C:1:20 start: pr67941.C:1:20 finish: pr67941.C:1:20> And as the call is to a method (which has METHOD_TYPE), UBSAN_NULL is inserted. If this is valid, can you suggest which method calls the C++ FE considers (just with literal NULL passed to this, or others too?) valid?
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 --- Comment #4 from Dominique d'Humieres --- With the patch at https://gcc.gnu.org/ml/fortran/2015-11/msg00093.html, compiling the test gives the error pr60993.f90:7:45: integer, parameter :: infn(2) = [Z'',Z'FFF0'] 1 Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1). This check can be disabled with the option '-fno-range-check' The test compiles with the suggested option '-fno-range-check', but the output is sinfn=-Infinity sinfp= Infinity dinfp= Infinitydinfp1= 0. dinfn= -Infinity With the following change --- pr60993.f90 2014-04-29 22:32:47.0 +0200 +++ pr60993_db.f90 2015-11-16 13:26:14.0 +0100 @@ -14,7 +14,7 @@ sinfp = transfer(Z'7F80', sinfp) print *, "sinfn=", sinfn, " sinfp=", sinfp dinfp = transfer(infp, dinfp) ! Works - dinfp1 = transfer([Z'',Z'7FF0'], dinfp1) ! Fails --- Why?? + dinfp1 = transfer(int([Z'',Z'7FF0'],kind=4), dinfp1) ! Fails --- Why?? print *, "dinfp=",dinfp, " dinfp1=", dinfp1 the output is sinfn=-Infinity sinfp= Infinity dinfp= Infinitydinfp1= Infinity dinfn= -Infinity
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 Ulrich Weigand changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #12 from Ulrich Weigand --- Unfortunately, it seems that your second commit brought back the failure on spu-elf that had already been fixed by the first commit ... /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/libgfortran/generated/matmul_c4.c: In function 'matmul_c4': /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/libgfortran/generated/matmul_c4.c:79:1: internal compiler error: in vectorizable_store, at tree-vect-stmts.c:5655 matmul_c4 (gfc_array_c4 * const restrict retarray, ^ 0x10b19c83 vectorizable_store /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vect-stmts.c:5655 0x10b21db3 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vect-stmts.c:8007 0x10b49ecf vect_schedule_slp_instance /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vect-slp.c:3608 0x10b503ab vect_schedule_slp(vec_info*) /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vect-slp.c:3673 0x10b2dffb vect_transform_loop(_loop_vec_info*) /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vect-loop.c:6773 0x10b57ab3 vectorize_loops() /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vectorizer.c:533 0x109fa5d7 execute /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-ssa-loop.c:273
[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 --- Comment #7 from Jonathan Wakely --- I would suggest not using exceptions with iostreams, they've always been an odd mix anyway.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #45 from Jeehoon Kang ---
> I think this is not true. For example with MatLab (might be sth else,
> if I don't remember correctly) you are required to pass pointers to
> arrays in two halves in double(!) values (I believe the only function
> argument type they support). GCC happily makes points-to analysis work
> through those.
Thank you for giving me an example. Yet, I think it is a little bit
unfortunate for MatLab (or sth else) to pass pointers by packing two into a
double, at least due to the readability problem. I think it is beyond the
intended usage of the C/C++ language, but I understand that GCC is the
time-honored compiler for various software and systems.
> The other (unfortunate) thing is that in GCC pointer subtraction
> is always performed on integers, thus for the C source code
>
> int idx = ptr1 - ptr2;
>
> we internally have sth like
>
> int idx = ((long)ptr1 - (long)ptr2) / 4;
>
> so you can't really treat pointers as "escaped" here without loss.
Thank you for giving me the information. I don't know the GCC internals, so I
would like to ask how much it would cost to introduce the syntax for pointer
subtractions. I hope it is not that huge, but I really don't have any idea.
> Note that we've had this (kind of) in the past and it tried to go
> without making pointers escaped at these points but only consider
> casts from integers to pointers as pointing to anything. But
> that's wrong correctness wise (not then treating the cast to integer
> as escape point).
Treating the cast to integer as escape point is proven-correct by a
machine-checked proof (in Coq) for various standard optimization examples, such
as CP, DCE, dead allocation elimination, etc. For more detail, please see the
paper above-mentioned.
> I also don't think doing the above would solve the cases of equality
> compares of pointes themselves. (hopefully undefined)
The formal memory model in the paper I mentioned invokes undefined behavior for
the pointer equality comparison example above. In the formal model, a pointer
is represented as a pair of a memory block identifier (l) and an offset (o).
(cf. the CompCert memory model) When a memory is malloc-ed or alloca-ed, a new
memory block identifier is assigned. A pointer equality, say of (l, o) and
(l', o'), invokes undefined behavior when l != l'.
So for the following example (by Alexander Cherepanov):
#include
#include
int main() {
int y, x = 0;
int *volatile v = &x;
int *xp = v;
int *i = &y + 1;
if (xp != i) {
printf("hello\n");
xp = i;
}
printf("%d\n", xp == &x);
}
Say y and x are allocated at l1 and l2, respectively. Then xp = (l2, 0), and i
= (l1, 4). Thus comparing xp and i invokes undefined behavior, since l1 != l2.
[Bug target/68365] gfortran test case showing performance loss with vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 Richard Biener changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Richard Biener --- Hmm, there are many loops here. I looked at the following (assuming the interesting loops are marked with safelen(1)) subroutine s111(ntimes,ld,n,ctime,dtime,a,b,c,d,e,aa,bb,cc) use lcd_mod C C linear dependence testing C no dependence - vectorizable C integer ntimes,ld,n,i,nl real a(n),b(n),c(n),d(n),e(n),aa(ld,n),bb(ld,n),cc(ld,n) real t1,t2,chksum,ctime,dtime,cs1d call init(ld,n,a,b,c,d,e,aa,bb,cc,'s111 ') call forttime(t1) do nl= 1,2*ntimes #ifndef __MIC__ !$omp simd safelen(1) #endif do i= 2,n,2 a(i)= a(i-1)+b(i) enddo call dummy(ld,n,a,b,c,d,e,aa,bb,cc,1.) enddo call forttime(t2) and current trunk doesn't consider this profitable unless -mavx is given (it needs the larger vector size for profitability it seems). Because of the step 2 it ends up using strided stores. Instead of doing interleaving on the loads and stores we could have just operated on all elements (rather than only even ones) and then use a masked store. That would waste half of the vector bandwidth but save all the shuffles. .L8: vmovups (%rdx), %xmm0 addl$1, %r9d addq$64, %rdx addq$64, %r11 vmovups -32(%rdx), %xmm2 vinsertf128 $0x1, -48(%rdx), %ymm0, %ymm1 vmovups -64(%r11), %xmm9 vinsertf128 $0x1, -16(%rdx), %ymm2, %ymm3 vmovups -32(%r11), %xmm11 vinsertf128 $0x1, -48(%r11), %ymm9, %ymm10 vinsertf128 $0x1, -16(%r11), %ymm11, %ymm12 vshufps $136, %ymm3, %ymm1, %ymm4 vshufps $136, %ymm12, %ymm10, %ymm13 vperm2f128 $3, %ymm4, %ymm4, %ymm5 vperm2f128 $3, %ymm13, %ymm13, %ymm14 vshufps $68, %ymm5, %ymm4, %ymm6 vshufps $238, %ymm5, %ymm4, %ymm7 vshufps $68, %ymm14, %ymm13, %ymm15 vshufps $238, %ymm14, %ymm13, %ymm0 vinsertf128 $1, %xmm7, %ymm6, %ymm8 vinsertf128 $1, %xmm0, %ymm15, %ymm1 vaddps %ymm1, %ymm8, %ymm2 vextractf128$0x1, %ymm2, %xmm4 vmovss %xmm2, -60(%rdx) vextractps $1, %xmm2, -52(%rdx) vextractps $2, %xmm2, -44(%rdx) vextractps $3, %xmm2, -36(%rdx) vmovss %xmm4, -28(%rdx) vextractps $1, %xmm4, -20(%rdx) vextractps $2, %xmm4, -12(%rdx) vextractps $3, %xmm4, -4(%rdx) cmpl%r9d, %ecx ja .L8 what we fail to realize here is that cross-lane interleaving isn't working with AVX256 and thus the interleave for the loads is very much more expensive than we think. That's a general vectorizer cost model issue: /* Uses an even and odd extract operations or shuffle operations for each needed permute. */ int nstmts = ncopies * ceil_log2 (group_size) * group_size; inside_cost = record_stmt_cost (body_cost_vec, nstmts, vec_perm, stmt_info, 0, vect_body); which 1) doesn't consider single-element interleaving differently, 2) simply uses vec_perm cost which heavily depends on the actual (constant) permutation used
[Bug target/66776] [AArch64] zero-extend version of csel not matching properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66776 --- Comment #2 from ktkachov at gcc dot gnu.org --- Renlin, can you close this PR if there's nothing more to do here?
[Bug tree-optimization/68157] [5/6 Regression] internal compiler error: in reassoc_stmt_dominates_stmt_p, at tree-ssa-reassoc.c:1287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68157 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 36726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36726&action=edit gcc6-pr68157.patch Untested fix.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #35 from chrbr at gcc dot gnu.org --- Specific NEON case fixed with the attribute/pragma target support for fpu= attribute support can now be extended for other target flags that need to be propagated to LTO (-mcpu=, -mtune=, -munaligned-access...)
[Bug jit/68370] Pointer arithmetic in libgccjit seems to require an extra cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68370 --- Comment #2 from David Malcolm --- Thanks for reporting this. That error message: libgccjit.so: error: gcc_jit_block_add_assignment: mismatching types: assignment to text (type: const char *) from &text[(int)1] (type: const char *) looks wrong. Please can you attach the full reproducer as a .c file (perhaps using gcc_jit_context_dump_reproducer_to_file; see https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#gcc_jit_context_dump_reproducer_to_file ).
[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r230365 aka C++ delayed folding merge.
[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68195 --- Comment #6 from Matthias Goldhoorn --- (In reply to Jonathan Wakely from comment #5) > Fails with gcc-5-branch, but doesn't fail on trunk for me. Is there a trunk branch or tag available i can try to compile, the last versions i tried does not compile (the compiler itself).
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #41 from H.J. Lu --- (In reply to Andrew Pinski from comment #39) > You should also update gimplify.c's zero_sized_type to be the same as your > empty_record_p. It won't work since the size of empty class isn't zero in C++. We just pass and return it like zero size record in C++.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #40 from H.J. Lu --- (In reply to H.J. Lu from comment #38) > Created attachment 36724 [details] > An updated patch to add empty_record_p > > I am testing it now. It doesn't work since it misses for (binfo = TYPE_BINFO (type), i = 0; BINFO_BASE_ITERATE (binfo, i, base_binfo); ++i) if (!is_really_empty_class (BINFO_TYPE (base_binfo))) return false; in is_really_empty_class in cp/class.c. It is language specific.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #34 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon Nov 16 11:20:02 2015 New Revision: 230410 URL: https://gcc.gnu.org/viewcvs?rev=230410&root=gcc&view=rev Log: 2015-11-16 Christian Bruel PR target/65837 * config/arm/arm-c.c (arm_cpu_builtins): Conditionally set and reset __ARM_FEATURE_FMA and __ARM_NEON_FP, __ARM_FP. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-c.c
[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68194
--- Comment #5 from ktkachov at gcc dot gnu.org ---
The different if-conversion behaviour enabled a new cse opportunity
which then produced the RTL that triggered the bad ree behaviour.
The relevant RTL insns before the ree pass look like:
Basic Block A:
(set (reg:HI 0 ax)
(mem:HI (symbol_ref:DI ("f"
...
(set (reg:SI 3 bx)
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0))
(reg:SI 0 ax)
(reg:SI 3 bx)))
(set (reg:SI 4 si)
(sign_extend:SI (reg:HI 3 bx)))
...
Basic block B (dominated by basic block A):
(set (reg:SI 4 si)
(sign_extend:SI (reg:QI 0 ax))) /* ax contains symbol "f". */
ree changes that into the broken:
Basic block A:
(set (reg:SI 4 si)
(sign_extend:SI (mem:HI (symbol_ref:DI ("f")
(set (reg:SI 3 bx)
(reg:SI 4 si))
...
(set (reg:SI 3 bx)
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:SI 0 ax)
(reg:SI 3 bx)))
...
Basic block B:
(set (reg:SI 4 si)
(sign_extend:SI (reg:QI 0 ax))) /* Insn unchanged by ree, but ax now
undefined. */
[Bug rtl-optimization/68189] [4.9/5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu by RTL if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68189 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Bet another PR68328 case. I'd say until that is fixed, all these vars only conditionally initialized in a conditional move are suspected dups.
