[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138 --- Comment #6 from Jakub Jelinek --- As a proof of concept, I've changed in the debugger the last stmt in that bb to: tmp.5_53 = stmp_c_10.10_67; and called update_stmt on it, and the result is the test passing.
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138 --- Comment #7 from Jakub Jelinek --- The bogus assignment is generated by vect_update_ivs_after_vectorizer, niters is 1334 and step_expr 1335. But it misses the fact that the value it is multiplying is not constant, but changes in every iteration of the outer loop, so it really has to be double reduction. Not really familiar with this part of the vectorizer, so leaving the analysis at this point.
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138
--- Comment #8 from Jakub Jelinek ---
Further improved testcase (just decrease number of iterations somewhat, and
make sure the u elements that are summed are different in each outer loop
iteration, to verify the vectorizer doesn't just multiply value from some
iteration by the number of iterations):
double u[333 * 333];
__attribute__((noinline, noclone)) static void
foo (int *x)
{
double c = 0.0;
int a, b;
for (a = 0; a < 333; a++)
{
for (b = 0; b < 333; b++)
c = c + u[334 * a];
u[334 * a] *= 2.0;
}
*x = c;
}
int
main ()
{
int d, e;
for (d = 0; d < 333 * 333; d++)
u[d] = 499.0;
for (d = 0; d < 333; d++)
u[d * 334] = (d + 2);
foo (&e);
if (e != 333 * (2 + 334) / 2 * 333)
__builtin_abort ();
return 0;
}
BTW, I'm really surprised we vectorize this even without -Ofast, it is a double
reduction, therefore reducing it causes different floating point operations
between the vectorized and non-vectorized cases.
[Bug c++/70153] New: [6 Regression] ICE on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70153 Bug ID: 70153 Summary: [6 Regression] ICE on valid C++ code Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vsevolod.livinskij at frtk dot ru Target Milestone: --- Created attachment 37903 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37903&action=edit Reproducer. Testcase produces ICE with -O0. Everything works fine with gcc version 4.9.4 (Revision=233979) and gcc version 5.3.1 (Revision=233979). Tested with -march=core-avx2, -march=corei7-avx and -march=knl. Error: > g++ -O0 repr.cpp -S g++: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. GCC version: > g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/export/users/vlivinsk/gcc-trunk/bin/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /export/users/vlivinsk/gcc-trunk/gcc/configure --with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --enable-cloog-backend=isl --with-fpmath=sse --enable-checking=release --enable-languages=c,c++,lto --with-gmp=/export/users/vlivinsk/gcc-trunk/gmp-6.1.0/bin --with-mpfr=/export/users/vlivinsk/gcc-trunk/mpfr-3.1.3/bin --with-mpc=/export/users/vlivinsk/gcc-trunk/mpc-1.0.3/bin --prefix=/export/users/vlivinsk/gcc-trunk/bin Thread model: posix gcc version 6.0.0 20160309 (experimental) (Revision=234075)
[Bug fortran/70149] Character pointer initialization causes ICE. (F2008)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-09 Blocks||31392, 68241 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31392 [Bug 31392] [meta-bug] gfortran problems with initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 [Bug 68241] [meta-bug] Deferred-length character
[Bug c++/70153] [6 Regression] ICE on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70153 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-09 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Looks like a stack overflow in fold-const.c.
[Bug middle-end/70050] [6 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have vector_type in generic_simplify_162, at generic-mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70050 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Wed Mar 9 09:20:18 2016 New Revision: 234079 URL: https://gcc.gnu.org/viewcvs?rev=234079&root=gcc&view=rev Log: PR target/67278 * gcc.dg/simd-8.c: Add -w -Wno-psabi to dg-options. PR middle-end/70050 * gcc.dg/pr70050.c: Add -w to dg-options. Fix up PR number in testcase comment. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr70050.c trunk/gcc/testsuite/gcc.dg/simd-8.c
[Bug target/67278] [4.9/5 Regression] ICE: verify_gimple failed on darwin 14.5 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67278 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Wed Mar 9 09:20:18 2016 New Revision: 234079 URL: https://gcc.gnu.org/viewcvs?rev=234079&root=gcc&view=rev Log: PR target/67278 * gcc.dg/simd-8.c: Add -w -Wno-psabi to dg-options. PR middle-end/70050 * gcc.dg/pr70050.c: Add -w to dg-options. Fix up PR number in testcase comment. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr70050.c trunk/gcc/testsuite/gcc.dg/simd-8.c
[Bug target/67278] [4.9/5 Regression] ICE: verify_gimple failed on darwin 14.5 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67278 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Wed Mar 9 09:23:53 2016 New Revision: 234080 URL: https://gcc.gnu.org/viewcvs?rev=234080&root=gcc&view=rev Log: PR middle-end/67278 * gcc.dg/simd-7.c: Add -w -Wno-psabi to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/simd-7.c
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #13 from Leon Winter --- The incorrect warning is only displayed when using an optimization level better than none (-O0) (this applies to your testcase and my real-world code). Your minimized test case is already wrongfully blamed by gcc-4.8. My non-testcase real-world code (C++ in -O1 and -O2 and -O3) is even more exciting since g++-4.8 complains, g++-4.9 does not but g++-5 complains again. So there might be a recurring regression in place. I will try to track down the regression from 4.9 to 5.3 since it is the latest version.
[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058 --- Comment #12 from rguenther at suse dot de --- On Tue, 8 Mar 2016, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058 > > --- Comment #11 from Jeffrey A. Law --- > The underlying randomness of coalescing is inherently due to the instability > of > SSA_NAME_VERSION. If we make SSA_NAME_VERSION stable, then the randomness of > coalescing goes away. > > So I essentially toss away the existing version #s and rebuild them in a walk > over the IL. First assignment gets #1, second assignment gets #2, and so-on. > > That brings relative stability to the version #s, which in turn brings > stability to the coalescer. > > I suspect the existing cases that aren't stable are probably due to default > defs or somesuch. Those don't have assignments and thus are still getting a > pseudo-random SSA_NAME_VERSION after my renumbering. Doesn't making the coalesce sort stable in almost the same stability in the end? Like with the simple counter idea that would basically provide a mapping between old SSA version and a virtual "new" one. I don't think we want to pay the compile-time cost of the rebuild or the churn on SSA names.
[Bug tree-optimization/70045] [6 Regression] ICE error: mismatching comparison operand types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70045 --- Comment #2 from vries at gcc dot gnu.org --- Created attachment 37904 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37904&action=edit tentative patch
[Bug c++/70153] [6 Regression] ICE on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70153 Markus Trippelsdorf changed: What|Removed |Added Target|x86_64 | --- Comment #2 from Markus Trippelsdorf --- Started with r230365: commit d2c638268e30dea7631ca2ee9b7489da2317526b Author: jason Date: Sat Nov 14 00:08:05 2015 + Merge C++ delayed folding branch.
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- The warning is "correct". You are accessing object *ap (a struct a) via a pointer to struct b. That ap really points to a b is something the FE code doesn't know at this point. I'll see if we can somehow make the FE code "smarter".
[Bug tree-optimization/69042] [6 regression] Missed optimization in ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042 --- Comment #9 from amker at gcc dot gnu.org --- (In reply to amker from comment #8) > Though adding candidate with offset stripped from base helps this case, it > causes other regressions which I need to understand. I can confirm that one major regression on AArch64 for spec2k is in 173.applu. The root cause is this change increases candidate number. The number exceeds the default "--param iv-consider-all-candidates-bound=30". It can be resolved by increasing this param. Other regressions seem false alarms, I couldn't reproduce it. There are some small improvements in other cases, overall the spec2k perf isn't changed on AArch64. I will check spec2k6 and will send the patch if there is no regression either. And can we increase the param bound a little now (or in GCC 7)?
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 --- Comment #3 from Jakub Jelinek --- Note even GCC 5.x and earlier warn here with -Wstrict-aliasing=2 or -Wstrict-aliasing=1, it is just whether we warn about this with the most common one -Wstrict-aliasing=3.
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 --- Comment #4 from Pedro Alves --- > The warning is "correct". You are accessing object *ap (a struct a) via a > pointer to struct b. I'd think that instead, we are accessing object "*&ap->i", an int, via a pointer to struct b, and I'd imagine that the problem is that the frontend doesn't know that struct *b and int * can alias, because the first field of 'struct a', which in turn is the first field of 'struct b', is an int. So I don't see how you can call this correct? Is this really just a warning problem, or does the compiler really think that struct *b and int * cannot alias? > I'll see if we can somehow make the FE code "smarter". I imagine that the frontend misses recursing through the first field of the first field of a struct, when adding valid-alias types.
[Bug c++/67658] [concepts] invalid code with constrained concepts compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67658 Irfan Adilovic changed: What|Removed |Added CC||irfanadilovic at gmail dot com --- Comment #1 from Irfan Adilovic --- The 20160306 snapshot exhibits the same behavior, which is explicitly commented as being forbidden at the end of [dcl.spec.concept] paragraph 6.
[Bug rtl-optimization/69633] [6 Regression] Redundant move is generated after r228097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633 --- Comment #3 from Yuri Rumyantsev --- Sorry for a confusion. The bug must be closed as user mistake. 2016-03-07 19:18 GMT+03:00 bernds at gcc dot gnu.org : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633 > > Bernd Schmidt changed: > >What|Removed |Added > > CC||bernds at gcc dot gnu.org > > --- Comment #2 from Bernd Schmidt --- > Doesn't seem to happen over here. Can you still reproduce this with trunk? > Please post exact arguments to cc1 if it does. > > -- > You are receiving this mail because: > You reported the bug.
[Bug tree-optimization/70152] [4.9/5/6 Regression] gcc ICE at -O3 and above on valid code on x86_64-linux-gnu in "replace_uses_by"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70152 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 37905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37905&action=edit gcc6-pr70152.patch Untested fix.
[Bug rtl-optimization/69633] [6 Regression] Redundant move is generated after r228097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633 Ilya Enkovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ienkovich at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Ilya Enkovich --- Closing then.
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143
--- Comment #5 from rguenther at suse dot de ---
On Wed, 9 Mar 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143
>
> --- Comment #3 from Jakub Jelinek ---
> Note even GCC 5.x and earlier warn here with -Wstrict-aliasing=2 or
> -Wstrict-aliasing=1, it is just whether we warn about this with the most
> common
> one -Wstrict-aliasing=3.
Sure. I can trivially re-instantiate previous behavior with
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 234025)
+++ gcc/c-family/c-common.c (working copy)
@@ -1568,7 +1568,9 @@ strict_aliasing_warning (tree otype, tre
alias_set_type set2 = get_alias_set (TREE_TYPE (type));
if (set1 != set2 && set2 != 0
- && (set1 == 0 || !alias_set_subset_of (set2, set1)))
+ && (set1 == 0
+ || (!alias_set_subset_of (set2, set1)
+ && !alias_set_subset_of (set1, set2
{
warning (OPT_Wstrict_aliasing, "dereferencing type-punned "
"pointer will break strict-aliasing rules");
or with the suggested && !alias_sets_conflict_p (set1, set2).
Though that will FAIL the gcc.dg/Wstrict-aliasing-struct-member.c
I added.
Note that we then also don't warn for
struct a {
int i;
int k;
};
struct b {
struct a a;
int j;
};
int main(void) {
static struct b b;
struct a *ap=(struct a *)&b;
return ((struct b *)&ap->k)->j;
}
then either. Doing this kind of warnings strictly based on alias
sets only is going to be "broken" - though I consider our strict-aliasing
warnings broken anyway (and I don't think we can ever implement something
sensible :/).
[Bug rtl-optimization/69633] [6 Regression] Redundant move is generated after r228097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633 Jakub Jelinek changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2016-03-09 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #5 from Jakub Jelinek --- Strange, I can still reproduce it: ./cc1.228094 -quiet -O2 -m32 -fPIE pr69633.c -o pr69633.s1 -march=i386 \ -mtune=generic ./cc1.228097 -quiet -O2 -m32 -fPIE pr69633.c -o pr69633.s2 -march=i386 \ -mtune=generic ./cc1.228153 -quiet -O2 -m32 -fPIE pr69633.c -o pr69633.s3 -march=i386 \ -mtune=generic ./cc1.234064 -quiet -O2 -m32 -fPIE pr69633.c -o pr69633.s4 -march=i386 \ -mtune=generic Compared to the first one, all the others have one more instruction in the function. E.g. between s1 and s3 there is: @@ -44,17 +41,18 @@ foo: addl%edi, %ebx imull $7471, %ecx, %edi leal32768(%ebx,%edi), %ebx - imull $-15119, %eax, %edi sarl$16, %ebx movb%bl, -3(%ebp) movl%edx, %ebx sall$15, %ebx - subl%edx, %ebx + movl%ebx, %edi + imull $-15119, %eax, %ebx + subl%edx, %edi + imull $13282, %edx, %edx addl%edi, %ebx imull $-17648, %ecx, %edi - imull $13282, %edx, %edx - leal32768(%ebx,%edi), %ebx imull $19485, %ecx, %ecx + leal32768(%ebx,%edi), %ebx sarl$16, %ebx movb%bl, -2(%ebp) movl%eax, %ebx s1 to s4 has more changes, but also one more instruction.
[Bug c++/70153] [6 Regression] ICE on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70153 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- I'd like to look into this.
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143
--- Comment #6 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #5)
> Though that will FAIL the gcc.dg/Wstrict-aliasing-struct-member.c
> I added.
>
> Note that we then also don't warn for
>
> struct a {
> int i;
> int k;
> };
> struct b {
> struct a a;
> int j;
> };
> int main(void) {
> static struct b b;
> struct a *ap=(struct a *)&b;
> return ((struct b *)&ap->k)->j;
> }
>
> then either. Doing this kind of warnings strictly based on alias
> sets only is going to be "broken" - though I consider our strict-aliasing
> warnings broken anyway (and I don't think we can ever implement something
> sensible :/).
The point of -Wstrict-aliasing=3 is to give very few false positives and still
catch lots of likely bugs. So, if there is INDIRECT_REF or *MEM_REF involved
and you can't analyze what it points to, we should err on the side that it
might be valid, people can still use -Wstrict-aliasing=2 that will warn even
about these.
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143
--- Comment #7 from rguenther at suse dot de ---
On Wed, 9 Mar 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143
>
> --- Comment #6 from Jakub Jelinek ---
> (In reply to rguent...@suse.de from comment #5)
> > Though that will FAIL the gcc.dg/Wstrict-aliasing-struct-member.c
> > I added.
> >
> > Note that we then also don't warn for
> >
> > struct a {
> > int i;
> > int k;
> > };
> > struct b {
> > struct a a;
> > int j;
> > };
> > int main(void) {
> > static struct b b;
> > struct a *ap=(struct a *)&b;
> > return ((struct b *)&ap->k)->j;
> > }
> >
> > then either. Doing this kind of warnings strictly based on alias
> > sets only is going to be "broken" - though I consider our strict-aliasing
> > warnings broken anyway (and I don't think we can ever implement something
> > sensible :/).
>
> The point of -Wstrict-aliasing=3 is to give very few false positives and still
> catch lots of likely bugs. So, if there is INDIRECT_REF or *MEM_REF involved
> and you can't analyze what it points to, we should err on the side that it
> might be valid, people can still use -Wstrict-aliasing=2 that will warn even
> about these.
Ok, I'll remove the new test and test
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 234025)
+++ gcc/c-family/c-common.c (working copy)
@@ -1568,7 +1568,9 @@ strict_aliasing_warning (tree otype, tre
alias_set_type set2 = get_alias_set (TREE_TYPE (type));
if (set1 != set2 && set2 != 0
- && (set1 == 0 || !alias_set_subset_of (set2, set1)))
+ && (set1 == 0
+ || (!alias_set_subset_of (set2, set1)
+ && !alias_sets_conflict_p (set1, set2
{
warning (OPT_Wstrict_aliasing, "dereferencing type-punned "
"pointer will break strict-aliasing rules");
then.
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143
--- Comment #8 from Pedro Alves ---
> Note that we then also don't warn for
(...)
> struct a { int i; int k; };
> return ((struct b *)&ap->k)->j;
(...)
> then either
I see it the same as:
int *ip = &ap->k;
((struct b *)ip)->j;
Fine from type alias perspective, but undefined for other reasons.
> Doing this kind of warnings strictly based on alias
> sets only is going to be "broken"
Agreed -- a warning for this case should probably be based on
layout / determining that k is not the initial field of struct a,
and thus this is undefined behavior.
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 --- Comment #9 from Jakub Jelinek --- (In reply to Pedro Alves from comment #8) > I see it the same as: > > int *ip = &ap->k; > ((struct b *)ip)->j; That is certainly not fine from aliasing perspective, aliasing is not just about the type of the field you access, but the whole access path, so if you use ((struct b *)ip)->j then ip should point to an object with effective type of struct b. But, I'm afraid we can't warn about this for -Wstrict-aliasing=3, because that would lead to too many false positives.
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 --- Comment #10 from rguenther at suse dot de --- On Wed, 9 Mar 2016, palves at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 > > --- Comment #4 from Pedro Alves --- > > The warning is "correct". You are accessing object *ap (a struct a) via a > > pointer to struct b. > > I'd think that instead, we are accessing object "*&ap->i", an int, via a > pointer > to struct b, and I'd imagine that the problem is that the frontend doesn't > know > that struct *b and int * can alias, because the first field of 'struct a', > which > in turn is the first field of 'struct b', is an int. > > So I don't see how you can call this correct? > > Is this really just a warning problem, or does the compiler really think that > struct *b and int * cannot alias? They can alias. But 'struct *b' and an 'int' object can't. Well. At least if the dynamic type of the 'int' object is still 'int'. See tree-ssa-alias.c:indirect_ref_may_alias_decl_p /* When we are trying to disambiguate an access with a pointer dereference as base versus one with a decl as base we can use both the size of the decl and its dynamic type for extra disambiguation. ??? We do not know anything about the dynamic type of the decl other than that its alias-set contains base2_alias_set as a subset which does not help us here. */ /* As we know nothing useful about the dynamic type of the decl just use the usual conflict check rather than a subset test. ??? We could introduce -fvery-strict-aliasing when the language does not allow decls to have a dynamic type that differs from their static type. Then we can check !alias_set_subset_of (base1_alias_set, base2_alias_set) instead. */ if (base1_alias_set != base2_alias_set && !alias_sets_conflict_p (base1_alias_set, base2_alias_set)) return false;
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 --- Comment #11 from Pedro Alves --- > That is certainly not fine from aliasing perspective, aliasing is not just > about the type of the field you access, but the whole access path, so if you > use ((struct b *)ip)->j then ip should point to an object with effective type > of struct b. Sorry, bad choice of words (and I'm not that familiar with gcc internals, as you'll have guessed). I meant "pointer type conversion" perspective. IOW, this particular particular ip can never point to a struct b, but not because the pointers' static types are incompatible. > use ((struct b *)ip)->j then ip should point to an object with effective type > of struct b. > But, I'm afraid we can't warn about this for -Wstrict-aliasing=3, because that > would lead to too many false positives. I see three distinct cases: #1 - 'ip' has dynamic type 'int *' (can also be some "struct *" that has int as first field) extern int *ip; ((struct b *)ip)->j; #2 - 'ip' has dynamic type "final" 'int *' static struct b b; struct a *ap=(struct a *)&b; int *ip = &ap->k; ((struct b *)ip)->j; #3 - 'ip' has dynamic type "final" 'struct b *'. static struct b b; struct a *ap=(struct a *)&b; int *ip = &ap->i; ((struct b *)ip)->j; Sounds like gcc doesn't distinguish #1 from #2. IOW, it's missing some kind of tracking whether the dynamic type is "final"?
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #4 from Richard Biener --- Note that the cited rev. only changed cost modeling so what you really want to do is to build and bisect with -fno-vect-cost-model (or -fvect-cost-model=unlimited).
[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70133 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #3 from Christophe Lyon --- I do not have access to the hardware you are using, but here is what I observed on an APM board. I built several flavors of GCC, and compiled your attached testcase, and here are the directives generated in the assembler file: gcc-trunk: .arch armv8-a+fp+sim gcc-linaro-5.2-2015.11-2/hello.s: .cpu generic+fp+simd gcc-linaro-snapshot-5.3-2016.02/hello.s: .arch armv8-a+fp+simd All 3 are accepted by the version of gas installed on the machine (2.25/ubuntu) As Kyrylo suggested, can you try either with gcc-trunk or with a newer version of Linaro GCC? In particular, we backported the commit he mentions (r227028) after release 2015.11 was made, and it is available in our latest snapshot.
[Bug target/69841] Wrong template instantiation in C++11 on armv7l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69841 --- Comment #5 from James Greenhalgh --- I don't know enough about the C++ standard to know whether this patch is reasonable to backport to GCC 5. Jason, do you have an opinion?
[Bug target/70123] [6 Regression] Miscompilation of cfitsio testcase on s390x-linux starting with r222144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70123 --- Comment #4 from Bernd Schmidt --- Created attachment 37906 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37906&action=edit Candidate patch Jakub, if you have a machine to test this on, can you try this patch? It's probably not the full patch I'll submit, but it should cure this particular issue.
[Bug tree-optimization/70144] [4.9/5/6 Regression] g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70144 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 37907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37907&action=edit gcc6-pr70144.patch Untested fix.
[Bug tree-optimization/70154] New: [openacc] failing alias analysis in oacc kernels region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70154
Bug ID: 70154
Summary: [openacc] failing alias analysis in oacc kernels
region
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: ---
Created attachment 37908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37908&action=edit
kernels-alias-ipa-pta-fail.c, to be run in gcc/testsuite/c-c++-common/goacc/
parloops fails to parallelize this testcase.
After ipa-pta, we have:
...
# VUSE <.MEM_2>
# PT = nonlocal unit-escaped { D.1869 } (nonlocal, escaped)
_5 = MEM[(const struct .omp_data_t.2D.1887 &).omp_data_i_4(D) clique 1 base
1].aD.1893;
# .MEM_6 = VDEF <.MEM_2>
*_5[i_1] = i_1;
# VUSE <.MEM_6>
# PT = nonlocal unit-escaped { D.1870 } (nonlocal, escaped)
_7 = MEM[(const struct .omp_data_t.2D.1887 &).omp_data_i_4(D) clique 1 base
1].bD.1891;
# .MEM_8 = VDEF <.MEM_6>
*_7[i_1] = i_1;
i_9 = i_1 + 1;
goto ;
...
If I remove the parallel region, I get this instead (so no more 'nonlocal
unit-escaped'), and parallelization succeeds:
...
# PT = { D.1869 } (nonlocal, escaped)
...
# PT = { D.1870 } (nonlocal, escaped)
...
The same happens if I instead remove the data enter/exit bits.
My first suspicion was that the oacc internal fns were missing certain
annotations that should help ipa-tpa. But the fact that the failure doesn't
seem to be tied to either the parallel construct, or the data enter/exit
construct makes me suspect that I'm running into some ipa-pta limitation.
[Bug tree-optimization/70137] internal compiler error: in add_phi_arg_for_new_expr, at graphite-isl-ast-to-gimple.c:2331
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70137 Richard Biener changed: What|Removed |Added Target||aarch64* --- Comment #1 from Richard Biener --- Works on x86_64-linux it seems.
[Bug tree-optimization/70154] [openacc] failing alias analysis in oacc kernels region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70154 --- Comment #1 from vries at gcc dot gnu.org --- Created attachment 37909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37909&action=edit pta1 dump file, using details-vops
[Bug tree-optimization/70128] Linux kernel div patching optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70128 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-03-09 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #12 from Richard Biener --- Mine. I'll see if I can sensibly "fix" points-to. It doesn't even preserve function-decls right now as they are not needed (as in, they can't be read from / written to).
[Bug tree-optimization/70144] [4.9/5/6 Regression] g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70144 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/70141] [6 Regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 Richard Biener changed: What|Removed |Added Summary|[6.0 regression] template |[6 Regression] template |parameter not deducible in |parameter not deducible in |partial specialization of |partial specialization of |template inside template|template inside template --- Comment #16 from Richard Biener --- Maybe sth for -fpermissive
[Bug tree-optimization/70094] Missed optimization when passing a constant struct argument by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70094 --- Comment #4 from Richard Biener --- (In reply to Eric Botcazou from comment #3) > > Confirmed. This is quite hard for us as GIMPLE doesn't allow arbitrary > > constant literals as function arguments and at RTL we can't remove the > > stack > > local anymore. > > RTL DSE theoretically has the machinery to do it though. Does your remark > hint at a specific issue? But RTL DSE cannot get rid of the stack space allocated for 'foo f', no?
[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-09 Known to work||4.9.3 Target Milestone|--- |5.4 Summary|[5 Regression] |[5/6 Regression] |-fno-ellide-constructor |-fno-ellide-constructor |makes static std::regex to |makes static std::regex to |throw |throw Ever confirmed|0 |1 Known to fail||5.3.0, 6.0 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|bernds at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- Mine. There's another bug about the FP ops thing I think.
[Bug c++/70153] [6 Regression] ICE on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70153 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |6.0
[Bug tree-optimization/70152] [4.9/5/6 Regression] gcc ICE at -O3 and above on valid code on x86_64-linux-gnu in "replace_uses_by"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70152 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/70148] Feature request: allow overriding the SSP canary location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70148 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Severity|normal |enhancement
[Bug tree-optimization/70128] Linux kernel div patching optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70128 --- Comment #13 from Richard Biener --- Created attachment 37910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37910&action=edit patch I am testing the attached. Btw, a workaround is -fno-tree-pta.
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 --- Comment #12 from Richard Biener --- Author: rguenth Date: Wed Mar 9 14:01:16 2016 New Revision: 234084 URL: https://gcc.gnu.org/viewcvs?rev=234084&root=gcc&view=rev Log: 2016-03-09 Richard Biener c-family/ PR c/70143 * c-common.c (strict_aliasing_warning): Add back alias_sets_conflict_p check. * gcc.dg/Wstrict-aliasing-bogus-upcast.c: New testcase. * gcc.dg/Wstrict-aliasing-struct-with-char-member.c: Likewise. * gcc.dg/Wstrict-aliasing-struct-member.c: Remove again. Added: trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-bogus-upcast.c trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-struct-with-char-member.c Removed: trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-struct-member.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/70094] Missed optimization when passing a constant struct argument by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70094 Eric Botcazou changed: What|Removed |Added Component|tree-optimization |rtl-optimization Severity|normal |enhancement --- Comment #5 from Eric Botcazou --- > But RTL DSE cannot get rid of the stack space allocated for 'foo f', no? Yes, you're right, the stack space cannot be reclaimed after RTL expansion, but in a non-toy example it would be reused for something else. I'll give it a try at the RTL level since this looks a useful improvement on its own.
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #5 from Bill Schmidt --- We also verified that the vectorized version of the loop is never entered during the application, since the output array is never properly aligned. Other experiments also point to a linker issue. When compiling everything with -O1 except for the file containing this code, and that file at -O3, the problem disappears. Also as noted, the original code works fine with an older linker. It looks like a linker corner case that's sensitive to code or data positioning.
[Bug rtl-optimization/70094] Missed optimization when passing a constant struct argument by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70094 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org
[Bug target/70049] [6 Regression] Error: operand size mismatch for `vpextrw' (wrong assembly generated) with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70049 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Mar 9 14:10:58 2016 New Revision: 234085 URL: https://gcc.gnu.org/viewcvs?rev=234085&root=gcc&view=rev Log: PR target/70049 * config/i386/sse.md (*vec_extract): Use %0 instead of %k0 if the operand is "m". * gcc.target/i386/pr70049.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr70049.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138
--- Comment #10 from Richard Biener ---
So I have a simple patch, still undecided whether I should include
vect_nested_cycle (and thus use VECTORIZABLE_CYCLE_DEF) or not. It's simply
vect_double_reduction_def that is missing for this testcase (and adding that
is "obvious" - both vect_double_reduction_def and vect_reduction_def are the
"outer" reduction).
Index: tree-vect-loop-manip.c
===
--- tree-vect-loop-manip.c (revision 234025)
+++ tree-vect-loop-manip.c (working copy)
@@ -1692,7 +1687,7 @@ vect_update_ivs_after_vectorizer (loop_v
/* Skip reduction phis. */
stmt_info = vinfo_for_stmt (phi);
- if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def)
+ if (VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (stmt_info)))
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
I guess I'll go with just adding vect_double_reduction_def for now. Ah,
it only looks at the outer loop PHIs anyway so can never get
vect_nested_cycle.
[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
--- Comment #2 from Viktor Ostashevskyi ---
Exception occurs, because in:
regex_traits::lookup_classname(...):
{
...
static const pair __classnames[] =
{
{"d", ctype_base::digit},
{"w", {ctype_base::alnum, _RegexMask::_S_under}},
{"s", ctype_base::space},
{"alnum", ctype_base::alnum},
{"alpha", ctype_base::alpha},
{"blank", ctype_base::blank},
{"cntrl", ctype_base::cntrl},
{"digit", ctype_base::digit},
{"graph", ctype_base::graph},
{"lower", ctype_base::lower},
{"print", ctype_base::print},
{"punct", ctype_base::punct},
{"space", ctype_base::space},
{"upper", ctype_base::upper},
{"xdigit", ctype_base::xdigit},
};
...
}
array element for "w" class is initialized to {0, 0} with
-fno-ellide-constructors.
[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #13 from Richard Henderson ---
Created attachment 37911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37911&action=edit
aggressive patch
Consider something like this, whereby we allow (sfp + scale + const)
as an address all the way until register allocation. LRA already knows
how to decompose this address in order to make it become valid, so
for your bar example in #c11 we get
bar:
stp x29, x30, [sp, -80]!
add x29, sp, 0
str x19, [sp, 16]
mov w19, w0
add x0, x29, 32
bl g
add x0, x29, 48
bl g
add x0, x29, 64
bl g
add x0, x29, 32
ldrbw0, [x0, w19, sxtw]
bl f
add x0, x29, 48
ldrbw0, [x0, w19, sxtw]
bl f
add x0, x29, 64
ldrbw0, [x0, w19, sxtw]
bl f
ldr x19, [sp, 16]
ldp x29, x30, [sp], 80
ret
So, three more instructions than trunk, no extra saved registers
like with the proposed patch. The extra instructions are simply
a choice that LRA makes during decomposition. If we look at a
different example,
void baz(int i, int j, int k)
{
char A[10];
g(A);
h(A[i], A[j], A[k]);
}
wherein the offsets are the same but the scale differs,
add x0, x29, 48
ldrbw2, [x0, w21, sxtw]
ldrbw1, [x0, w20, sxtw]
ldrbw0, [x0, w19, sxtw]
bl h
where post-reload-cse unifies the three x29+48 insns.
Compare that to trunk, which produces
add x0, x29, 64
add x21, x0, x21, sxtw
add x20, x0, x20, sxtw
add x19, x0, x19, sxtw
ldrbw2, [x21, -16]
ldrbw1, [x20, -16]
ldrbw0, [x19, -16]
bl h
At some point an AArch64 maintainer is going to have to decide
what to do with this PR. If the answer is to defer all to gcc7,
then we should downgrade the priority to P4.
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138
--- Comment #11 from Richard Biener ---
Simpler testcase not requiring strided stores:
double u[33];
__attribute__((noinline, noclone)) static void
foo (int *x)
{
double c = 0.0;
int a, b;
for (a = 0; a < 33; a++)
{
for (b = 0; b < 33; b++)
c = c + u[a];
u[a] *= 2.0;
}
*x = c;
}
int
main ()
{
int d, e;
for (d = 0; d < 33; d++)
{
u[d] = (d + 2);
__asm__ volatile ("" : : : "memory");
}
foo (&e);
if (e != 33 * (2 + 34) / 2 * 33)
__builtin_abort ();
return 0;
}
fails to vectorize on the gcc-5-branch because it can't create an epilogue
there.
[Bug target/70146] missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146
--- Comment #1 from H.J. Lu ---
We do it for MacOS:
#if TARGET_MACHO
/* Output the Mach-O "canonical" pic base label name ("Lxx$pb") here.
This is what will be referenced by the Mach-O PIC subsystem. */
if (machopic_should_output_picbase_label () || !label)
ASM_OUTPUT_LABEL (asm_out_file, MACHOPIC_FUNCTION_BASE_NAME);
/* When we are restoring the pic base at the site of a nonlocal label,
and we decided to emit the pic base above, we will still output a
local label used for calculating the correction offset (even though
the offset will be 0 in that case). */
if (label)
targetm.asm_out.internal_label (asm_out_file, "L",
CODE_LABEL_NUMBER (label));
#endif
.text
.align 4,0x90
.globl _get_foo
_get_foo:
LFB0:
call___x86.get_pc_thunk.ax
L1$pb:
movlL_foo$non_lazy_ptr-L1$pb(%eax), %eax
ret
LFE0:
.section __TEXT,__textcoal_nt,coalesced,pure_instructions
We should do something similar for Linux.
[Bug target/70146] missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-09 Ever confirmed|0 |1
[Bug c++/70112] [lto] Segmentation fault in Libreoffice's program gengal.bin when build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70112
--- Comment #5 from Martin Liška ---
Hi.
I've just tried to build libreoffice:
commit abadeb7a4a76e8ea6ec449f3ea564abf8d52a231
Author: Maxim Monastirsky
Date: Sun Feb 28 16:30:58 2016 +0200
Unused defines
Change-Id: Idc31e498a7223e7827533b24ab26928e21660ff2
with latest GCC:
gcc --version
gcc (GCC) 6.0.0 20160308 (experimental)
Works fine for both -O2 and -O2 and -flto. Unfortunately, due to:
/home/marxin/Programming/libreoffice/sax/source/tools/converter.cxx: In
function ‘void sax::lcl_AppendTimezone(rtl::OUStringBuffer&, sal_Int16)’:
/home/marxin/Programming/libreoffice/sax/source/tools/converter.cxx:1271:47:
error: invalid operands of types ‘__gnu_cxx::__enable_if::__type
{aka double}’ and ‘int’ to binary ‘operator%’
const sal_Int32 nMinutes(abs(nOffset) % 60);
~^~~~
/home/marxin/Programming/libreoffice/sax/source/tools/converter.cxx: In
function ‘void sax::lcl_ConvertToUTC(sal_Int16&, sal_uInt16&, sal_uInt16&,
sal_uInt16&, sal_uInt16&, sal_Int16)’:
/home/marxin/Programming/libreoffice/sax/source/tools/converter.cxx:1442:55:
error: invalid operands of types ‘__gnu_cxx::__enable_if::__type
{aka double}’ and ‘int’ to binary ‘operator%’
sal_Int16 const nOffsetMinutes(abs(nSourceOffset) % 60);
I was unable to build 'libreoffice-5-0-5' branch. Execution of both binaries is
w/o any problem.
Martin
[Bug target/70052] ICE compiling _Decimal128 test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70052 --- Comment #2 from David Edelsohn --- Missing "j" constraint in pattern to generate 0.
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138
--- Comment #12 from Bernd Schmidt ---
I arrived at the same conclusion, and I was testing the following:
Index: gcc/tree-vect-loop-manip.c
===
--- gcc/tree-vect-loop-manip.c (revision 234025)
+++ gcc/tree-vect-loop-manip.c (working copy)
@@ -1692,7 +1692,8 @@ vect_update_ivs_after_vectorizer (loop_v
/* Skip reduction phis. */
stmt_info = vinfo_for_stmt (phi);
- if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def)
+ if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def
+ || STMT_VINFO_DEF_TYPE (stmt_info) == vect_double_reduction_def)
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
[Bug target/70123] [6 Regression] Miscompilation of cfitsio testcase on s390x-linux starting with r222144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70123 --- Comment #5 from Jakub Jelinek --- (In reply to Bernd Schmidt from comment #4) > Created attachment 37906 [details] > Candidate patch > > Jakub, if you have a machine to test this on, can you try this patch? It's > probably not the full patch I'll submit, but it should cure this particular > issue. Fix verified both on the #c0 testcase (please remember that __builtin_strcat needs to be changed to __builtin_strcpy), and on the whole unreduced original testprog.c. I'm surprised that the RA can't figure out the needed value lives across the function call in the %r6 register (as well as %r10) already, but guess that can be improved incrementally, perhaps in GCC 7.
[Bug c/70143] [6 Regression] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Richard Biener --- Fixed.
[Bug target/69493] Poor code generation for return of struct containing vectors on PPC64LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69493 --- Comment #2 from Segher Boessenkool --- This seems fixed on current trunk (dse1 removes the reload from mem)?
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Richard Biener --- Thus invalid.
[Bug c++/70153] [6 Regression] ICE on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70153
--- Comment #4 from Marek Polacek ---
Slightly cleaned up test case:
void
foo ()
{
unsigned long long int i = 0ULL;
unsigned long long int v;
v = 2ULL * ((1 + (unsigned long int) +1) * i);
}
Note the +1 - without the '+' this problem doesn't occur.
[Bug tree-optimization/67681] Missed vectorization: induction variable used after loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681 --- Comment #3 from alalaw01 at gcc dot gnu.org --- So in the not-vectorized case (-DFOO=1), we get for the inner loop: : # i_27 = PHI _8 = (long unsigned int) i_27; _9 = _8 * 4; _11 = data_10(D) + _9; _13 = *_11; _14 = _13 + j_23; *_11 = _14; i_16 = i_27 + 1; if (i_16 <= max_24) goto ; else goto ; : goto ; : # i_32 = PHI the loop exit phi, i_32=PHI, makes i_16=i_27+1 relevant (vec_stmt_relevant_p: used out of loop.), so we go through that on the worklist and then i_27=PHI, marking the phi as STMT_VINFO_LIVE_P, and hence "not vectorized: value used after loop". Kind of as expected, FORNOW. In the -DFOO=0 case, a bunch of loop peeling, header-copying, and other transforms, end up with this input to vectorization: : //header of inner loop # i_2 = PHI _8 = (long unsigned int) i_2; _9 = _8 * 4; _11 = data_10(D) + _9; _12 = *_11; _13 = _12 + j_26; *_11 = _13; i_15 = i_2 + 1; if (max_7 >= i_15) goto ; else goto ; : goto ; : //bb 5 is only predecessor _19 = (unsigned int) i_25; _18 = (unsigned int) max_7; _17 = (unsigned int) i_25; _5 = _18 - _17; _4 = _5 + _19; _3 = _4 + 1; i_21 = (int) _3; : # i_23 = PHI //tests outer loop note bb7 use i_25, not i_2; so neither i_15 nor i_2 escape the loop, and we don't have the problem from above. (Yes bb7 is taking i_25 away from max_7 and then adding it back on again, before adding 1, to give the value of i after the inner loop.) This arrangement of multiple i's live at the same time, is not present in 107t.ch2. 130t.loopinit introduces i_21, computed by an exit phi on leaving the inner loop. 135t.sccp then changes this to the max_7-i_25+i_25 sequence which removes the dependency on i_15 and allows vectorization.
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Richard Biener --- Fixed.
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138 --- Comment #14 from Richard Biener --- Author: rguenth Date: Wed Mar 9 16:41:19 2016 New Revision: 234086 URL: https://gcc.gnu.org/viewcvs?rev=234086&root=gcc&view=rev Log: 2016-03-09 Richard Biener Jakub Jelinek PR tree-optimization/70138 * tree-vect-loop-manip.c (vect_update_ivs_after_vectorizer): Also skip vect_double_reduction_def. * gcc.dg/vect/pr70138-1.c: New testcase. * gcc.dg/vect/pr70138-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/vect/pr70138-1.c trunk/gcc/testsuite/gcc.dg/vect/pr70138-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127 --- Comment #7 from Jakub Jelinek --- Created attachment 37912 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37912&action=edit gcc6-pr70127-typecheck.patch OEP_NO_TYPECHECK patch.
[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127 --- Comment #8 from Jakub Jelinek --- Created attachment 37913 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37913&action=edit gcc6-pr70127-hack.patch To gather some statistics on what the various changes to operand_equal_p affect or might affect, I've bootstrapped/regtested x86_64-linux and i686-linux trunk with the gcc6-pr70127-typecheck.patch and gcc6-pr70127-hack.patch, which should for every non-recursive opernad_equal_p call it 3 times - once the way current trunk does, once the way gcc6-pr70127-typecheck.patch would and once the way 5.x did, and reported any differences in what has been returned. That of course doesn't mean the different operand_equal_p actually affected some optimization, or changed generated code. The i686-linux bootstrap already finished, x86_64-linux is still regtesting, so the current results are partial, but I see 3458 lines with trunk 1 new 0 5.x 1 136 lines with trunk 1 new 0 5.x 0 and no others. Thus, the OEP_NO_TYPECHECK patch will affect more than 25 times what reversion of r229494 would affect. Therefore, I think the reversion is safest thing at this point, and we should reconsider after branching. If there is interest I can also attach the detailed log (with filenames/function names).
[Bug target/70155] New: Use SSE for TImode load/store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70155
Bug ID: 70155
Summary: Use SSE for TImode load/store
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com, ysrumyan at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-mic-2 int128]$ cat x.i
extern __int128 a, b;
struct foo
{
__int128 i;
}__attribute__ ((packed));
extern struct foo x, y;
void
foo (void)
{
a = b;
x = y;
}
[hjl@gnu-mic-2 int128]$ gcc -S -O2 x.i
[hjl@gnu-mic-2 int128]$ cat x.s
.file "x.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movqb(%rip), %rax
movqb+8(%rip), %rdx
movq%rax, a(%rip)
movq%rdx, a+8(%rip)
movqy(%rip), %rax
movqy+8(%rip), %rdx
movq%rax, x(%rip)
movq%rdx, x+8(%rip)
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident "GCC: (GNU) 5.3.1 20160212 (Red Hat 5.3.1-4)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-mic-2 int128]$
We could generate
foo:
.LFB0:
.cfi_startproc
movdqa b(%rip), %xmm0
movaps %xmm0, a(%rip)
movdqu y(%rip), %xmm0
movups %xmm0, x(%rip)
ret
.cfi_endproc
.LFE0:
[Bug c++/64989] constant-initialization of self-referencing array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64989
Martin Sebor changed:
What|Removed |Added
Keywords|wrong-code |rejects-valid
Last reconfirmed|2015-03-18 00:00:00 |2016-3-9
CC||msebor at gcc dot gnu.org
Known to fail||4.9.3, 5.3.0, 6.0
--- Comment #3 from Martin Sebor ---
The test case is still rejected in 6.0 (thus changing the wrong-code keyword to
rejects-valid). The problem seems to be using the this pointer since in test
case below, the first case is accepted.
$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xg++
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic z.c
struct A
{
const void *p;
constexpr A (const void *p): p (p) { }
};
constexpr A a[2] = { a, a + 1 };
static_assert (a [1].p == a + 1, "#1");
struct B
{
const void *p;
constexpr B (): p (this) { }
};
constexpr B b[2];
static_assert (b [1].p == b + 1, "#2");
z.c:17:1: error: non-constant condition for static assertion
static_assert (b [1].p == b + 1, "#2");
^
z.c:17:1: error: the value of ‘b’ is not usable in a constant expression
z.c:16:13: note: ‘b’ used in its own initializer
constexpr B b[2];
^
[Bug rtl-optimization/69633] [6 Regression] Redundant move is generated after r228097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633 Bernd Schmidt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #6 from Bernd Schmidt --- Taking a closer look.
[Bug tree-optimization/67681] Missed vectorization: induction variable used after loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681 --- Comment #4 from alalaw01 at gcc dot gnu.org --- loopinit introduces the exit phi in much the same way for both -DFOO=0 and -DFOO=1, so the difference is in sccp. In the -DFOO=0 case, sccp does this (removing TODO_cleanup_cfg from pass_data_scev_cprop to make the diff easier, still vectorizes): ;; Function addlog2 (addlog2, funcdef_no=0, decl_uid=2749, cgraph_uid=0, symbol_order=0) + +final value replacement: + i_21 = PHI + with + i_21 = (int) _3; + ...[snip]... : - # i_21 = PHI + _19 = (unsigned int) i_25; + _18 = (unsigned int) max_7; + _17 = (unsigned int) i_25; + _5 = _18 - _17; + _4 = _5 + _19; + _3 = _4 + 1; + i_21 = (int) _3; In the -DFOO=1 case, sccp doesn't do anything; and adding -fno-tree-scev-cprop prevents vectorization of the -DFOO=0 case.
[Bug c++/70156] New: incorrect "incomplete type" error initializing a static const data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70156
Bug ID: 70156
Summary: incorrect "incomplete type" error initializing a
static const data member
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The two definitions of the data members of class C in the program below are
rejected as a required. However, the text of only the second diagnostic is
correct. The text of the first diagnostic is not since the type A<0> is
complete at the point it's used.
$ cat v.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc++ v.c
template struct A { int i; };
struct B { int i; };
struct C {
static const A<0> a = { 0 };
static const B b = { 1 };
};
v.c:4:31: error: in-class initialization of static data member ‘const A<0>
C::a’ of incomplete type
static const A<0> a = { 0 };
^
v.c:5:28: error: ‘constexpr’ needed for in-class initialization of static data
member ‘const B C::b’ of non-integral type [-fpermissive]
static const B b = { 1 };
^
[Bug target/69493] Poor code generation for return of struct containing vectors on PPC64LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69493 --- Comment #3 from Bill Schmidt --- That's interesting. We have some other examples of similar issues we should check as well before closing this. I'll take a look in a bit.
[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
--- Comment #10 from alalaw01 at gcc dot gnu.org ---
Hmmm, so this fixes the ICE, generating:
SR.5_12 = MEM[(struct S0[2] *)&*.LC0].f0;
MEM[(struct S0[2] *)&*.LC0].f0 = SR.5_12;
d = *.LC0;
d$3$f0_14 = MEM[(struct S0[2] *)&*.LC0 + 3B].f0;
d$0$f0_7 = SR.5_12;
e$f0_9 = d$3$f0_14;
_3 = (int) d$0$f0_7;
c = _3;
_5 = (int) e$f0_9;
__builtin_printf ("%x\n", _5);
d ={v} {CLOBBER};
return 0;
which in -fdump-tree-optimized (at -O1) looks like:
SR.5_12 = MEM[(struct S0[2] *)&*.LC0].f0;
d$3$f0_14 = MEM[(struct S0[2] *)&*.LC0 + 3B].f0;
_3 = (int) SR.5_12;
c = _3;
_5 = (int) d$3$f0_14;
__builtin_printf ("%x\n", _5);
return 0;
which is much saner. But I don't really understand why the PARM_DECL case that
I'm adding to here is that way (since r147980 "New implementation of SRA" in
2009, https://gcc.gnu.org/ml/gcc-patches/2009-04/msg02218.html)...
Bootstrapped+regtest on AArch64 (c,c++) and ARM (c,c++,ada), no regressions.
(Constants don't get pushed into the pool on x86.)
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index
72157edd02e3235e57b786bbf460c94b0c52b2c5..24eac6ae7c4dcd41358b1a020047076afe1a8106
100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2427,7 +2427,8 @@ analyze_access_subtree (struct access *root, struct
access *parent,
if (!hole || root->grp_total_scalarization)
root->grp_covered = 1;
- else if (root->grp_write || TREE_CODE (root->base) == PARM_DECL)
+ else if (root->grp_write || TREE_CODE (root->base) == PARM_DECL
+ || constant_decl_p (root->base))
root->grp_unscalarized_data = 1; /* not covered and written to */
return sth_created;
}
[Bug target/70157] New: Mismatched __float128 load/store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70157
Bug ID: 70157
Summary: Mismatched __float128 load/store
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-6 pr70155]$ cat y.i
extern __float128 a, b;
struct foo
{
__float128 i;
}__attribute__ ((packed));
extern struct foo x, y;
void
foo (void)
{
a = b;
x = y;
}
[hjl@gnu-6 pr70155]$ gcc -S y.i -O2
[hjl@gnu-6 pr70155]$ cat y.s
.file "y.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movdqa b(%rip), %xmm0
movaps %xmm0, a(%rip)
movdqu y(%rip), %xmm0
movups %xmm0, x(%rip)
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident "GCC: (GNU) 5.3.1 20160212 (Red Hat 5.3.1-4)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr70155]$
Shouldn't only one of movdqa/movaps (movdqu/movups) used for __float128
load and store?
[Bug target/70146] missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146 Richard PALO changed: What|Removed |Added CC||richard at netbsd dot org --- Comment #2 from Richard PALO --- I'm curious if something like this could help certain similar situations encountered in SunOS as well...
[Bug tree-optimization/67681] Missed vectorization: induction variable used after loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681 --- Comment #5 from alalaw01 at gcc dot gnu.org --- In the -DFOO=0 case, we have peeled an extra copy of the inner loop condition, i <= max_7, above the loop. scalar evolution (final_value_replacement_loop) works, because it sees the inner loop goes round niter = (unsigned int) max_7 - (unsigned int) i_25 iterations, and compute_overall_effect_of_inner_loop gives us (int) (((unsigned int) i_25 + ((unsigned int) max_7 - (unsigned int) i_25)) + 1) which is not expression_expensive_p, so we do it. Hence the add/subtract above. When -DFOO=1, we have not done that peeling, so niter = i_22 <= max_24 ? (unsigned int) max_24 - (unsigned int) i_22 : 0, and compute_overall_effect_of_inner_loop gives us (i_22 + 1) + (i_22 <= max_24 ? (int) ((unsigned int) max_24 - (unsigned int) i_22) : 0) which is expression_expensive_p, so we don't do the final value replacement.
[Bug fortran/70158] New: ICE in small Fortran program with OMP and C_PTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70158 Bug ID: 70158 Summary: ICE in small Fortran program with OMP and C_PTR Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: christophe.cous...@meso-star.com Target Milestone: --- Created attachment 37914 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37914&action=edit source file used ICE with the following command line and version. $ gfortran -fopenmp -std=f2008 -ffree-form bug.f bug.f: In function ‘compute’: bug.f:7:0: internal compiler error: Erreur de segmentation !$OMP PARALLEL PRIVATE(RNG) ^ Please submit a full bug report, with preprocessed source if appropriate. $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
[Bug fortran/70158] ICE in small Fortran program with OMP and C_PTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70158 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-03-09 Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- Can you upgrade your version of gfortran and test to see if the code compiles for you. For me, the code compiles with 4.9.4, 5.3.1, and 6.0.0
[Bug fortran/70158] ICE in small Fortran program with OMP and C_PTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70158 --- Comment #2 from Dominique d'Humieres --- > Can you upgrade your version of gfortran and test > to see if the code compiles for you. For me, the > code compiles with 4.9.4, 5.3.1, and 6.0.0 For me too, but I see the ICE with 4.8.5.
[Bug c/68473] ICE: in contains_point, at diagnostic-show-locus.c:340 after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473 --- Comment #14 from David Malcolm --- Author: dmalcolm Date: Wed Mar 9 18:14:43 2016 New Revision: 234087 URL: https://gcc.gnu.org/viewcvs?rev=234087&root=gcc&view=rev Log: PR c++/70105: Defer location expansion until diagnostic_show_locus gcc/ChangeLog: PR c/68473 PR c++/70105 * diagnostic-show-locus.c (layout_range::layout_range): Replace location_range param with three const expanded_locations * and a bool. (layout::layout): Replace call to rich_location::lazily_expand_location with get_expanded_location. Extract the range and perform location expansion here, passing the results to the layout_range ctor. * diagnostic.c (source_range::debug): Delete. * diagnostic.h (diagnostic_expand_location): Reimplement in terms of rich_location::get_expanded_location. * gcc-rich-location.c (get_range_for_expr): Delete. (gcc_rich_location::add_expr): Reimplement to avoid the rich_location::add_range overload that took a location_range, passing a location_t instead. gcc/testsuite/ChangeLog: PR c/68473 PR c++/70105 * gcc.dg/plugin/diagnostic_plugin_show_trees.c (show_tree): Drop range information from call to inform_at_rich_loc. * gcc.dg/plugin/diagnostic_plugin_test_show_locus.c (add_range): New. (test_show_locus): Replace calls to rich_location::add_range with calls to add_range. Rewrite the tests that used the now-defunct rich_location ctor taking a source_range. Simplify other tests by replacing calls to COMBINE_LOCATION_DATA with calls to make_location. libcpp/ChangeLog: PR c/68473 PR c++/70105 * include/line-map.h (source_range::debug): Delete. (struct location_range): Update comment. Replace expanded_location fields "m_start", "m_finish", and "m_caret" with a source_location field: "m_loc". (class rich_location): Reword comment. (rich_location::get_loc): Reimplement in terms of a new overloaded variant which takes an unsigned int. (rich_location::get_loc_addr): Delete. (rich_location::add_range): Drop params "start" and "finish" in favor of param "loc". Drop overloaded variants taking a source_range or location_range *. (rich_location::lazily_expand_location): Delete in favor of... (rich_location::get_expanded_location): New decl. (rich_location::m_loc): Delete field. (rich_location::m_column_override): New field. * line-map.c (rich_location::rich_location): Drop name of line_maps * param. Update initializations for deletion of field "m_loc" and addition of field "m_column_override". Reimplement body as a call to add_range. Delete overloaded variant taking a source_range. (rich_location::get_loc): New function. (rich_location::lazily_expand_location): Delete in favor of... (rich_location::get_expanded_location): New function. (rich_location::override_column): Reimplement. (rich_location::add_range): Drop params "start" and "finish" in favor of param "loc". Eliminate location expansion in favor of simply storing loc. Drop overloaded variants taking a source_range or location_range *. (rich_location::set_range): Eliminate location expansion. Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-show-locus.c trunk/gcc/diagnostic.c trunk/gcc/diagnostic.h trunk/gcc/gcc-rich-location.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_show_trees.c trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c trunk/libcpp/ChangeLog trunk/libcpp/include/line-map.h trunk/libcpp/line-map.c
[Bug c++/70105] [6 regression] giant warning when building gcc-5 with gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70105 --- Comment #3 from David Malcolm --- Author: dmalcolm Date: Wed Mar 9 18:14:43 2016 New Revision: 234087 URL: https://gcc.gnu.org/viewcvs?rev=234087&root=gcc&view=rev Log: PR c++/70105: Defer location expansion until diagnostic_show_locus gcc/ChangeLog: PR c/68473 PR c++/70105 * diagnostic-show-locus.c (layout_range::layout_range): Replace location_range param with three const expanded_locations * and a bool. (layout::layout): Replace call to rich_location::lazily_expand_location with get_expanded_location. Extract the range and perform location expansion here, passing the results to the layout_range ctor. * diagnostic.c (source_range::debug): Delete. * diagnostic.h (diagnostic_expand_location): Reimplement in terms of rich_location::get_expanded_location. * gcc-rich-location.c (get_range_for_expr): Delete. (gcc_rich_location::add_expr): Reimplement to avoid the rich_location::add_range overload that took a location_range, passing a location_t instead. gcc/testsuite/ChangeLog: PR c/68473 PR c++/70105 * gcc.dg/plugin/diagnostic_plugin_show_trees.c (show_tree): Drop range information from call to inform_at_rich_loc. * gcc.dg/plugin/diagnostic_plugin_test_show_locus.c (add_range): New. (test_show_locus): Replace calls to rich_location::add_range with calls to add_range. Rewrite the tests that used the now-defunct rich_location ctor taking a source_range. Simplify other tests by replacing calls to COMBINE_LOCATION_DATA with calls to make_location. libcpp/ChangeLog: PR c/68473 PR c++/70105 * include/line-map.h (source_range::debug): Delete. (struct location_range): Update comment. Replace expanded_location fields "m_start", "m_finish", and "m_caret" with a source_location field: "m_loc". (class rich_location): Reword comment. (rich_location::get_loc): Reimplement in terms of a new overloaded variant which takes an unsigned int. (rich_location::get_loc_addr): Delete. (rich_location::add_range): Drop params "start" and "finish" in favor of param "loc". Drop overloaded variants taking a source_range or location_range *. (rich_location::lazily_expand_location): Delete in favor of... (rich_location::get_expanded_location): New decl. (rich_location::m_loc): Delete field. (rich_location::m_column_override): New field. * line-map.c (rich_location::rich_location): Drop name of line_maps * param. Update initializations for deletion of field "m_loc" and addition of field "m_column_override". Reimplement body as a call to add_range. Delete overloaded variant taking a source_range. (rich_location::get_loc): New function. (rich_location::lazily_expand_location): Delete in favor of... (rich_location::get_expanded_location): New function. (rich_location::override_column): Reimplement. (rich_location::add_range): Drop params "start" and "finish" in favor of param "loc". Eliminate location expansion in favor of simply storing loc. Drop overloaded variants taking a source_range or location_range *. (rich_location::set_range): Eliminate location expansion. Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-show-locus.c trunk/gcc/diagnostic.c trunk/gcc/diagnostic.h trunk/gcc/gcc-rich-location.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_show_trees.c trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c trunk/libcpp/ChangeLog trunk/libcpp/include/line-map.h trunk/libcpp/line-map.c
[Bug c++/70105] [6 regression] giant warning when building gcc-5 with gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70105 --- Comment #4 from David Malcolm --- Author: dmalcolm Date: Wed Mar 9 18:23:27 2016 New Revision: 234088 URL: https://gcc.gnu.org/viewcvs?rev=234088&root=gcc&view=rev Log: PR c++/70105: prevent nonsensical underline spew for macro expansions diagnostic_show_locus can sometimes do the wrong thing when handling expressions built up from macros. PR c++/70105 (currently marked as a P3 regression) has an example of a diagnostic where over 500 lines of irrelevant source are printed, and underlined, giving >1000 lines of useless spew to stderr. This patch adds extra sanitization to diagnostic-show-locus.c, so that we only attempt to print underlines and secondary locations if such locations are "sufficiently sane" relative to the primary location of a diagnostic. This "sufficiently sane" condition is implemented by a new helper function compatible_locations_p, which requires such locations to have the same macro expansion hierarchy as the primary location, using linemap_macro_map_loc_unwind_toward_spelling, effectively mimicing the expansion performed by LRK_SPELLING_LOCATION. This may be too strong a condition, but it effectively fixes PR c++/70105, without removing any underlines in my testing. Successfully bootstrapped®rtested in combination with the previous patch on x86_64-pc-linux-gnu; adds 15 new PASS results to g++.sum and 4 new PASS results to gcc.sum. gcc/ChangeLog: PR c/68473 PR c++/70105 * diagnostic-show-locus.c (compatible_locations_p): New function. (layout::layout): Sanitize ranges using compatible_locations_p. gcc/testsuite/ChangeLog: PR c/68473 PR c++/70105 * g++.dg/diagnostic/pr70105.C: New test. * gcc.dg/plugin/diagnostic-test-expressions-1.c (foo): New decl. (test_multiple_ordinary_maps): New test function. libcpp/ChangeLog: PR c/68473 PR c++/70105 * line-map.c (linemap_macro_map_loc_unwind_toward_spelling): Move decl... * include/line-map.h (linemap_macro_map_loc_unwind_toward_spelling): ...here, converting from static to extern. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr70105.C Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-show-locus.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-expressions-1.c trunk/libcpp/ChangeLog trunk/libcpp/include/line-map.h trunk/libcpp/line-map.c
[Bug c/68473] ICE: in contains_point, at diagnostic-show-locus.c:340 after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473 --- Comment #15 from David Malcolm --- Author: dmalcolm Date: Wed Mar 9 18:23:27 2016 New Revision: 234088 URL: https://gcc.gnu.org/viewcvs?rev=234088&root=gcc&view=rev Log: PR c++/70105: prevent nonsensical underline spew for macro expansions diagnostic_show_locus can sometimes do the wrong thing when handling expressions built up from macros. PR c++/70105 (currently marked as a P3 regression) has an example of a diagnostic where over 500 lines of irrelevant source are printed, and underlined, giving >1000 lines of useless spew to stderr. This patch adds extra sanitization to diagnostic-show-locus.c, so that we only attempt to print underlines and secondary locations if such locations are "sufficiently sane" relative to the primary location of a diagnostic. This "sufficiently sane" condition is implemented by a new helper function compatible_locations_p, which requires such locations to have the same macro expansion hierarchy as the primary location, using linemap_macro_map_loc_unwind_toward_spelling, effectively mimicing the expansion performed by LRK_SPELLING_LOCATION. This may be too strong a condition, but it effectively fixes PR c++/70105, without removing any underlines in my testing. Successfully bootstrapped®rtested in combination with the previous patch on x86_64-pc-linux-gnu; adds 15 new PASS results to g++.sum and 4 new PASS results to gcc.sum. gcc/ChangeLog: PR c/68473 PR c++/70105 * diagnostic-show-locus.c (compatible_locations_p): New function. (layout::layout): Sanitize ranges using compatible_locations_p. gcc/testsuite/ChangeLog: PR c/68473 PR c++/70105 * g++.dg/diagnostic/pr70105.C: New test. * gcc.dg/plugin/diagnostic-test-expressions-1.c (foo): New decl. (test_multiple_ordinary_maps): New test function. libcpp/ChangeLog: PR c/68473 PR c++/70105 * line-map.c (linemap_macro_map_loc_unwind_toward_spelling): Move decl... * include/line-map.h (linemap_macro_map_loc_unwind_toward_spelling): ...here, converting from static to extern. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr70105.C Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-show-locus.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-expressions-1.c trunk/libcpp/ChangeLog trunk/libcpp/include/line-map.h trunk/libcpp/line-map.c
[Bug c++/65579] [C++11] gcc requires definition of a static constexpr member even though it is not odr-used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65579
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Known to fail||4.9.3, 5.3.0, 6.0
--- Comment #1 from Martin Sebor ---
Re-confirmed with today's top of trunk (6.0) and all prior supported versions
that implement constexpr. See below.
The difference between the template and non-template case is the readonly bit
that's set on the 's' field when S is an ordinary struct. The bit is clear
when S is a template. The bit gets set in the c_apply_type_quals_to_decl()
function in c-family/c-common.c called from the cp_apply_type_quals_to_decl()
function defined in cp/typeck.c. The latter function executes the following
condition just before calling c_apply_type_quals_to_decl(). COMPLETE_TYPE_P
(type) is false when S is a (specialization of a template), causing the
TYPE_QUAL_CONST to clear.
/* Avoid setting TREE_READONLY incorrectly. */
/* We used to check TYPE_NEEDS_CONSTRUCTING here, but now a constexpr
constructor can produce constant init, so rely on cp_finish_decl to
clear TREE_READONLY if the variable has non-constant init. */
/* If the type has (or might have) a mutable component, that component
might be modified. */
if (TYPE_HAS_MUTABLE_P (type) || !COMPLETE_TYPE_P (type))
type_quals &= ~TYPE_QUAL_CONST;
c_apply_type_quals_to_decl (type_quals, decl);
When S is made complete by this point (e.g., by causing S to be
instantiated, say by declaring an object of the type), the bit stays set and
the test program links.
The c_apply_type_quals_to_decl() function the does the following:
if ((type_quals & TYPE_QUAL_CONST)
|| (type && TREE_CODE (type) == REFERENCE_TYPE))
/* We used to check TYPE_NEEDS_CONSTRUCTING here, but now a constexpr
constructor can produce constant init, so rely on cp_finish_decl to
clear TREE_READONLY if the variable has non-constant init. */
TREE_READONLY (decl) = 1;
The comments referencing constexpr suggest that TREE_READONLY should perhaps be
set here and then cleared in cp_finish_decl.
$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc++ z.c
template
struct S {
int i;
};
struct T {
static constexpr S s = { 1 };
};
int main()
{
return T::s.i;
}
/tmp/ccqP3dAP.o: In function `main':
z.c:(.text+0x6): undefined reference to `T::s'
collect2: error: ld returned 1 exit status
[Bug c++/70105] [6 regression] giant warning when building gcc-5 with gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70105 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- Should be fixed by r234087+r234088: r234087: "[PATCH 1/2] PR c++/70105: Defer location expansion until diagnostic_show_locus" https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00583.html r234088: "[PATCH 2/2] PR c++/70105: prevent nonsensical underline spew for macro expansions" https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00585.html Additionally verified by rebuildling tree-complex.c, which now emits just: *** In file included from ./tm.h:27:0, from ../../src/gcc/tree-complex.c:23: ../../src/gcc/config/elfos.h:102:21: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\ ^ ../../src/gcc/config/elfos.h:170:24: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \ ^ In file included from ./tm.h:48:0, from ../../src/gcc/tree-complex.c:23: ../../src/gcc/defaults.h:126:24: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \ ^ In file included from ../../src/gcc/tree-complex.c:57:0: ../../src/gcc/tree-complex.c: In function ‘tree_node* create_one_component_var(tree, tree, const char*, const char*, tree_code)’: ../../src/gcc/../include/libiberty.h:184:25: warning: operation on ‘libiberty_concat_ptr’ may be undefined [-Wsequence-point] (libiberty_concat_ptr = (char *) alloca (concat_length ACONCAT_PARAMS + 1), \ ^ ../../src/gcc/stringpool.h:39:50: note: in definition of macro ‘get_identifier’ ? get_identifier_with_length ((str), strlen (str)) \ ^~~ ../../src/gcc/tree-complex.c:473:39: note: in expansion of macro ‘ACONCAT’ DECL_NAME (r) = get_identifier (ACONCAT ((name, suffix, NULL))); ^~~ *** Marking as resolved.
[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058 --- Comment #13 from Jeffrey A. Law --- Stabilizing the sort is just one piece in the problem. SSA_NAME_VERSIONs are also used as partition numbers. That doesn't seem to impact code generation (so far), but it does make dump comparisons bloody difficult to really analyze. That's what really got me thinking about this problem -- the fact that changes in the version #s not only affect code generation, but they make it orders of magnitude harder to evaluate whether or not stabilizing the sort is all that's needed to address the performance concerns due to gratutious changes in the dump files. The result of those ponderings was the idea that changing SSA_NAME_VERSIONs should have zero impact on the code we generate. We should be able to hand out names in a totally arbitrary order and ultimately get the same assembly code. Reality is somewhat different. Consider that in various places we canonicalize expression operands based on SSA_NAME_VERSIONs. Those can and will get different code based on SSA_NAME_VERSIONs in use. ie if (a_1 == b_2) if (a_2 == b_1) Should generate the same assembly code, but won't because the second will get canonicalized into if (b_1 == a_2) And when we convert that to RTL, it'll generate different code than the original a_1 == b_2 version. Similar situations occur due to canonicalization that happens during tree-ssa-reassoc and almost certainly other places. It's pervasive enough that the goal of "no change in assembly output due to SSA_NAME_VERSION changes" may not be attainable in the immediate future. Coming back to 64058 and 68654, it's not clear yet if just stabilizing the sort is sufficient. I'm still evaluating that. FWIW, I've got a variant that just stabilizes the sort with just an index we record as we find a potential coalescing pair. That's pretty trivial. I started down another path where I added a level of indirection between the SSA_NAME_VERSION and the associated partition maps. My worry with the latter is interactions with tree-ssa-live.c.
[Bug target/70157] Mismatched __float128 load/store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70157 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-09 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It is due to TARGET_SSE_TYPELESS_STORES.
[Bug target/70157] Mismatched __float128 load/store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70157 --- Comment #2 from Uroš Bizjak --- (In reply to H.J. Lu from comment #1) > It is due to TARGET_SSE_TYPELESS_STORES. This is by design, movaps/movups is one byte shorter than movdqa/movdqu.
[Bug target/70155] Use SSE for TImode load/store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70155 --- Comment #1 from Uroš Bizjak --- This can be tweaked in processor_cost table. However, is SSE move really faster? Cost tables doesn't say so.
[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Wed Mar 9 20:05:40 2016 New Revision: 234090 URL: https://gcc.gnu.org/viewcvs?rev=234090&root=gcc&view=rev Log: PR tree-optimization/70127 * fold-const.c (operand_equal_p): Revert the 2015-10-28 change. * gcc.c-torture/execute/pr70127.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr70127.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug target/70086] [6 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2202 (insn does not satisfy its constraints) with -mavx512vl -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70086 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Mar 9 20:06:59 2016 New Revision: 234091 URL: https://gcc.gnu.org/viewcvs?rev=234091&root=gcc&view=rev Log: PR target/70086 * config/i386/i386.md (truncdfsf2 splitter): Use gen_vec_concatv2df instead of gen_sse2_loadlpd. * config/i386/sse.md (*vec_concatv2df): Rename to... (vec_concatv2df): ... this. * gcc.target/i386/pr70086-1.c: New test. * gcc.target/i386/pr70086-2.c: New test. * gcc.target/i386/pr70086-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr70086-1.c trunk/gcc/testsuite/gcc.target/i386/pr70086-2.c trunk/gcc/testsuite/gcc.target/i386/pr70086-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/70152] [4.9/5/6 Regression] gcc ICE at -O3 and above on valid code on x86_64-linux-gnu in "replace_uses_by"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70152 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Mar 9 20:12:19 2016 New Revision: 234092 URL: https://gcc.gnu.org/viewcvs?rev=234092&root=gcc&view=rev Log: PR tree-optimization/70152 * tree-sra.c (replace_removed_params_ssa_names): Copy over SSA_NAME_OCCURS_IN_ABNORMAL_PHI from old_name to new_name. * gcc.dg/pr70152.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr70152.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug target/70086] [6 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2202 (insn does not satisfy its constraints) with -mavx512vl -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70086 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
