[Bug c++/72825] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected array_type, have error_mark in array_ref_low_bound, at tree.c:13013)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72825 --- Comment #3 from Paolo Carlini --- See notes on c++/84632 too.
[Bug c++/84632] [8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p, at cp/constexpr.c:1778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84632 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Paolo Carlini --- Fixed. c++/72825 will track improvements to maybe_deduce_size_from_array_init
[Bug c++/84632] [8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p, at cp/constexpr.c:1778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84632 --- Comment #8 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Mar 27 06:52:04 2018 New Revision: 258870 URL: https://gcc.gnu.org/viewcvs?rev=258870&root=gcc&view=rev Log: /cp 2018-03-27 Paolo Carlini Jason Merrill PR c++/84632 * init.c (build_aggr_init): When initializing from array, reject anything but CONSTRUCTORs and TARGET_EXPRs. (build_vec_init): Handle separately ARRAY_TYPEs. /testsuite 2018-03-27 Paolo Carlini Jason Merrill PR c++/84632 * g++.dg/init/array49.C: New. * g++.dg/torture/pr70499.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/init/array49.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr70499.C
[Bug c++/85071] The g++ delete the memory alloced by new operator before I manually delete it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85071 --- Comment #3 from wierton <141242068 at smail dot nju.edu.cn> --- (In reply to Jonathan Wakely from comment #2) > Both valgrind and AddressSanitizer would have found this bug, you should use > them. I feel so sorry to post this stupid code. I re-checked it using valgrind and re-checked the logic, and then found the problem as you mentioned. Thanks for your patient explanation.
[Bug testsuite/80546] [7/8 Regression] FAIL: gcc.target/powerpc/bool3-p[78].c scan-assembler-not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80546 --- Comment #11 from Peter Bergner --- (In reply to Peter Bergner from comment #10) > My bootstrap/regtesting of this patch is still running. Ok, the bootstrap and regtesting came back clean and both bool3-p[78].c tests cases now PASS.
[Bug rtl-optimization/84878] ICE: Segmentation fault (in add_cross_iteration_register_deps)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84878 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-03/msg01413.ht ||ml
[Bug testsuite/80546] [7/8 Regression] FAIL: gcc.target/powerpc/bool3-p[78].c scan-assembler-not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80546 --- Comment #10 from Peter Bergner --- Created attachment 43764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43764&action=edit Alternate patch for PR80546 Mike created the vsx_mov_* patterns, so I asked him why he disparaged the GPR moves. He said that reload (not LRA?) was attempting to use the GPR moves for vector types and that was causing some horrible code. I can understand that, but I don't understand why we should disparage them for the integer types (DImode and TImode), since they normally live in GPRs to begin with. With that in mind, I created the attached patch which seems to create better code for the ptr4 test case than current trunk without changing the other functions. Looking at the difference between the unpatched and patched bool3-p8.s files, I see: --- bool3-p8-old.s 2018-03-26 21:15:38.293963450 -0500 +++ bool3-p8-new.s 2018-03-26 21:16:27.514854332 -0500 @@ -134,13 +134,8 @@ # gpr reg 10 # 0 "" 2 #NO_APP - mtvsrd 0,10 - mtvsrd 1,11 - xxpermdi 12,0,1,0 - xxlnor 0,12,12 - mfvsrd 10,0 - xxpermdi 0,0,0,3 - mfvsrd 11,0 + not 10,10 + not 11,11 #APP # 76 "/home/bergner/gcc/gcc-fsf-mainline-pr84878/gcc/testsuite/gcc.target/powerpc/bool3.h" 1 # gpr reg 10 Mike, anyone, does this look reasonable? I'll mention that the costs for BASE_REGS/GENERAL_REGS for r122 are much more reasonable compared to what Jakub was seeing on Comment 3 with the unpatched compiler. My bootstrap/regtesting of this patch is still running. Mike, do we have a test case where this matters?
[Bug testsuite/80546] [7/8 Regression] FAIL: gcc.target/powerpc/bool3-p[78].c scan-assembler-not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80546 Peter Bergner changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #9 from Peter Bergner --- CCing Mike for his possible input.
[Bug rtl-optimization/85072] g++ -O1 consumes all memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85072
--- Comment #4 from Vladimir Makarov ---
(In reply to Richard Biener from comment #3)
> Doing a more "correct" patch like below shows that nearly all possible
> "starts" are covered:
>
> (gdb) p bitmap_count_bits(starts)
> $2 = 500039
> (gdb) p max_regno - lra_constraint_new_regno_start
> $4 = 505207
>
> so preserving semantics that way doesn't end up helping memory use :/
>
> Index: gcc/lra-assigns.c
> ===
> --- gcc/lra-assigns.c (revision 258678)
> +++ gcc/lra-assigns.c (working copy)
> @@ -429,12 +429,25 @@ init_live_reload_and_inheritance_pseudos
>for (p = 0; p < lra_live_max_point; p++)
> bitmap_initialize (&live_reload_and_inheritance_pseudos[p],
>&live_reload_and_inheritance_pseudos_bitmap_obstack);
> + bitmap starts = BITMAP_ALLOC (NULL);
> + for (i = lra_constraint_new_regno_start; i < max_regno; i++)
> +for (r = lra_reg_info[i].live_ranges; r != NULL; r = r->next)
> + bitmap_set_bit (starts, r->start);
>for (i = lra_constraint_new_regno_start; i < max_regno; i++)
> {
>for (r = lra_reg_info[i].live_ranges; r != NULL; r = r->next)
> - for (p = r->start; p <= r->finish; p++)
> - bitmap_set_bit (&live_reload_and_inheritance_pseudos[p], i);
> + {
> + bitmap_iterator bi;
> + unsigned p;
> + EXECUTE_IF_SET_IN_BITMAP (starts, r->start, p, bi)
> + {
> + if (p > (unsigned)r->finish)
> + break;
> + bitmap_set_bit (&live_reload_and_inheritance_pseudos[p], i);
> + }
> + }
> }
> + BITMAP_FREE (starts);
> }
>
> /* Finalize data about living reload pseudos at any given program
The patch looks ok to me. Thank you, Richard. You can commit it into the
trunk.
[Bug c/82272] RFE: request a warning for ( == ) etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82272 --- Comment #5 from Martin Sebor --- I submitted N2229 to WG14: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2229.htm I also opened Glibc bug for isdigit() et al. referenced in the paper: https://sourceware.org/bugzilla/show_bug.cgi?id=23003
[Bug target/58684] powerpc uses only unordered floating-point compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 --- Comment #6 from Segher Boessenkool --- Patch at https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01405.html .
[Bug target/58684] powerpc uses only unordered floating-point compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 --- Comment #5 from Segher Boessenkool --- *** Bug 84366 has been marked as a duplicate of this bug. ***
[Bug target/84366] gcc.dg/torture/float128-cmp-invalid.c fails when run on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84366 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Segher Boessenkool --- Dup. *** This bug has been marked as a duplicate of bug 58684 ***
[Bug c++/85087] call to a non-const member function on a const lvalue accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85087 Martin Sebor changed: What|Removed |Added Keywords||accepts-invalid --- Comment #1 from Martin Sebor --- The code has been accepted since at least GCC 4 so it's not a regression. For reference, EDG eccp 4.13 prints the following errors: "u.C", line 11: error: qualifiers dropped in binding reference of type "A &" to initializer of type "const A" g ((A)b); // error: good ^ "u.C", line 13: error: the object has type qualifiers that are not compatible with the member function "A::f" object type is: const A ((A)b).f (); // accepted: bug ^ 2 errors detected in the compilation of "u.C".
[Bug c++/85087] New: call to a non-const member function on a const lvalue accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85087
Bug ID: 85087
Summary: call to a non-const member function on a const lvalue
accepted
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
While looking at bug 85043 I noticed that in the test case below, GCC correctly
rejects the attempt to convert the const reference to B to A in the call to g()
but it accepts the same invalid conversion in the context where a a non-const
member function on the result of the conversion is called. Other compilers
reject both conversions.
$ cat u.C && /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -S -Wall
-Wextra -Wpedantic u.C
struct A { void f (); };
struct B {
operator const A& () const;
};
void g (A&);
void h (const B &b)
{
g ((A)b); // error: good
((A)b).f (); // accepted: bug
}
u.C: In function ‘void h(const B&)’:
u.C:11:6: error: cannot bind non-const lvalue reference of type ‘A&’ to an
rvalue of type ‘A’
g ((A)b); // error: good
^~~~
u.C:7:6: note: initializing argument 1 of ‘void g(A&)’
void g (A&);
^
[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-27 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- Confirmed that this is a worthwhile meta-bug grouping.
[Bug c++/84905] Improve warning for __attribute__((const)) on function returning void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84905 --- Comment #5 from Eric Gallager --- (In reply to Martin Sebor from comment #4) > Resolving as Won't Fix based on comment #2. (I will update > gcc-8/changes.html before the release and may update the documentation of > attribute const in the manual with additional detail.) Maybe also add a note to https://gcc.gnu.org/wiki/VerboseDiagnostics
[Bug fortran/80645] FAIL: gfortran.dg/elemental_subroutine_3.f90 -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80645 Martin Sebor changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #13 from Martin Sebor --- *** Bug 85085 has been marked as a duplicate of this bug. ***
[Bug middle-end/85085] [8 regression] Test case gfortran.dg/elemental_subroutine_3.f90 fails with __builtin_memcpy warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85085 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Sebor --- The warnings in this test are the subject of bug 80645. It's still not completely clear that the code the warning sees is correct (bug 80645 comment #10 says the test case is valid as is the code emitted by the Fortran front-end, but it doesn't speak to the validity of the GIMPLE, i.e., it doesn't refute the analysis in bug 80645 comment #3). I am also yet to fix bug 80545 which is about -Wstringop-overflow= being enabled by default by the Fortran front-end with no way to suppress it. *** This bug has been marked as a duplicate of bug 80645 ***
[Bug c/448] -related issues (C99 issues)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 Eric Gallager changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2008-04-15 19:37:34 |2018-3-26
[Bug target/83638] atomic_is_lock_free should return false on pa-risc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83638 --- Comment #4 from dave.anglin at bell dot net --- On 2018-03-26 2:23 PM, mikulas at artax dot karlin.mff.cuni.cz wrote: > If the userspace wants to optimize different code paths for lockless atomics > and for locked atomics, atomic_is_lock_free should return false, to indicate > that the atomic operation is as costly as taking a lock. At the moment, there's not really any way to specify this in the backend. I believe the function returns true in your examples because the call to can_compare_and_swap_p() in fold_builtin_atomic_always_lock_free() passes true for the allow_libcall argument. /* Check if a compare_and_swap pattern exists for the mode which represents the required size. The pattern is not allowed to fail, so the existence of the pattern indicates support is present. Also require that an atomic load exists for the required size. */ if (can_compare_and_swap_p (mode, true) && can_atomic_load_p (mode)) return boolean_true_node; else return boolean_false_node;
[Bug testsuite/83462] [8 regression] c-c++-common/Warray-bounds-3.c fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83462 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84175 --- Comment #8 from Martin Sebor --- *** Bug 84175 has been marked as a duplicate of this bug. ***
[Bug c/84175] FAIL: c-c++-common/Warray-bounds-4.c -Wc++-compat strcpy (test for warnings, line 67)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84175
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=83462
Resolution|--- |DUPLICATE
--- Comment #2 from Martin Sebor ---
The test failures are also discussed in bug 83462. The root cause of the
missing warning is bug 83543: a missing strlen optimization. The following
shows the problem:
$ cat z.c && gcc -O2 -S -Wall -Wextra -fdump-tree-wrestrict=/dev/stdout z.c
void f (int i)
{
struct {
char a[5], b[7];
} x = { "", "012345" }; // strlen pass doesn't know how to compute the
lengths of x.a and x.b
if (i < 1 || 2 < i)
i = 1;
__builtin_strcpy (x.a + i, x.b);
__builtin_puts (x.a);
}
;; Function f (f, funcdef_no=0, decl_uid=2854, cgraph_uid=0, symbol_order=0)
f (int i)
{
struct
{
char a[5];
char b[7];
} x;
unsigned int i.0_1;
unsigned int _2;
char * _4;
sizetype _13;
sizetype prephitmp_14;
[local count: 1073741825]:
x = *.LC0;
i.0_1 = (unsigned int) i_8(D);
_2 = i.0_1 + 4294967295;
if (_2 > 1)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 440234144]:
_13 = (sizetype) i_8(D);
[local count: 1073741824]:
# prephitmp_14 = PHI <_13(3), 1(2)>
_4 = &x.a + prephitmp_14;
__builtin_strcpy (_4, &x.b);
__builtin_puts (&x.a);
x ={v} {CLOBBER};
return;
}
*** This bug has been marked as a duplicate of bug 83462 ***
[Bug tree-optimization/79958] Missed tree DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79958 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law --- Even if we were to follow both paths, only one path has the necessary clobbers that would allow DSE to optimize away the assignment. One could make an argument that a call to __builtin_abort should be generating the necessary clobbers, or that they should be implicit. If we were to fix the clobbers so that they existed on both paths, then ISTM that we have to prove that the store is dead on all paths from the store. If it is only dead on some paths then it ought to be a candidate for sinking. This might argue that DSE and sinking should be sharing more infrastructure. Anyway, seems like GCC 9 or later work.
[Bug libgcc/85086] New: _Unwind_Resume can't unwind shadow stack with thread cancellation and alternate signal stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85086 Bug ID: 85086 Summary: _Unwind_Resume can't unwind shadow stack with thread cancellation and alternate signal stack Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x86 On Linux, when alternate signal stack is used with thread cancellation, _Unwind_Resume fails when it tries to unwind shadow stack from signal handler on alternate signal stack. The issue is that signal handler on alternate signal stack uses a separate shadow stack and we must switch to the original shadow stack to unwind it. But frame count will be wrong in this case. For thread cancellation, there is no need to unwind shadow stack since it will long jump back and exit.
[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791 --- Comment #12 from Bill Schmidt --- It's not clear yet what we should do with this. It looks like SMS is able to figure out that the sign-extension is not needed in the pre-r247885 code, but can't sort this out with the IVOPTS change. The IVOPTS change looks perfectly reasonable, but has the side effect of adding a second loop-carried dependency on i_5. It could be that this is why SMS fails, but why is this worse than the previous code, which instead had two loop-carried dependencies on ivtmp.10_18? One clue is that the "before" code contains: r174:SI = (SI)r164 + 32 r164:DI = zext(r174) which is a self-contained loop-carried dependence. For the "after" code, this disappears, and instead we introduce r165:SI = (SI)r160 << 3 r166:DI = zext(r165) Here we don't have a self-contained LCD, but it introduces confusion into an existing LCD that occurs later: r169:SI = (SI)r160 + 4 r160:DI = sext(r169) The latter is the sign-extension that we aren't able to remove. I suspect that the extra interference of the new code is the reason. It looks like the cost leading to the IVOPTS change is probably very close to the cost of leaving things as they were. Is that right? Is it possible for IVOPTS to detect that it's going to complicate a simple LCD in a case where the cost model doesn't show much difference? Not sure that is the right approach, just wondering. I will dig into the SMS algorithm next time I get some free time to look at it, and try to confirm my guesses. Maybe it can be taught to deal with this case.
[Bug middle-end/85085] New: [8 regression] Test case gfortran.dg/elemental_subroutine_3.f90 fails with __builtin_memcpy warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85085 Bug ID: 85085 Summary: [8 regression] Test case gfortran.dg/elemental_subroutine_3.f90 fails with __builtin_memcpy warnings Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- These failures started with r247622. They were mentioned in a previous PR which is fixed (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80643 and 80644 as well) but there were many other test case failures and I think these just got missed. FAIL: gfortran.dg/elemental_subroutine_3.f90 -O1 (test for excess errors) FAIL: gfortran.dg/elemental_subroutine_3.f90 -O2 (test for excess errors) FAIL: gfortran.dg/elemental_subroutine_3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/elemental_subroutine_3.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/elemental_subroutine_3.f90 -Os (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran9/../../gfortran -B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran9/../../ -B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -pedantic-errors -B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -lm -o ./elemental_subroutine_3.exe /home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90:37:0: Warning: '__builtin_memcpy' reading 16 bytes from a region of size 12 [-Wstringop-overflow=] FAIL: gfortran.dg/elemental_subroutine_3.f90 -O1 (test for excess errors) Excess errors: /home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90:37:0: Warning: '__builtin_memcpy' reading 16 bytes from a region of size 12 [-Wstringop-overflow=] spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran9/../../gfortran -B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran9/../../ -B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -pedantic-errors -B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -lm -o ./elemental_subroutine_3.exe /home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90:37:0: Warning: '__builtin_memcpy' reading 16 bytes from a region of size 12 [-Wstringop-overflow=] FAIL: gfortran.dg/elemental_subroutine_3.f90 -O2 (test for excess errors) Excess errors: /home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90:37:0: Warning: '__builtin_memcpy' reading 16 bytes from a region of size 12 [-Wstringop-overflow=] spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran9/../../gfortran -B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran9/../../ -B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -pedantic-errors -B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libatomic/.libs -B/home/seure
[Bug fortran/85083] [8 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:2915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85083 --- Comment #3 from Harald Anlauf --- Patch posted: https://gcc.gnu.org/ml/fortran/2018-03/msg00197.html
[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 Pat Haugen changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #16 from Pat Haugen --- (In reply to Jan Hubicka from comment #14) > Author: hubicka > Date: Mon Feb 12 09:48:06 2018 > New Revision: 257582 > > URL: https://gcc.gnu.org/viewcvs?rev=257582&root=gcc&view=rev > Log: > > PR middle-end/83665 > * params.def (inline-min-speedup): Increase from 8 to 15. > (max-inline-insns-auto): Decrease from 40 to 30. > * ipa-split.c (consider_split): Add some buffer for function to > be considered inlining candidate. > * invoke.texi (max-inline-insns-auto, inline-min-speedup): UPdate > default values. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/doc/invoke.texi > trunk/gcc/ipa-split.c > trunk/gcc/params.def This change is responsible for a 6% degradation in CPU2000 175.vpr and a 12% degradation in CPU2006 401.bzip2. Both run on a Power7 box.
[Bug fortran/85082] [8 Regression] ICE with -Ofast in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85082 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-26 Known to work||7.3.0 Target Milestone|--- |8.0 Ever confirmed|0 |1 Known to fail||8.0.1 --- Comment #1 from Dominique d'Humieres --- The ICE appeared between revision r247817 (2017-05-09, OK) and r248367 (2017-05-23, ICE).
[Bug fortran/85083] [8 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:2915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85083 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||ice-on-invalid-code Last reconfirmed||2018-03-26 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |8.0 Known to fail||8.0.1 --- Comment #2 from Dominique d'Humieres --- The block has been added at revision r257856.
[Bug c/84175] FAIL: c-c++-common/Warray-bounds-4.c -Wc++-compat strcpy (test for warnings, line 67)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84175 seurer at gcc dot gnu.org changed: What|Removed |Added Target|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11, ||powerpc64*-*-* CC||msebor at gcc dot gnu.org, ||seurer at gcc dot gnu.org Host|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11, ||powerpc64*-*-* Build|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11, ||powerpc64*-*-* --- Comment #1 from seurer at gcc dot gnu.org --- This also fails on powerpc64 both LE and BE and began with r255755 which is where the test case was introduced it looks like. r255755 | msebor | 2017-12-16 17:58:34 -0600 (Sat, 16 Dec 2017) | 81 lines PR tree-optimization/78918 - missing -Wrestrict on memcpy copying over self
[Bug target/83638] atomic_is_lock_free should return false on pa-risc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83638
--- Comment #3 from dave.anglin at bell dot net ---
On 2018-03-26 2:23 PM, mikulas at artax dot karlin.mff.cuni.cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83638
>
> --- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
> >From performance point of view it doesn't matter if the lock is taken inside
> the kernel or inside the gcc library.
Actually, I believe it does. It's not possible for a userspace
implementation to be non
interruptable. The atomic implementation is also tied to the futex
implementation in the kernel.
Interrupts are disabled around the lock to ensure the code can't
schedule. The lock itself is
never held for more than a few instructions. However, the code may spin
in kernel and
userspace.
The original choice whether the support was "lock free" was based on the
following in md.texi:
For the purposes of C++11 @code{std::atomic::is_lock_free}, it is
assumed that these library calls do @emph{not} use any kind of
interruptable locking.
The original linuxthread implementation used userspace locks and it was
pretty much a disaster
for a variety of reasons.
>
> If the userspace wants to optimize different code paths for lockless atomics
> and for locked atomics, atomic_is_lock_free should return false, to indicate
> that the atomic operation is as costly as taking a lock.
I'm not against atomic_is_lock_free always returning 0 on hppa but I've
yet to see a
real world situation where it makes a difference.
Dave
[Bug c/448] -related issues (C99 issues)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 --- Comment #38 from joseph at codesourcery dot com --- I think the correct state is NEW. There is a well-defined set of target OSes that lack the target macro definitions describing those targets' stdint.h types, each of which should be straightforward to fix for someone with access to the target OS in question to examine its headers and run tests.
[Bug fortran/85083] [8 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:2915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85083
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #1 from Harald Anlauf ---
The ICE is fixed by the obvious check:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (revision 258846)
+++ gcc/fortran/primary.c (working copy)
@@ -2898,6 +2898,7 @@
if (this_comp->ts.type == BT_CHARACTER && !this_comp->attr.allocatable
&& this_comp->ts.u.cl && this_comp->ts.u.cl->length
&& this_comp->ts.u.cl->length->expr_type == EXPR_CONSTANT
+ && actual->expr->ts.type == BT_CHARACTER
&& actual->expr->expr_type == EXPR_CONSTANT)
{
ptrdiff_t c, e;
This restores the original error message.
[Bug fortran/85084] [6/7/8 Regression] ICE: out of memory allocating 18446744073709551600 bytes ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85084 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-26 CC||tkoenig at gcc dot gnu.org Known to work||5.5.0 Target Milestone|--- |6.5 Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.0.1 --- Comment #1 from Dominique d'Humieres --- f951: out of memory allocating 18446744073709551600 bytes after a total of 0 bytes appears with -ffrontend-optimize and is suppressed with -fno-frontend-optimize.
[Bug target/84878] ICE: Segmentation fault (in add_cross_iteration_register_deps)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84878
--- Comment #2 from Peter Bergner ---
So we segv in ddg.c:add_cross_iteration_register_deps() at this code:
/* Create inter-loop true dependences and anti dependences. */
for (r_use = DF_REF_CHAIN (last_def); r_use != NULL; r_use = r_use->next)
{
rtx_insn *use_insn = DF_REF_INSN (r_use->ref);
segv's
We currently have:
(gdb) pr def_insn
(insn 331 321 332 12 (parallel [
(set (reg:V4SI 239 [ vect__4.11 ])
(unspec:V4SI [
(reg:V4SF 134 [ vect_cst__39 ])
(const_int 0 [0])
] UNSPEC_VCTSXS))
(set (reg:SI 110 vscr)
(unspec:SI [
(const_int 0 [0])
] UNSPEC_SET_VSCR))
]) "bug.i":9 1812 {altivec_vctsxs}
(expr_list:REG_UNUSED (reg:V4SI 239 [ vect__4.11 ])
(nil)))
(gdb) p DF_REF_REGNO (last_def)
$4 = 110
So we're looking at the definition of the VSCR hard register, which is a global
register (ie, global_regs[110] == 1), but there are no following explicit uses
of the VSCR reg, so:
(gdb) p DF_REF_INSN_INFO(r_use->ref)
$5 = (df_insn_info *) 0x0
When we call DF_REF_INSN(r_use->ref) which deferences
DF_REF_INSN_INFO(r_use->ref), we segv.
The following patch cures the segv:
Index: gcc/ddg.c
===
--- gcc/ddg.c (revision 258802)
+++ gcc/ddg.c (working copy)
@@ -295,6 +295,11 @@ add_cross_iteration_register_deps (ddg_p
/* Create inter-loop true dependences and anti dependences. */
for (r_use = DF_REF_CHAIN (last_def); r_use != NULL; r_use = r_use->next)
{
+ /* PR84878: Some definitions of global hard registers may not have
+ any following uses or they may be artificial, so skip them. */
+ if (DF_REF_INSN_INFO (r_use->ref) == NULL)
+ continue;
+
rtx_insn *use_insn = DF_REF_INSN (r_use->ref);
if (BLOCK_FOR_INSN (use_insn) != g->bb)
[Bug target/85073] [x86] extra check after BLSR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85073 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |8.0 --- Comment #2 from Uroš Bizjak --- Fixed.
[Bug target/85073] [x86] extra check after BLSR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85073 --- Comment #1 from uros at gcc dot gnu.org --- Author: uros Date: Mon Mar 26 19:26:19 2018 New Revision: 258864 URL: https://gcc.gnu.org/viewcvs?rev=258864&root=gcc&view=rev Log: PR target/85073 * config/i386/i386.md (*bmi_blsr__cmp): New insn pattern. (*bmi_blsr__ccz): Ditto. testsuite/ChangeLog: PR target/85073 * gcc.target/i386/pr85073.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85073.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug ipa/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983 seurer at gcc dot gnu.org changed: What|Removed |Added Target|hppa-unknown-linux-gnu, |hppa-unknown-linux-gnu, |arm-none-linux-gnueabihf|arm-none-linux-gnueabihf, ||powerpc64*-*-* CC||seurer at gcc dot gnu.org Host|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, ||powerpc64*-*-* Build|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, ||powerpc64*-*-* --- Comment #10 from seurer at gcc dot gnu.org --- FYI these fail on powerpc64 as well both LE and BE. FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8) FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_1.C line 2) FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_1.C line 3) FAIL: g++.dg/lto/pr83121 cp_lto_pr83121_0.o-cp_lto_pr83121_1.o link, -O0 -flto
[Bug fortran/85084] New: [6/7/8 Regression] ICE: out of memory allocating 18446744073709551600 bytes ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85084 Bug ID: 85084 Summary: [6/7/8 Regression] ICE: out of memory allocating 18446744073709551600 bytes ... Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Invalid code affects versions 6/7/8 : $ cat z1.f90 program p real :: a(3,3) = 1.0 real :: b(3) b = matmul(a, a) end $ cat z2.f90 program p real :: a(3,3) = 1.0 real :: b(33) b = matmul(a, a) end $ gfortran-5 -c z1.f90 -O2 z1.f90:4:3: b = matmul(a, a) 1 Error: Incompatible ranks 1 and 2 in assignment at (1) $ gfortran-8 -c z1.f90 -O2 z1.f90:4:3: b = matmul(a, a) 1 Error: Incompatible ranks 1 and 2 in assignment at (1) f951: out of memory allocating 18446744073709551600 bytes after a total of 643072 bytes
[Bug fortran/85083] New: [8 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:2915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85083 Bug ID: 85083 Summary: [8 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:2915 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20180218 and 20180225 : $ cat z1.f90 program p type t character(3) :: c end type type(t), allocatable :: z allocate (z, source=t(.true.,'abc')) end $ gfortran-8-20180218 -c z1.f90 z1.f90:6:32: allocate (z, source=t(.true.,'abc')) 1 Error: Too many components in structure constructor at (1) $ gfortran-8-20180325 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb9c38f crash_signal ../../gcc/toplev.c:325 0x705c4d gfc_convert_to_structure_constructor(gfc_expr*, gfc_symbol*, gfc_expr**, gfc_actual_arglist**, bool) ../../gcc/fortran/primary.c:2915 0x70dbb8 resolve_generic_f ../../gcc/fortran/resolve.c:2699 0x70dbb8 resolve_function ../../gcc/fortran/resolve.c:3171 0x70df5a gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6709 0x71531b gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11092 0x71721a resolve_codes ../../gcc/fortran/resolve.c:16525 0x71731e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16560 0x700aea resolve_all_program_units ../../gcc/fortran/parse.c:6060 0x700aea gfc_parse_file() ../../gcc/fortran/parse.c:6310 0x74791f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/85082] New: [8 Regression] ICE with -Ofast in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85082 Bug ID: 85082 Summary: [8 Regression] ICE with -Ofast in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2624 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed before 20170618 : $ cat z1.f90 program p real(4) :: a, b integer(4) :: n, m equivalence (a, n) a = 1024.0 m = 8 a = 1024.0 b = set_exponent(a, m) n = 8 a = f(a, n) b = set_exponent(a, m) end $ cat z2.f90 program p real(8) :: a, b integer(8) :: n, m equivalence (a, n) a = 1024.0 m = 8 a = 1024.0 b = set_exponent(a, m) n = 8 a = f(a, n) b = set_exponent(a, m) end $ gfortran-7 -c z1.f90 -Ofast $ gfortran-8-20180325 -c z1.f90 -O3 $ $ gfortran-8-20180325 -c z1.f90 -Ofast during GIMPLE pass: fre z1.f90:12:0: end internal compiler error: in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2624 0xd11093 vn_reference_insert_pieces(tree_node*, int, tree_node*, vec, tree_node*, unsigned int) ../../gcc/tree-ssa-sccvn.c:2624 0xd11151 vn_reference_lookup_or_insert_for_pieces ../../gcc/tree-ssa-sccvn.c:1646 0xd12135 vn_reference_lookup_3 ../../gcc/tree-ssa-sccvn.c:2068 0xc728aa walk_non_aliased_vuses(ao_ref*, tree_node*, void* (*)(ao_ref*, tree_node*, unsigned int, void*), void* (*)(ao_ref*, tree_node*, void*, bool*), tree_node* (*)(tree_node*), void*) ../../gcc/tree-ssa-alias.c:2801 0xd0eaa0 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind, vn_reference_s**, bool) ../../gcc/tree-ssa-sccvn.c:2517 0xd0f431 eliminate_dom_walker::before_dom_children(basic_block_def*) ../../gcc/tree-ssa-sccvn.c:5629 0x11dd2af dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:353 0xd0ac38 vn_eliminate(bitmap_head*) ../../gcc/tree-ssa-sccvn.c:5910 0xd16da1 execute ../../gcc/tree-ssa-sccvn.c:6018
[Bug target/83638] atomic_is_lock_free should return false on pa-risc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83638 --- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz --- >From performance point of view it doesn't matter if the lock is taken inside the kernel or inside the gcc library. If the userspace wants to optimize different code paths for lockless atomics and for locked atomics, atomic_is_lock_free should return false, to indicate that the atomic operation is as costly as taking a lock.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #68 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #67) > On March 26, 2018 2:46:08 PM GMT+02:00, "jakub at gcc dot gnu.org" > wrote: > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 > > > >--- Comment #66 from Jakub Jelinek --- > >(In reply to Jakub Jelinek from comment #63) > >> --- gcc/dwarf2out.c2018-03-11 17:48:53.498068316 +0100 > >> +++ gcc/dwarf2out.c2018-03-13 10:58:03.477514623 +0100 > >> @@ -28282,6 +28282,7 @@ output_macinfo (const char *debug_line_l > >>case DW_MACINFO_undef: > >> if ((!dwarf_strict || dwarf_version >= 5) > >> && HAVE_COMDAT_GROUP > >> +&& !flag_lto > > Flag_generate_lto || Flag_generate_offload > > Is what we use elsewhere It is meant just to debug the issue, the final patch would use some configure macro if it helps.
[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004 --- Comment #35 from Jakub Jelinek --- Created attachment 43763 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43763&action=edit pr82004_dumps.tar.xz Dumps. For lto I've just added the init_sw_absorption function parts of the dump, the dumps are too large.
[Bug c/39808] warn_unused_result fails to produce warning in a statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39808 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|dave.pagan at oracle dot com, |paolo.carlini at oracle dot com |gcc-bugs at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |dave.pagan at oracle dot com --- Comment #6 from Paolo Carlini --- Dave is on it.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #67 from rguenther at suse dot de --- On March 26, 2018 2:46:08 PM GMT+02:00, "jakub at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 > >--- Comment #66 from Jakub Jelinek --- >(In reply to Jakub Jelinek from comment #63) >> --- gcc/dwarf2out.c 2018-03-11 17:48:53.498068316 +0100 >> +++ gcc/dwarf2out.c 2018-03-13 10:58:03.477514623 +0100 >> @@ -28282,6 +28282,7 @@ output_macinfo (const char *debug_line_l >> case DW_MACINFO_undef: >>if ((!dwarf_strict || dwarf_version >= 5) >>&& HAVE_COMDAT_GROUP >> + && !flag_lto Flag_generate_lto || Flag_generate_offload Is what we use elsewhere >>&& vec_safe_length (files) != 1 >>&& i > 0 >>&& i + 1 < length >> help? If yes, we could go for && (!flag_lto || >!HAVE_BROKEN_LD_WHATEVER) >> and add configure test for that. > >Rainer, does the above patch fix your remaining issues or are other >sections >involved too?
[Bug c/55976] -Werror=return-type should error on returning a value from a void function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|dave.pagan at oracle dot com | Assignee|unassigned at gcc dot gnu.org |dave.pagan at oracle dot com --- Comment #8 from Paolo Carlini --- Dave is on it.
[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004 --- Comment #34 from Jakub Jelinek --- Ok, I can now reproduce, but only with -flto, not without that. Without -flto, before pre I see: [local count: 85892]: # logchl_591 = PHI <-3.0097868371792719699442386627197265625e+0(33), logchl_701(129)> # mc_799 = PHI # n_623 = PHI <0(33), _789(129)> # DEBUG n => n_623 # DEBUG mc => mc_799 # DEBUG logchl => logchl_591 dlogchl.345_699 = dlogchl; logchl_701 = logchl_591 + dlogchl.345_699; # DEBUG logchl => logchl_701 _702 = __builtin_pow (1.0e+1, logchl_701); chlamnt = _702; # DEBUG m => 1 # DEBUG m => 1 ... in -fdump-tree-pre-details dump I see: SCC consists of 67: logchl_591 .MEM_621 dlogchl.345_699 logchl_701 _702 .MEM_913 .MEM_914 .MEM_915 .MEM_916 .MEM_917 .MEM_918 stdout.350_714 .MEM_9 19 .MEM_920 .MEM_921 .MEM_922 .MEM_923 .MEM_924 .MEM_807 _718 _719 _723 _724 w2_725 w1_726 _727 _728 _729 _730 _731 .MEM_925 _732 _733 _734 _735 _7 36 .MEM_926 _737 _738 _739 _740 _741 .MEM_927 _742 _743 _744 _745 _746 .MEM_928 .MEM_944 mpercm.360_758 .MEM_622 _755 _757 _759 M.119_814 _761 _762 _765 _767 _768 M.120_202 _770 _771 _773 _774 .MEM_946 Starting iteration 1 Value numbering logchl_591 stmt = logchl_591 = PHI <-3.0097868371792719699442386627197265625e+0(33), logchl_701(129)> Setting value number of logchl_591 to -3.0097868371792719699442386627197265625e+0 (changed) Value numbering .MEM_621 stmt = .MEM_621 = PHI <.MEM_898(33), .MEM_946(129)> Setting value number of .MEM_621 to .MEM_898 (changed) Value numbering dlogchl.345_699 stmt = dlogchl.345_699 = dlogchl; Setting value number of dlogchl.345_699 to 1.2081668171172168513294309377670288085938e-2 (changed) Value numbering logchl_701 stmt = logchl_701 = logchl_591 + dlogchl.345_699; Match-and-simplified logchl_591 + dlogchl.345_699 to -3.0e+0 RHS logchl_591 + dlogchl.345_699 simplified to -3.0e+0 Setting value number of logchl_701 to -3.0e+0 (changed) Value numbering _702 stmt = _702 = __builtin_pow (1.0e+1, logchl_701); Match-and-simplified __builtin_pow (1.0e+1, logchl_701) to 1.2081668171172168513294309377670288085938e-3 call __builtin_pow (1.0e+1, logchl_701) simplified to 1.2081668171172168513294309377670288085938e-3 Setting value number of _702 to 1.2081668171172168513294309377670288085938e-3 (changed) With -flto, I see just similar: [local count: 16255]: # n_925 = PHI <0(33), _1128(129)> # logchl_926 = PHI <-3.0097868371792719699442386627197265625e+0(33), logchl_1040(129)> # mc_928 = PHI # a1_lsm.5953_134 = PHI # a2_lsm.5954_1153 = PHI # b1_lsm.5955_1099 = PHI # b2_lsm.5956_139 = PHI # DEBUG n => n_925 # DEBUG mc => mc_928 # DEBUG logchl => logchl_926 logchl_1040 = logchl_926 + 1.2081668171172168513294309377670288085938e-2; # DEBUG logchl => logchl_1040 _1041 = __builtin_pow (1.0e+1, logchl_1040); chlamnt_lsm.5952_1150 = _1041; # DEBUG m => 1 # DEBUG m => 1 before pre, but instead: SCC consists of 2: logchl_926 logchl_1040 Starting iteration 1 Value numbering logchl_926 stmt = logchl_926 = PHI <-3.0097868371792719699442386627197265625e+0(33), logchl_1040(129)> Setting value number of logchl_926 to -3.0097868371792719699442386627197265625e+0 (changed) Value numbering logchl_1040 stmt = logchl_1040 = logchl_926 + 1.2081668171172168513294309377670288085938e-2; Match-and-simplified logchl_926 + 1.2081668171172168513294309377670288085938e-2 to -3.0e+0 RHS logchl_926 + 1.2081668171172168513294309377670288085938e-2 simplified to -3.0e+0 Setting value number of logchl_1040 to -3.0e+0 (changed) Starting iteration 2 Value numbering logchl_926 stmt = logchl_926 = PHI <-3.0097868371792719699442386627197265625e+0(33), logchl_1040(129)> Setting value number of logchl_926 to logchl_926 (changed) Value numbering logchl_1040 stmt = logchl_1040 = logchl_926 + 1.2081668171172168513294309377670288085938e-2; Setting value number of logchl_1040 to logchl_1040 (changed) Processing SCC needed 3 iterations Value numbering _1093 stmt = _1093 = (long int) k_1137; Setting value number of _1093 to _1093 (changed) Value numbering _1103 stmt = _1103 = _1091 + _1093; Setting value number of _1103 to _1103 (changed) Value numbering _1041 stmt = _1041 = __builtin_pow (1.0e+1, logchl_1040); Setting value number of _1041 to _1041 (changed) so this precomputation of the first iteration doesn't happen in that case. Richard, any way to debug why? I'll attach the log files (lim2 and pre-details).
[Bug sanitizer/85081] New: [7(8 Regression] Sanitizer error with references in vectorized/parallel for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85081
Bug ID: 85081
Summary: [7(8 Regression] Sanitizer error with references in
vectorized/parallel for-loop
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
The following valid code snippet compiled with
"-fopenmp-simd -fsanitize=address"
is aborted by the sanitizer at runtime since GCC 7.1.0:
inline const int& max(const int& a, const int& b)
{
return a < b ? b : a;
}
int main()
{
#pragma omp simd
// #pragma omp parallel for
for ( int i = 0; i < 20; ++i )
{
const int j = max(i, 1);
}
return 0;
}
==25412==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7ffe6a4ecac0 at pc 0x0040090a bp 0x7ffe6a4eca80 sp 0x7ffe6a4eca78
WRITE of size 4 at 0x7ffe6a4ecac0 thread T0
#0 0x400909 in main (a.out+0x400909)
#1 0x7f88f7f84724 in __libc_start_main (/lib64/libc.so.6+0x20724)
#2 0x400748 in _start (a.out+0x400748)
Address 0x7ffe6a4ecac0 is located in stack of thread T0 at offset 32 in frame
#0 0x400805 in main (a.out+0x400805)
This frame has 2 object(s):
[32, 36) '' <== Memory access at offset 32 is inside this variable
[96, 100) 'i'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope (a.out+0x400909) in main
Shadow bytes around the buggy address:
0x10004d495900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004d495910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004d495920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004d495930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004d495940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10004d495950: 00 00 00 00 f1 f1 f1 f1[f8]f2 f2 f2 f2 f2 f2 f2
0x10004d495960: 04 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00
0x10004d495970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004d495980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004d495990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004d4959a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==25412==ABORTING
The address-sanitizer also complains with "#pragma omp parallel for"
and "-fopenmp".
The problem persists if I change the return value of "max" to "int",
but disappears if I change the arguments to plain "int".
I don't know whether this is a sanitizer or OpenMP (or even a C++ frontend)
issue.
[Bug c++/85062] [6/7/8 Regression] ICE on alignas with parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85062 --- Comment #2 from Jason Merrill --- Author: jason Date: Mon Mar 26 16:30:41 2018 New Revision: 258859 URL: https://gcc.gnu.org/viewcvs?rev=258859&root=gcc&view=rev Log: PR c++/85062 - ICE with alignas in wrong place. * decl.c (grokdeclarator): Ignore attributes on type-specifiers here. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alignas16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug target/85080] [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85080 seurer at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64*-*-* CC||dje at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Host||powerpc64*-*-* Build||powerpc64*-*-* --- Comment #1 from seurer at gcc dot gnu.org --- Note that this fails on both Le and BE.
[Bug target/85080] New: [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85080 Bug ID: 85080 Summary: [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- This originally began failings with r248678 quite a long time ago (2017-05-31) along with a bunch of other test cases. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925. The others are all fixed now but not this one. FAIL: gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c scan-tree-dump-times vect "vectorization not profitable" 1 (found 0 times) FAIL: gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c scan-tree-dump-times vect "vectorized 1 loops" 1 (found 2 times)
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.0 --- Comment #12 from Jonathan Wakely --- (In reply to Paolo Carlini from comment #7) > Certainly I can confirm that the problem cannot be reproduced anymore by > tweaking the random seed to 1153519516. Given this comment, I don't know how to reproduce the original failure. So let's say it's FIXED. Benjamin's commit was in GCC 4.7.0 so setting that for the target milestone.
[Bug lto/85078] LTO ICE: tree check: expected tree that contains 'decl minimal' structure, have 'identifier_node' in decl_mangling_context, at cp/mangle.c:878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078 --- Comment #1 from Franz Sirl --- The ICE was introduced between r257623 and r257685.
[Bug c++/85071] The g++ delete the memory alloced by new operator before I manually delete it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85071 --- Comment #2 from Jonathan Wakely --- Both valgrind and AddressSanitizer would have found this bug, you should use them.
[Bug c++/85071] The g++ delete the memory alloced by new operator before I manually delete it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85071
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely ---
class Module : public SyntaxElement {
public:
Module() = default;
bool hasCalleesFor(IntrusiveRefCntPtr func) const
{ return true; }
};
void Context::setAvailableCallees() {
if(!M->hasCalleesFor(F)) return;
}
This creates an IntrusiveRefCntPtr which owns F, and so at the end of
the statement the smart pointer deletes F.
Any later use of that pointer (via this->F or the global func) is undefined.
[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737 --- Comment #11 from Martin Jambor --- I guess you'll need to check whether it is PR 55334 (i.e. not preserving restrict accross ipa-cp and/or inlining) coming back somehow...
[Bug target/84786] [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84786
--- Comment #12 from Jakub Jelinek ---
For 7.x I think we need:
--- gcc/config/i386/sse.md.jj 2018-03-05 17:04:45.820743323 +0100
+++ gcc/config/i386/sse.md 2018-03-26 17:29:00.967880855 +0200
@@ -10687,7 +10687,7 @@
[(set (match_operand:VI2_AVX2_AVX512BW 0 "register_operand" "=x,v")
(any_lshift:VI2_AVX2_AVX512BW
(match_operand:VI2_AVX2_AVX512BW 1 "register_operand" "0,v")
- (match_operand:DI 2 "nonmemory_operand" "xN,vN")))]
+ (match_operand:DI 2 "nonmemory_operand" "xN,YvN")))]
"TARGET_SSE2 && && "
"@
p\t{%2, %0|%0, %2}
@@ -10706,7 +10706,7 @@
[(set (match_operand:VI48_AVX2 0 "register_operand" "=x,x,v")
(any_lshift:VI48_AVX2
(match_operand:VI48_AVX2 1 "register_operand" "0,x,v")
- (match_operand:DI 2 "nonmemory_operand" "xN,xN,vN")))]
+ (match_operand:DI 2 "nonmemory_operand" "xN,xN,YvN")))]
"TARGET_SSE2 && "
"@
p\t{%2, %0|%0, %2}
but don't have time to test it right now, nor create short self-contained
testcases for it.
[Bug target/84878] ICE: Segmentation fault (in add_cross_iteration_register_deps)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84878 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-26 CC||bergner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Peter Bergner --- Confirmed. You also get an ICE if you replace -mcpu=??? with just -maltivec
[Bug c++/85079] New: Segfault While Compiling DXX-Rebirth Project
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85079 Bug ID: 85079 Summary: Segfault While Compiling DXX-Rebirth Project Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: afuturepilotis at gmail dot com Target Milestone: --- Here is the error report I received: /usr/bin/i686-w64-mingw32-g++ -v -save-temps -c -g -O2 -ftabstop=4 -Wall -Werror=extra -Werror=format=2 -Werror=missing-braces -Werror=missing-include-dirs -Werror=uninitialized -Werror=undef -Werror=pointer-arith -Werror=cast-qual -Werror=missing-declarations -Werror=redundant-decls -Werror=vla -funsigned-char -std=gnu++14 -Werror=unused -Werror=useless-cast -fvisibility=hidden -Wsuggest-attribute=noreturn -Wlogical-op -Wold-style-cast -Wno-format-truncation -Wno-implicit-fallthrough -Wno-sign-compare -D_WIN32 -DWIN32_LEAN_AND_MEAN -DPHYSFS_DEPRECATED= -DNDEBUG -DRELEASE -D_WIN32_WINNT=1536 -Icommon/include -Icommon/main -I. -I/usr/i686-w64-mingw32/include/libpng16 -I/usr/i686-w64-mingw32/include -I/usr/i686-w64-mingw32/include/SDL "common/2d/bitblt.cpp" -o "common/2d/bitblt.o" Using built-in specs. COLLECT_GCC=/usr/bin/i686-w64-mingw32-g++ Target: i686-w64-mingw32 Configured with: /home/shadoww/Projects/aurpkg/mingw-w64/aurpkg/mingw-w64-gcc/src/gcc/configure --prefix=/usr --libexecdir=/usr/lib --target=i686-w64-mingw32 --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-threads=posix --enable-fully-dynamic-string --enable-libstdcxx-time=yes --with-system-zlib --enable-cloog-backend=isl --enable-lto --disable-dw2-exceptions --enable-libgomp --disable-multilib --enable-checking=release : (reconfigured) /home/shadoww/Projects/aurpkg/mingw-w64/aurpkg/mingw-w64-gcc/src/gcc/configure --prefix=/usr --libexecdir=/usr/lib --target=i686-w64-mingw32 --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-threads=posix --enable-fully-dynamic-string --enable-libstdcxx-time=yes --with-system-zlib --enable-cloog-backend=isl --enable-lto --disable-dw2-exceptions --enable-libgomp --disable-multilib --enable-checking=release Thread model: posix gcc version 7.3.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-g' '-O2' '-ftabstop=4' '-Wall' '-Werror=extra' '-Werror=format=2' '-Werror=missing-braces' '-Werror=missing-include-dirs' '-Werror=uninitialized' '-Werror=undef' '-Werror=pointer-arith' '-Werror=cast-qual' '-Werror=missing-declarations' '-Werror=redundant-decls' '-Werror=vla' '-funsigned-char' '-std=gnu++14' '-Werror=unused' '-Werror=useless-cast' '-fvisibility=hidden' '-Wsuggest-attribute=noreturn' '-Wlogical-op' '-Wold-style-cast' '-Wformat-truncation=0' '-Wimplicit-fallthrough=0' '-Wno-sign-compare' '-D' '_WIN32' '-D' 'WIN32_LEAN_AND_MEAN' '-D' 'PHYSFS_DEPRECATED=' '-D' 'NDEBUG' '-D' 'RELEASE' '-D' '_WIN32_WINNT=1536' '-I' 'common/include' '-I' 'common/main' '-I' '.' '-I' '/usr/i686-w64-mingw32/include/libpng16' '-I' '/usr/i686-w64-mingw32/include' '-I' '/usr/i686-w64-mingw32/include/SDL' '-o' 'common/2d/bitblt.o' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /usr/lib/gcc/i686-w64-mingw32/7.3.0/cc1plus -E -quiet -v -I common/include -I common/main -I . -I /usr/i686-w64-mingw32/include/libpng16 -I /usr/i686-w64-mingw32/include -I /usr/i686-w64-mingw32/include/SDL -D_REENTRANT -D _WIN32 -D WIN32_LEAN_AND_MEAN -D PHYSFS_DEPRECATED= -D NDEBUG -D RELEASE -D _WIN32_WINNT=1536 common/2d/bitblt.cpp -mtune=generic -march=pentiumpro -std=gnu++14 -Wall -Werror=extra -Werror=format=2 -Werror=missing-braces -Werror=missing-include-dirs -Werror=uninitialized -Werror=undef -Werror=pointer-arith -Werror=cast-qual -Werror=missing-declarations -Werror=redundant-decls -Werror=vla -Werror=unused -Werror=useless-cast -Wsuggest-attribute=noreturn -Wlogical-op -Wold-style-cast -Wformat-truncation=0 -Wimplicit-fallthrough=0 -Wno-sign-compare -ftabstop=4 -funsigned-char -fvisibility=hidden -g -fworking-directory -O2 -fpch-preprocess -o bitblt.ii ignoring nonexistent directory "/usr/lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/sys-include" ignoring duplicate directory "/usr/i686-w64-mingw32/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: common/include common/main . /usr/i686-w64-mingw32/include/libpng16 /usr/i686-w64-mingw32/include/SDL /usr/lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/include/c++/7.3.0 /usr/lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/include/c++/7.3.0/i686-w64-mingw32 /usr/lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/include/c++/7.3.0/backward /usr/lib/gcc/i686-w64-mingw32/7.3.0/include /usr/lib/gcc/i686-w64-mingw32/7.3.0/include-fixed /usr/lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/inc
[Bug libstdc++/84654] libstdc++ tries to use __float128 when compiling with -mno-float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84654 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #2 from Jonathan Wakely --- Fix posted to: https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01389.html
[Bug target/84786] [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84786 --- Comment #11 from Matthias Kretz --- Created attachment 43762 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43762&action=edit test case that produces incorrect vpsrlw Compiled with `g++-7 -std=c++17 -O0 -fabi-version=0 -fabi-compat-version=0 -march=knl -o fail fail.cpp` g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0 from objdump -d | grep vpsrlw I get: 56e364: 62 b1 7d 08 d1 c0 vpsrlw %xmm16,%xmm0,%xmm0 56eaf6: 62 b1 7d 08 d1 c1 vpsrlw %xmm17,%xmm0,%xmm0 56f174: 62 b1 7d 08 d1 c2 vpsrlw %xmm18,%xmm0,%xmm0 56f68c: 62 b1 7d 08 d1 c3 vpsrlw %xmm19,%xmm0,%xmm0 58ef6f: 62 b1 7d 08 d1 c0 vpsrlw %xmm16,%xmm0,%xmm0 58f6f5: 62 b1 7d 08 d1 c1 vpsrlw %xmm17,%xmm0,%xmm0 58fd67: 62 b1 7d 08 d1 c2 vpsrlw %xmm18,%xmm0,%xmm0 590273: 62 b1 7d 08 d1 c3 vpsrlw %xmm19,%xmm0,%xmm0 59585d: 62 b1 7d 08 d1 c0 vpsrlw %xmm16,%xmm0,%xmm0 595fef: 62 b1 7d 08 d1 c1 vpsrlw %xmm17,%xmm0,%xmm0 596664: 62 b1 7d 08 d1 c2 vpsrlw %xmm18,%xmm0,%xmm0 596b6a: 62 b1 7d 08 d1 c3 vpsrlw %xmm19,%xmm0,%xmm0 59cb7a: 62 b1 7d 28 d1 c0 vpsrlw %xmm16,%ymm0,%ymm0 59d39f: 62 b1 7d 28 d1 c1 vpsrlw %xmm17,%ymm0,%ymm0 59d9fe: 62 b1 7d 28 d1 c2 vpsrlw %xmm18,%ymm0,%ymm0 59dfc6: 62 b1 7d 28 d1 c3 vpsrlw %xmm19,%ymm0,%ymm0 5a407c: 62 b1 7d 28 d1 c0 vpsrlw %xmm16,%ymm0,%ymm0 5a4895: 62 b1 7d 28 d1 c1 vpsrlw %xmm17,%ymm0,%ymm0 5a4eeb: 62 b1 7d 28 d1 c2 vpsrlw %xmm18,%ymm0,%ymm0 5a54ad: 62 b1 7d 28 d1 c3 vpsrlw %xmm19,%ymm0,%ymm0 5be392: 62 b1 7d 08 d1 c0 vpsrlw %xmm16,%xmm0,%xmm0 5bea0b: 62 b1 7d 08 d1 c1 vpsrlw %xmm17,%xmm0,%xmm0 5bef85: 62 b1 7d 08 d1 c2 vpsrlw %xmm18,%xmm0,%xmm0 5bf3be: 62 b1 7d 08 d1 c3 vpsrlw %xmm19,%xmm0,%xmm0 5d8ae0: 62 b1 7d 08 d1 c0 vpsrlw %xmm16,%xmm0,%xmm0 5d9149: 62 b1 7d 08 d1 c1 vpsrlw %xmm17,%xmm0,%xmm0 5d96b3: 62 b1 7d 08 d1 c2 vpsrlw %xmm18,%xmm0,%xmm0 5d9adc: 62 b1 7d 08 d1 c3 vpsrlw %xmm19,%xmm0,%xmm0 5de3e7: 62 b1 7d 08 d1 c0 vpsrlw %xmm16,%xmm0,%xmm0 5dea62: 62 b1 7d 08 d1 c1 vpsrlw %xmm17,%xmm0,%xmm0 5defd5: 62 b1 7d 08 d1 c2 vpsrlw %xmm18,%xmm0,%xmm0 5df3fe: 62 b1 7d 08 d1 c3 vpsrlw %xmm19,%xmm0,%xmm0 5e3cd2: 62 b1 7d 08 d1 c0 vpsrlw %xmm16,%xmm0,%xmm0 5e431b: 62 b1 7d 08 d1 c1 vpsrlw %xmm17,%xmm0,%xmm0 5e4865: 62 b1 7d 08 d1 c2 vpsrlw %xmm18,%xmm0,%xmm0 5e4c6e: 62 b1 7d 08 d1 c3 vpsrlw %xmm19,%xmm0,%xmm0 5e94bd: 62 b1 7d 08 d1 c0 vpsrlw %xmm16,%xmm0,%xmm0 5e9b18: 62 b1 7d 08 d1 c1 vpsrlw %xmm17,%xmm0,%xmm0 5ea06b: 62 b1 7d 08 d1 c2 vpsrlw %xmm18,%xmm0,%xmm0 5ea474: 62 b1 7d 08 d1 c3 vpsrlw %xmm19,%xmm0,%xmm0 799710: c5 f9 d1 c5 vpsrlw %xmm5,%xmm0,%xmm0 7999a9: c5 f9 d1 c6 vpsrlw %xmm6,%xmm0,%xmm0 799e3b: c5 f9 d1 c7 vpsrlw %xmm7,%xmm0,%xmm0 79a101: 62 b1 7d 08 d1 c0 vpsrlw %xmm16,%xmm0,%xmm0 79a3c2: 62 b1 7d 08 d1 c1 vpsrlw %xmm17,%xmm0,%xmm0 79a68c: 62 b1 7d 08 d1 c2 vpsrlw %xmm18,%xmm0,%xmm0 7a1e51: c5 f9 d1 c5 vpsrlw %xmm5,%xmm0,%xmm0 7a20ea: c5 f9 d1 c6 vpsrlw %xmm6,%xmm0,%xmm0 7a2579: c5 f9 d1 c7 vpsrlw %xmm7,%xmm0,%xmm0 7a283f: 62 b1 7d 08 d1 c0 vpsrlw %xmm16,%xmm0,%xmm0 7a2b00: 62 b1 7d 08 d1 c1 vpsrlw %xmm17,%xmm0,%xmm0 7a2dca: 62 b1 7d 08 d1 c2 vpsrlw %xmm18,%xmm0,%xmm0
[Bug target/84786] [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84786 --- Comment #10 from Matthias Kretz --- This is all I have right now: TID 0 SDE-ERROR: Executed instruction not valid for specified chip (KNL): 0x70d281: vpsrlw xmm0, xmm0, xmm16 Image: /home/travis/build/VcDevel/Vc/build-Experimental/c2dd920concentrateGCC7.2.0Relivy-bridgeknl/tests/mask_knl_vectorbuiltin+0x30d281 (in multi-region image, region# 0) Function: _ZN5Tests11load_store_IN2Vc2v29simd_maskIfNS2_6detail7avx_abiILi32EE3runEv Instruction bytes are: 62 b1 7d 08 d1 c0 See bottom of: http://lxwww53.gsi.de/testDetails.php?test=2016375&build=14519
[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004 --- Comment #33 from Andrey Guskov --- This is the full execution line I used to produce the log in question, and with which the test continues failing: $ gfortran -fdump-tree-all -fdump-rtl-all -m64 -c -o sw_absorption.fppized.o -march=core-avx2 -mfpmath=sse -Ofast -fno-associative-math -funroll-loops -flto -fopenmp -fconvert=big-endian sw_absorption.fppized.f90
[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004 --- Comment #32 from Andrey Guskov --- Created attachment 43761 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43761&action=edit Dump as requested in #c31 Jakub, see the attachment. This is the log of what I get, packed in 7Z. At a glance, the importatnt part looks quite similar to what Richard has shown.
[Bug target/84786] [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84786 --- Comment #9 from Jakub Jelinek --- (In reply to Matthias Kretz from comment #8) > There seems to be a similar bug for vpsrlw and vpsllw. Do you need a > testcase? (It's hard to hit the bug... just had one occur on a Travis CI > build) I don't see how that is possible. Do you have at least objdump with the instructions (e.g. which exact operand it is), and what gcc options were used?
[Bug c++/85062] [6/7/8 Regression] ICE on alignas with parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85062 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/85049] [8 Regression] Internal compiler error with __integer_pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85049 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/85049] [8 Regression] Internal compiler error with __integer_pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85049 --- Comment #4 from Jason Merrill --- Author: jason Date: Mon Mar 26 14:37:50 2018 New Revision: 258856 URL: https://gcc.gnu.org/viewcvs?rev=258856&root=gcc&view=rev Log: PR c++/85049 - ICE with __integer_pack. * pt.c (unify_pack_expansion): Don't try to deduce generated packs. * cp-tree.h (TEMPLATE_PARM_P): New. Added: trunk/gcc/testsuite/g++.dg/ext/integer-pack3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c
[Bug lto/85078] New: LTO ICE: tree check: expected tree that contains 'decl minimal' structure, have 'identifier_node' in decl_mangling_context, at cp/mangle.c:878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078 Bug ID: 85078 Summary: LTO ICE: tree check: expected tree that contains 'decl minimal' structure, have 'identifier_node' in decl_mangling_context, at cp/mangle.c:878 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: sirl at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 43760 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43760&action=edit testcase The attached testcase ICEs with trunk@r258851. 7.3.1 compiles the testcase without problems. g++-8 -flto -c -O2 test-LTO-ICE.cpp during IPA pass: visibility test-LTO-ICE.cpp:20:8: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'identifier_node' in decl_mangling_context, at cp/mangle.c:878 void c (int, const char *, a &); ^ 0xa22890 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.c:9494 0x4b05dc contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.h:3249 0x4b05dc decl_mangling_context ../../gcc/cp/mangle.c:878 0x4b05dc write_name ../../gcc/cp/mangle.c:906 0xfd6cea write_class_enum_type ../../gcc/cp/mangle.c:2809 0xfd6cea write_type ../../gcc/cp/mangle.c: 0xfd743b write_array_type ../../gcc/cp/mangle.c:3600 0xfd743b write_type ../../gcc/cp/mangle.c:2146 0xfd6ea8 write_type ../../gcc/cp/mangle.c:2255 0xfd7de8 write_method_parms ../../gcc/cp/mangle.c:2796 0xfd2af4 write_bare_function_type ../../gcc/cp/mangle.c:2732 0xfd2af4 write_encoding ../../gcc/cp/mangle.c:847 0xfd220e write_mangled_name ../../gcc/cp/mangle.c:790 0xfd220e mangle_decl_string ../../gcc/cp/mangle.c:3792 0xfd1cd5 get_mangled_id ../../gcc/cp/mangle.c:3814 0xfd1cd5 mangle_decl(tree_node*) ../../gcc/cp/mangle.c:3852 0x1451e5d decl_assembler_name(tree_node*) ../../gcc/tree.c:687 0x10f55e0 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool) ../../gcc/symtab.c:174 0x10f55e0 symtab_node::register_symbol() ../../gcc/symtab.c:386 0x10fd244 cgraph_node::create(tree_node*) ../../gcc/cgraph.c:520 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug middle-end/85074] FAIL: g++.dg/torture/pr81812.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85074
--- Comment #2 from John David Anglin ---
We have default TARGET_USE_LOCAL_THUNK_ALIAS_P and
TARGET_ASM_CAN_OUTPUT_MI_THUNK is default_can_output_mi_thunk_no_vcall().
if (!this_adjusting
|| !targetm.asm_out.can_output_mi_thunk (thunk_fndecl, fixed_offset,
virtual_value, alias))
{
/* If this is a covariant thunk, or we don't have the necessary
code for efficient thunks, generate a thunk function that
just makes a call to the real function. Unfortunately, this
doesn't work for varargs. */
if (varargs_function_p (function))
error ("generic thunk code fails for method %q#D which uses %<...%>",
function);
}
[Bug c++/85077] [8 Regression] V[248][SD]F abs not optimized to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85077
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|WAITING |ASSIGNED
CC||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Target Milestone|--- |8.0
Summary|V[248][SD]F abs not |[8 Regression] V[248][SD]F
|optimized to|abs not optimized to
--- Comment #5 from Jakub Jelinek ---
This regressed with r248124, before that change the FE would fold the two
functions to ABS_EXPR but now it emits VEC_COND_EXPR < x < {0.0, 0.0, 0.0,
0.0} , -NON_LVALUE_EXPR , x > and nothing recognizes that later. I'll have
a look.
[Bug target/84786] [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84786 --- Comment #8 from Matthias Kretz --- There seems to be a similar bug for vpsrlw and vpsllw. Do you need a testcase? (It's hard to hit the bug... just had one occur on a Travis CI build)
[Bug other/31852] Missing __builtin_memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31852 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Mon Mar 26 13:09:10 2018 New Revision: 258854 URL: https://gcc.gnu.org/viewcvs?rev=258854&root=gcc&view=rev Log: Add workaround to std::variant for Clang bug 31852 * include/std/variant (__get): Qualify calls to avoid ADL. (__select_index): Adjust whitespace. (variant): Add using-declaration to workaround Clang bug. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/variant
[Bug c/78568] [6/7/8/9 Regression] Wtype-limits warning regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78568 Jakub Jelinek changed: What|Removed |Added Keywords||deferred Target Milestone|6.5 |9.0 Summary|[6/7/8 Regression] |[6/7/8/9 Regression] |Wtype-limits warning|Wtype-limits warning |regression |regression --- Comment #8 from Jakub Jelinek --- Deferred for GCC9+, as we don't want to introduce new warnings to GCC8 at this point.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #20 from Jakub Jelinek --- Andrew, a friendly ping on this. The #c13 patch looks like a good progress, what happened to it?
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #66 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #63) > --- gcc/dwarf2out.c 2018-03-11 17:48:53.498068316 +0100 > +++ gcc/dwarf2out.c 2018-03-13 10:58:03.477514623 +0100 > @@ -28282,6 +28282,7 @@ output_macinfo (const char *debug_line_l > case DW_MACINFO_undef: > if ((!dwarf_strict || dwarf_version >= 5) > && HAVE_COMDAT_GROUP > + && !flag_lto > && vec_safe_length (files) != 1 > && i > 0 > && i + 1 < length > help? If yes, we could go for && (!flag_lto || !HAVE_BROKEN_LD_WHATEVER) > and add configure test for that. Rainer, does the above patch fix your remaining issues or are other sections involved too?
[Bug inline-asm/85030] [6/7 Regression] internal compiler error: Floating point exception (validate_subreg())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85030 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8 Regression] internal |[6/7 Regression] internal |compiler error: Floating|compiler error: Floating |point exception |point exception |(validate_subreg()) |(validate_subreg()) --- Comment #6 from Jakub Jelinek --- Fixed on the trunk.
[Bug c++/85077] V[248][SD]F abs not optimized to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85077 --- Comment #4 from Matthias Kretz --- Oh, there seems to be a regression in GCC 8. In 7 it works as you say. In 8 I can't get the andps to show up
[Bug c++/85077] V[248][SD]F abs not optimized to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85077 --- Comment #3 from Matthias Kretz --- Ouch, right I didn't think of non-finite values. I.e. -0 < 0 is false... However, this is what I wanted: abs(-inf) -> inf abs( inf) -> inf abs( nan) -> nan abs( -0) -> 0 abs( 0) -> 0 The sign bit manipulation works for all of them. The ternary fails only on the -0 input, no? I'm working on an implementation of wg21.link/p0214r9 that I'd like to contribute to libstdc++, which is why I'm currently looking to remove workarounds and enable the compiler to do const-prop as much as possible. I'd be happy to go with an implementation that uses my_abs if that's the way to go (I guess it is). FWIW, ICC translates `x < 0 ? -x : x` (on float itself) to sign masking. (But then again ICC doesn't conform with default flags either)
[Bug go/84948] [8 regression] ICE in set_from, at go/gofrontend/types.cc:2660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Survey Invite] Bug report duplication problem - Help our study
I've invited you to fill out the following form: Professional Profile To fill it out, visit: https://docs.google.com/forms/d/e/1FAIpQLSfQTZkrylE1t49gjzewPQSPWHFnPtGCZfRujg_G8VTwqGrbHg/viewform?c=0&w=1&usp=mail_form_link Dear friend, I am a master's student in Computer Science at the Federal University of Bahia, Salvador, Brazil, under the advising of Dr. Eduardo Almeida. We chose you because you participated in one of the open source projects included in this study. All the information provided will be kept confidential. We have no intention to judge your work since we are merely interested in learning about some aspects of your work. We are investigating the bug report duplication problem, so based on your experience using bug-trackers, we would like to invite you to participate in a short 8-10 minute survey that our research group is conducting to get opinion about this subject. Please, return it until March 31st, 2018. We will offer a lottery ticket to compete for an Amazon $100 credit and the results of the study when we finished the analysis. We appreciate your time! Best Regards, Alexandre Gitirana Google Forms: Create and analyze surveys.
[Bug lto/85047] cdd2a01 (and others) FAIL with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85047
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
void foo(int n)
{
struct X { int a[n]; } a;
struct Y { struct X *p; } b;
static struct Y z;
}
shows that there's no clear boundary with the way we stream things given
'z' ends up in the symtab as global entity but it refers to a function-local
type.
With nested functions we'll easily fall into a similar trap I guess and
those would also make the above even more "complicated" by effectively
assigning z two different types? (one referencing 'n' directly and one
referencing it via the static chain -- which doesn't actually get 'n'
here)
int foo(int n)
{
struct X { int a[n]; } a;
struct Y { struct X *p; };
static struct Y z;
int bar(int i) { return z.p->a[i]; }
z.p = &a;
return bar(3);
}
int main() { return foo(5); }
just to mention these in the quest to get the "sharing" automagically
"correct".
So it looks like all types should be "global", even those refering to other
local entities. We mostly promote things to "local" to optimize the WPA
tree merging phase and shrink the global section but it looks like the
"local" property is quite complicated and cannot be computed "locally"
when processing just one decls trees (global var or function).
[Bug rtl-optimization/78200] [7/8 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200 --- Comment #23 from Jakub Jelinek --- Created attachment 43759 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43759&action=edit gcc8-pr78200.patch Does this patch make any difference on the benchmark?
[Bug c++/85077] V[248][SD]F abs not optimized to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85077 Richard Biener changed: What|Removed |Added Component|target |c++ --- Comment #2 from Richard Biener --- I suppose this asks for a std::abs overload and/or (for C) a __builtin_abs that also works with generic vectors. Or a C/C++ operator for abs.
[Bug target/85077] V[248][SD]F abs not optimized to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85077 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-03-26 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Using -O2 -ffinite-math-only -fno-signed-zeros I do get _Z3absDv4_f: .LFB0: .cfi_startproc vandps .LC0(%rip), %xmm0, %xmm0 ret so I'd say it works as expected?
[Bug c++/85070] [8 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85070 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/85046] [8 Regression] cp/name-lookup.c:6175:53: runtime error: member access within null pointer of type 'struct cp_binding_level'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85046 --- Comment #3 from Nathan Sidwell --- Created attachment 43758 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43758&action=edit another example I've further altered the testcase. This one ICEs at #3 all the way back to gcc-5 (at least). Notice it gives no error on lines #1 or #2, at least one of those is bogus. Line #1 either implicitly creates union g inside c()::q, or is an error (I need to check the std carefully, but my recollection is that inside a struct definition only 'union g;' forward declares a union. ). If that recollection is wrong, and #1 is ok. then #2 is an error, because we have to tagged types 'g' inside c()::q. What's happening is that the the xref_tag for 'union q' inside c()::q has ts_global for the scope -- so it looks in outer scopes. But this also injects it into an outer scope when we don't find it. That's wrong. Our lazy binding level caching machinery gets confused and scroggs the binding stack, leading to bad reuse. In some cases that bad reuse was hidden by the existence of a namespace-scope binding onto IDENTIFIER_BINDING. That doesn't exist any more. So we ICE in some more cases. I still think this is ICE on invalid, but it's not error-recovery.
[Bug tree-optimization/85050] Vectorized function - suboptimal gather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85050 --- Comment #4 from H.J. Lu --- (In reply to H.J. Lu from comment #3) > (In reply to Richard Biener from comment #2) > > IIRC there's a related bug with regard to double <-> float conversions and > > SSE > > vectorization. Can't find it right now. > > PR 36844? PR 46011 and PR 46012?
[Bug tree-optimization/85050] Vectorized function - suboptimal gather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85050 --- Comment #3 from H.J. Lu --- (In reply to Richard Biener from comment #2) > IIRC there's a related bug with regard to double <-> float conversions and > SSE > vectorization. Can't find it right now. PR 36844?
[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83789 --- Comment #27 from kaushikp at gcc dot gnu.org --- I have verified the backported patch to GCC-7 and it fixes the issues I had observed earlier. Thanks again Peter for this!
[Bug c++/85061] ICE with __builtin_offsetof applied to static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85061 --- Comment #2 from Jakub Jelinek --- Created attachment 43757 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43757&action=edit gcc8-pr85061.patch Untested fix.
[Bug target/85077] New: V[248][SD]F abs not optimized to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85077
Bug ID: 85077
Summary: V[248][SD]F abs not optimized to
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
The following test case (also at https://godbolt.org/g/XEPk7M) shows that `x <
0 ? -x : x` is not optimized to an efficient abs implementation. This is not
only the case for SSE, but also for AVX and AVX512 vectors.
The my_abs functions show what I'd expect the result to be.
#include
template using V [[gnu::vector_size(N)]] = T;
auto abs(V x) { return x < 0 ? -x : x; }
auto my_abs(V x) {
return _mm_and_ps((__m128)(~V() >> 1), x);
}
auto abs(V x) { return x < 0 ? -x : x; }
auto my_abs(V x) {
return _mm_and_pd((__m128d)(~V() >> 1), x);
}
[Bug lto/84592] [openacc,openmp] lto1: ICE in input_varpool_node, at lto-cgraph.c:1424: for function static var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84592 Tom de Vries changed: What|Removed |Added Summary|[openacc,openmp] lto1: ICE |[openacc,openmp] lto1: ICE |in input_varpool_node, at |in input_varpool_node, at |lto-cgraph.c:1424: for |lto-cgraph.c:1424: for |CSWTCH symbol |function static var --- Comment #11 from Tom de Vries --- The switch conversion part of this is handled in PR85063 - "Support switch conversion in offloading functions". Remaining to be handled here is the example from comment 5. Updating summary to reflect that.
[Bug tree-optimization/85063] Support switch conversion in offloading functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85063 Tom de Vries changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Target Milestone|--- |8.0
[Bug tree-optimization/85063] Support switch conversion in offloading functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85063 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Tom de Vries --- Patch with OpenMP and OpenACC test-cases committed. Marking resolved-fixed.
[Bug tree-optimization/85063] Support switch conversion in offloading functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85063 --- Comment #10 from Tom de Vries --- Author: vries Date: Mon Mar 26 09:45:49 2018 New Revision: 258852 URL: https://gcc.gnu.org/viewcvs?rev=258852&root=gcc&view=rev Log: Fix switch conversion in offloading functions 2018-03-26 Tom de Vries PR tree-optimization/85063 * omp-general.c (offloading_function_p): New function. Factor out of ... * omp-offload.c (pass_omp_target_link::gate): ... here. * omp-general.h (offloading_function_p): Declare. * tree-switch-conversion.c (build_one_array): Mark CSWTCH.x variable with attribute omp declare target for offloading functions. * testsuite/libgomp.c/switch-conversion-2.c: New test. * testsuite/libgomp.c/switch-conversion.c: New test. * testsuite/libgomp.oacc-c-c++-common/switch-conversion-2.c: New test. * testsuite/libgomp.oacc-c-c++-common/switch-conversion.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/switch-conversion-2.c trunk/libgomp/testsuite/libgomp.c/switch-conversion.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/switch-conversion-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/switch-conversion.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-general.c trunk/gcc/omp-general.h trunk/gcc/omp-offload.c trunk/gcc/tree-switch-conversion.c trunk/libgomp/ChangeLog
[Bug c++/85076] [6/7/8 Regression] ICE with invalid template used as lambda argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85076 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 43756 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43756&action=edit gcc8-pr85076.patch Full untested patch.
