[Bug rtl-optimization/85789] Signed integer overflow with nonzero optimization in cse.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85789 --- Comment #1 from Vittorio Zecca --- I confirm it is still in trunk 270309, must be compiled with nonzero optimization ~/local/gcc-270309-undefined/bin/gcc -S -O gccerr67.c ../../gcc/gcc/cse.c:2215:34: runtime error: signed integer overflow: 1 - -9223372036854775807 cannot be represented in type 'long int' Bug now moved at line 2215 offset = (get_integer_term (x) - get_integer_term (p->exp));
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #81 from Jürgen Reuter --- LLVM worked, so I think there are enough green lights now for committing this fix.
[Bug inline-asm/52813] %rsp in clobber list is silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813 --- Comment #10 from Eric Gallager --- (In reply to rsand...@gcc.gnu.org from comment #8) > Author: rsandifo > Date: Tue Jan 15 16:46:54 2019 > New Revision: 267941 > > URL: https://gcc.gnu.org/viewcvs?rev=267941=gcc=rev > Log: > PR inline-asm/52813 revisited > > The original patch for this PR made it an error to list the stack > pointer in the clobber list of an inline asm. However, the general > feeling seemed to be that going straight to a hard error was too harsh, > since there's quite a bit of existing code that has the clobber. > > This patch implements the compromise discussed on IRC of making it > a -Wdeprecated warning instead. > > 2019-01-15 Richard Sandiford > > gcc/ > PR inline-asm/52813 > * doc/extend.texi: Document that listing the stack pointer in the > clobber list of an asm is a deprecated feature. > * common.opt (Wdeprecated): Moved from c-family/c.opt. > * cfgexpand.c (asm_clobber_reg_is_valid): Issue a -Wdeprecated > warning instead of an error for clobbers of the stack pointer. > Add a note explaining why. > > gcc/c-family/ > PR inline-asm/52813 > * c.opt (Wdeprecated): Move documentation and variable to common.opt. > > gcc/d/ > PR inline-asm/52813 > * lang.opt (Wdeprecated): Reference common.opt instead of c.opt. > > gcc/testsuite/ > PR inline-asm/52813 > * gcc.target/i386/pr52813.c (test1): Turn the diagnostic into a > -Wdeprecated warning and expect a following note:. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/c-family/ChangeLog > trunk/gcc/c-family/c.opt > trunk/gcc/cfgexpand.c > trunk/gcc/common.opt > trunk/gcc/d/ChangeLog > trunk/gcc/d/lang.opt > trunk/gcc/doc/extend.texi > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/gcc.target/i386/pr52813.c (In reply to Christophe Lyon from comment #9) > Author: clyon > Date: Fri Jan 18 09:57:41 2019 > New Revision: 268066 > > URL: https://gcc.gnu.org/viewcvs?rev=268066=gcc=rev > Log: > [ARM][testsuite] follow-up to PR target/52813 and target/11807 fix. > > 2019-01-18 Christophe Lyon > > * gcc.target/arm/pr77904.c: Add dg-warning for sp clobber. > > > Modified: > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/gcc.target/arm/pr77904.c So after these 2, has this been fixed now?
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Ian Lance Taylor --- Fixed, I hope.
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 --- Comment #10 from ian at gcc dot gnu.org --- Author: ian Date: Thu Apr 18 04:11:22 2019 New Revision: 270434 URL: https://gcc.gnu.org/viewcvs?rev=270434=gcc=rev Log: PR go/90110 compiler: use temporary to avoid early destruction The code was passing a substr directly to strtol, and then checking the *end value returned by strtol. But the substr could be destroyed as soon as strtol returns, making the test of *end invalid. Also fix an incorrect test of the string index rather than the value. Fixes https://gcc.gnu.org/PR90110 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/172663 Modified: trunk/gcc/go/gofrontend/MERGE trunk/gcc/go/gofrontend/import.cc
[Bug c++/90047] [8/9 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90047 --- Comment #5 from Jason Merrill --- Author: jason Date: Thu Apr 18 03:32:24 2019 New Revision: 270433 URL: https://gcc.gnu.org/viewcvs?rev=270433=gcc=rev Log: PR c++/90047 - ICE with enable_if alias template. In order to make alias templates useful for SFINAE we instantiate them under the prevailing 'complain' argument, so an error encountered while instantiating during SFINAE context is silent. The problem in this PR comes when we later look up the erroneous instantiation and don't give an error at that point. Fixed by not adding an erroneous instantiation to the hash table, so we instantiate it again when needed and get the error. This required changes to a number of tests, which previously said "substitution failed:" with no explanation of what the failure was; now we properly explain. * pt.c (tsubst_decl) [TYPE_DECL]: Don't put an erroneous decl in the hash table when we're in SFINAE context. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-67.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C trunk/libstdc++-v3/testsuite/20_util/duration/arithmetic/dr3050.cc trunk/libstdc++-v3/testsuite/20_util/from_chars/1_c++20_neg.cc trunk/libstdc++-v3/testsuite/20_util/from_chars/1_neg.cc trunk/libstdc++-v3/testsuite/20_util/shared_ptr/assign/auto_ptr_neg.cc trunk/libstdc++-v3/testsuite/20_util/shared_ptr/assign/shared_ptr_neg.cc trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/unique_ptr_neg.cc trunk/libstdc++-v3/testsuite/20_util/to_chars/1_neg.cc trunk/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc trunk/libstdc++-v3/testsuite/20_util/unique_ptr/cons/ptr_deleter_neg.cc trunk/libstdc++-v3/testsuite/20_util/unique_ptr/modifiers/reset_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/insert_neg.cc trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/insert_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc trunk/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc trunk/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/pointer_ctor_neg.cc trunk/libstdc++-v3/testsuite/experimental/memory/shared_ptr/modifiers/reset_neg.cc
[Bug fortran/90133] New: Linker error if no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90133
Bug ID: 90133
Summary: Linker error if no
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below compiles cleanly with -fcoarray=single but generates a linker
error when I use -fcoarray=lib and link to MPICH and OpenCoarrays. The linking
problem goes away if the "use" statement and "type(event_type)" declaration are
moved to just after the "associate" statement and wrapped in "block/end block",
which leads me to suspect this might be a gfortran bug rather than an
OpenCoarrays bug.
$ cat link-error.f90
module link_error
contains
subroutine post_event_in_associate
use iso_fortran_env
type(event_type), save :: e[*]
associate( i => 1 )
event post(e[1])
end associate
end
end module
end
$ gfortran \
-I/home/rouson/Desktop/Builds/opt/opencoarrays/2.6.1-b480f1d/gnu/9.0.1/include/OpenCoarrays-2.6.1-14-gb480f1d_GNU-9.0.1
\
-fcoarray=lib \
-Wl,-rpath \
-Wl,/home/rouson/Builds/opt/mpich/3.2/gnu/9.0.1/lib \
-Wl,--enable-new-dtags ${@} \
/home/rouson/Desktop/Builds/opt/opencoarrays/2.6.1-b480f1d/gnu/9.0.1/lib/libcaf_mpi.a
\
/home/rouson/Desktop/Builds/opt/mpich/3.2/gnu/9.0.1/lib/libmpifort.so \
/home/rouson/Desktop/Builds/opt/mpich/3.2/gnu/9.0.1/lib/libmpi.so \
link-error.f90
/tmp/ccU8ZmCw.o: In function `_caf_init.1.3907':
link-error.f90:(.text+0x4d): undefined reference to `caf_token.0.3905'
link-error.f90:(.text+0x5c): undefined reference to `_gfortran_caf_register'
/tmp/ccU8ZmCw.o: In function `__link_error_MOD_post_event_in_associate':
link-error.f90:(.text+0x8b): undefined reference to `caf_token.0.3905'
link-error.f90:(.text+0xae): undefined reference to `_gfortran_caf_event_post'
/tmp/ccU8ZmCw.o: In function `main':
link-error.f90:(.text+0xda): undefined reference to `_gfortran_caf_init'
link-error.f90:(.text+0x104): undefined reference to `_gfortran_caf_finalize'
collect2: error: ld returned 1 exit status
$ gfortran --version
GNU Fortran (GCC) 9.0.1 20190318 (experimental)
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 Peter Bergner changed: What|Removed |Added Attachment #46189|0 |1 is obsolete|| --- Comment #34 from Peter Bergner --- Created attachment 46190 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46190=edit Updated patch Updated patch that is functionally the same, but I like this one better.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #33 from Peter Bergner --- Created attachment 46189 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46189=edit Proposed patch Here is a patch that fixes make_object_dead() that was causing r0 to be incorrectly added to p116's total_conflict_regs which made it impossible to assign r0 to p116. With this patch, we now assign r0 to p116 like we want: ;; a5(r116,l0) conflicts: ;; total conflict hard regs: ;; conflict hard regs: ... Popping a5(r116,l0) -- assign reg 0 Popping a3(r112,l0) -- assign reg 4 Popping a2(r114,l0) -- assign reg 4 Popping a0(r111,l0) -- assign reg 0 Popping a4(r117,l0) -- assign reg 0 Popping a1(r113,l0) -- assign reg 3 Disposition: 0:r111 l0 03:r112 l0 41:r113 l0 32:r114 l0 4 5:r116 l0 04:r117 l0 0 Can someone on the ARM side please bootstrap and regtest the patch to see if it fixes the testsuite fallout? I'll bootstrap and regtest it on power.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #32 from Peter Bergner ---
(In reply to Peter Bergner from comment #26)
> (In reply to Vladimir Makarov from comment #25)
> > (In reply to Peter Bergner from comment #24)
> >> I don't know why r0 isn't in profitable_regs for pseudo 116.
> >
> > Profitable regs there contain also conflict regs. R0 is conflicting with
> > p106. If R0 usage (in call insn) were in the same BB, your new conflict
> > calculation found that there is no actual conflict. But IRA uses
> > df-infrastructure which tells IRA that R0 lives at the BB end where p106
> > occurs.
>
> I'm sorry, but I don't see where p116 conflicts with r0. Can you show me
> where/how? Looking at my IRA dump, I see:
Ok, so there is a bug in print_allocno_conflicts() that causes us to skip
printing the hard reg conflicts if the allocno doesn't have any conflicts with
other allocnos. I submitted a patch to fix that. With the fix, I know see the
following conflict info for p116:
;; a5(r116,l0) conflicts:
;; total conflict hard regs: 0
;; conflict hard regs:
So this explains why p116 isn't assigned r0. That doesn't explain why p116
conflicts with r0 though, because looking at the rtl brlow, it shouldn't:
(insn 50 3 7 2 (set (reg:SI 116)
(reg:SI 0 r0 [ aD.4197 ])) "bug.i":7:1 181 {*arm_movsi_insn}
(nil))
(insn 7 50 8 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 116)
(const_int 0 [0])))
(set (reg/v:SI 112 [ aD.4197 ])
(reg:SI 116))
]) "bug.i":10:6 188 {*movsi_compare0}
(expr_list:REG_DEAD (reg:SI 116)
(nil)))
So yes, r0 is live at the definition of p116, we know they have the same value.
My ira-conflicts.c changes adding non_conflicting_reg_copy_p() should have
handled that, but it isn't. Now non_conflicting_reg_copy_p() does correctly
notice that insn 50 is a simple copy that we can ignore for conflict purposes,
but somehow, a conflict is still being added.
I tracked the problem down to ira-conflicts.c:make_object_dead() not handling
ignore_reg_for_conflicts correctly. The bug is that we correctly remove the
ignored reg (r0) from OBJECT_CONFLICT_HARD_REGS, but we miss removing it from
OBJECT_TOTAL_CONFLICT_HARD_REGS too. I'm working on a patch.
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #80 from Jürgen Reuter --- > A little late to the party, but this revised patch worked for me on > 10.4.4/Xcode10.2 with gcc8.3.0, gcc7.4.0, and gcc6.5.0. fftw3-3.3.8 built > and passed all tests against the patched gcc8 and gcc7. cernlib built > against the patched gcc6. Never too late for an important confirmation.^^ LLVM now builds (after solving unrelated PR90124, its tests are running (45%done). Looks good.
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #79 from fink at snaggledworks dot com --- (In reply to Iain Sandoe from comment #68) > Created attachment 46176 [details] > revised fixincludes patch. > > So I have an answer about the language implications. > > Any C++ program containing _Atomic is using a reserved identifier, and so is > "ill-formed no diagnostic required", per [lex.name]/3 > > Therefore, it's standards-conforming for a [C++] implementation to make such > identifiers keywords (as GCC does for __attribute__, for example) > > Apparently, this is intentional extension and is only one of a longer list > of such keywords that clang++ accepts. > > > > Since, according to the discussion above, this is not a bug in the compiler > but rather in using a non-portable extension, perhaps we should not expect > any change to the headers. > > > > The patch attached include the generated files, and I'd be grateful if folks > would test it (right now I have limited access to Darwin test boxen, but it > seems to DTRT for me) - I will post to @patches, but leave commit until it's > confirmed that it's working. A little late to the party, but this revised patch worked for me on 10.4.4/Xcode10.2 with gcc8.3.0, gcc7.4.0, and gcc6.5.0. fftw3-3.3.8 built and passed all tests against the patched gcc8 and gcc7. cernlib built against the patched gcc6.
[Bug c++/81159] New warning idea: -Wself-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159
Nikolay Orliuk changed:
What|Removed |Added
CC||virkony at gmail dot com
--- Comment #4 from Nikolay Orliuk ---
Just curious if this code works good with return value optimization like:
static inline T conditional_update(T&& src, bool flag) {
if (flag) {
return T{};
} else {
return std::move(src);
}
}
T a;
a = conditional_update(a, true);
a = conditional_update(a, false);
Is it going to produce warning after inlining and propagating constants?..
[Bug libstdc++/90105] std::forward_list::sort() is not "stable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Wed Apr 17 21:47:20 2019 New Revision: 270427 URL: https://gcc.gnu.org/viewcvs?rev=270427=gcc=rev Log: PR libstdc++/90105 make forward_list::sort stable While testing the fix I also discovered that operator== assumes the elements are comparable with operator!= which is not required. PR libstdc++/90105 * include/bits/forward_list.h (operator==): Do not use operator!= to compare elements. (forward_list::sort(Comp)): When elements are equal take the one earlier in the list, so that sort is stable. * testsuite/23_containers/forward_list/operations/90105.cc: New test. * testsuite/23_containers/forward_list/comparable.cc: Test with types that meet the minimum EqualityComparable and LessThanComparable requirements. Remove irrelevant comment. Added: trunk/libstdc++-v3/testsuite/23_containers/forward_list/operations/90105.cc - copied, changed from r270425, trunk/libstdc++-v3/testsuite/23_containers/forward_list/comparable.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/forward_list.tcc trunk/libstdc++-v3/testsuite/23_containers/forward_list/comparable.cc
[Bug c++/81159] New warning idea: -Wself-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159 --- Comment #3 from Marek Polacek --- Ok, this shouldn't be too hard. I guess I could implement it for GCC 10.
[Bug c++/81159] New warning idea: -Wself-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159 Eric Gallager changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Eric Gallager --- cc-ing Marek since he wrote a blog post that seems relevant here: https://developers.redhat.com/blog/2019/04/12/understanding-when-not-to-stdmove-in-c/
[Bug c++/67906] Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906 Eric Gallager changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #10 from Eric Gallager --- (In reply to Jonathan Wakely from comment #8) > Kinda related: PR 86981 cc-ing Marek since he fixed that
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #35 from Eric Gallager --- cc-ing Martin Sebor since this bug is relevant to this blog post he wrote: https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings/ (In reply to Manuel López-Ibáñez from comment #16) > Subject: Bug 7651 > > Author: manu > Date: Tue Jan 2 17:33:25 2007 > New Revision: 120347 > > URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=120347 > Log: > 2007-01-02 Manuel Lopez-Ibanez > > PR middle-end/7651 > * c.opt (Wold-style-declaration): New. > * doc/invoke.texi (C-only Warning Options): New. > (Wold-style-declaration): Document it. > (Wextra): Enabled by -Wextra. > * c-opts.c (c_common_post_options): Enabled by -Wextra. > * c-decl.c (declspecs_add_scspec): Replace -Wextra with > -Wold-style-declaration. > > testsuite/ > * gcc.dg/declspec-3.c: Replace -W with -Wold-style-declaration. > * gcc.dg/declspec-3-Wextra.c: New. > * gcc.dg/declspec-3-no.c: New > > Added: > trunk/gcc/testsuite/gcc.dg/declspec-3-Wextra.c > trunk/gcc/testsuite/gcc.dg/declspec-3-no.c > Modified: > trunk/gcc/ChangeLog > trunk/gcc/c-decl.c > trunk/gcc/c-opts.c > trunk/gcc/c.opt > trunk/gcc/doc/invoke.texi > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/gcc.dg/declspec-3.c Would have been nice to have a testcase explicitly named gcc.dg/Wold-style-declaration.c, too, for easier findability
[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410 --- Comment #22 from Segher Boessenkool --- #line 0 isn't valid C code. If it causes problems we should just error on it (and perhaps even when it doesn't (yet) cause problems).
[Bug bootstrap/90132] make bootstrap fails with -O3 (gcc9 snapshot 20190414)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132
--- Comment #2 from Martin Sebor ---
I think the following test case reproduces what's going on in decNumber.c.
Both GCC 8 and 9 issue the warning (IIRC, the warning was added in GCC 7 for
writes but enhanced to reads in GCC 8).
$ cat a.c && gcc -O3 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
struct S
{
int n, a[1];
};
static inline void f (int *d, const struct S *p)
{
const int *e = p->n > 1 ? p->a + p->n : p->a + 1;
for (const int *s = p->a + 1; s < e; ++s, ++d)
*d = *s;
}
void g (struct S*);
void h (int *d)
{
struct S s = { 0 };
g ();
f (d, );
}
;; Function h (h, funcdef_no=1, decl_uid=1920, cgraph_uid=2, symbol_order=1)
Removing basic block 6
Removing basic block 7
h (int * d)
{
struct S s;
int _6;
long unsigned int _7;
long unsigned int _8;
const int * iftmp.0_9;
unsigned long _15;
unsigned long _16;
sizetype _20;
unsigned long _23;
sizetype _24;
unsigned long _25;
unsigned long _26;
[local count: 118111600]:
s = {};
g ();
_6 = s.n;
if (_6 > 1)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 69685844]:
_7 = (long unsigned int) _6;
_8 = _7 * 4;
iftmp.0_9 = + _8;
if ([(void *) + 8B] < iftmp.0_9)
goto ; [93.20%]
else
goto ; [6.80%]
[local count: 64949629]:
_26 = (unsigned long) iftmp.0_9;
_16 = (unsigned long) [(void *) + 8B];
_15 = ~_16;
_23 = _15 + _26;
_25 = _23 >> 2;
_24 = _25 + 1;
_20 = _24 * 4;
__builtin_memcpy (d_4(D), [(void *) + 8B], _20); [tail call]
[local count: 118111601]:
s ={v} {CLOBBER};
return;
}
a.c: In function ‘h’:
cc1: warning: ‘__builtin_memcpy’ reading 4 or more bytes from a region of size
0 [-Wstringop-overflow=]
[Bug bootstrap/90132] make bootstrap fails with -O3 (gcc9 snapshot 20190414)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-17
CC||msebor at gcc dot gnu.org
Blocks||88443
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
I can reproduce the warning without -fPIC:
$ (cd /build/gcc-svn-self/libdecnumber && /build/gcc-svn/gcc/xgcc -B
/build/gcc-svn/gcc -I/src/gcc/svn/libdecnumber -I. -O3 -g3 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long -fno-lto
-I/src/gcc/svn/libdecnumber -I. -S /src/gcc/svn/libdecnumber/decNumber.c)
/src/gcc/svn/libdecnumber/decNumber.c: In function ‘decNumberPower’:
cc1: warning: ‘__builtin_memcpy’ reading 2 or more bytes from a region of size
0 [-Wstringop-overflow=]
$
The variable being read is dnOne:
[local count: 3614127]:
# iftmp.231_443 = PHI
smsup_444 = + iftmp.231_443;
if ([(void *) + 12B] < smsup_444)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 3216573]:
_110 = (unsigned long) smsup_444;
_550 = (unsigned long) [(void *) + 12B];
_568 = ~_550;
_525 = _110 + _568;
_524 = _525 >> 1;
_520 = _524 + 1;
_518 = _520 * 2;
__builtin_memcpy (d_434, [(void *) + 12B], _518);
The offset 12 in the MEM_REF corresponds to sizeof (decnumber).
compute_builtin_object_size() returns zero for [(void *) + 12B] and
_518's range is ~[1, 1], so either zero or 2 or more. The warning doesn't
consider the unlikely case of zero and treats the anti-range as [2, SIZE_MAX].
The missing location information suggests the memcpy call is the result of some
transformation. The reference to smsup implies it comes from this loop in
decNumberCopy() (the only function in the translation unit that defines the
smsup variable):
if (src->digits>3) {
const uint16_t *smsup, *s;
uint16_t *d;
d=dest->lsu+1;
smsup=src->lsu+((src->digits)<=49?d2utable[src->digits]:((src->digits)+3
-1)/3);
for (s=src->lsu+1; slsu+1 is past the end of the dnOne object but smsup has one of two
values: src->lsu + d2utable[src->digits] or src->lsu + 1, and the first one
doesn't look determinate because dnOne is also used as some sort of a temporary
by decNumberPower and its digits member (initially set to 1) is overwritten.
So the loop gets transformed into memcpy that reads some number other than 1
from an object of size zero.
Adding an assertion like in the otherwise untested patch below should let GCC
see that dnOne.digits is unchanged. I don't know enough about the library to
tell if that's actually correct or what the correct macro or value to use here
might be.
===
--- libdecnumber/decNumber.c(revision 270418)
+++ libdecnumber/decNumber.c(working copy)
@@ -2188,6 +2188,8 @@ decNumber * decNumberPower(decNumber *res, const d
}
/* [inv now points to big-enough buffer or allocated storage] */
decNumberCopy(inv, dac); /* copy the 1/lhs */
+ if (dnOne.digits > 1)
+ __builtin_unreachable ();
decNumberCopy(dac, ); /* restore acc=1 */
lhs=inv; /* .. and go forward with new lhs */
#if DECSUBSET
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug c/90123] "/usr/include/string.h", line 44: syntax error at token '__dest'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90123 --- Comment #2 from iris --- Hi Andrew, thank you so much for your comments! I tried cproto4.7m and I no longer see these errors.
[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410 --- Comment #21 from Jonny Grant --- Hi! In comment 9 I raised if #line 0 could be prevented please #line next_line_num So a line can only be >=1 as I understand it. Editors show files from line 1. There's no line 0 Godbolt can't show the error.. as it prevents showing line 0 that doesn't exist (files count from 1), and gcc shows the wrong code line highlighted. #line 0 #error 3 #error hello #1 with x86-64 gcc (trunk) : error: #error 3 :1:2: error: #error hello 1 | #line 0 | ^ Compiler returned: 1
[Bug c++/89949] Internal compiler error with lambda as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89949 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- This doesn't ICE for me.
[Bug translation/79183] Hard coded plurals in gimple-ssa-sprintf.c:2050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 46188 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46188=edit gcc9-pr79183.patch Untested fix for those two cases.
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #16 from Marek Polacek --- I'll keep poking for now, though I'm not sure what to do.
[Bug c++/89325] [7/8/9 Regression] False warnings about "optimization attribute" on operators when -fno-ipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89325 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Apr 17 19:24:55 2019 New Revision: 270422 URL: https://gcc.gnu.org/viewcvs?rev=270422=gcc=rev Log: PR c++/89325 * g++.dg/ext/attrib58.C: New test. * g++.dg/ext/attrib59.C: New test. * g++.dg/ext/attrib60.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/attrib58.C trunk/gcc/testsuite/g++.dg/ext/attrib59.C trunk/gcc/testsuite/g++.dg/ext/attrib60.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/90125] Typo of AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|jakub at redhat dot com| Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug target/90125] Typo of AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Apr 17 19:23:45 2019 New Revision: 270421 URL: https://gcc.gnu.org/viewcvs?rev=270421=gcc=rev Log: PR target/90125 * config/i386/avx512fintrin.h (_mm_maskz_fmadd_round_sd, _mm_maskz_fmadd_round_ss, _mm_maskz_fmsub_round_sd, _mm_maskz_fmsub_round_ss, _mm_maskz_fnmadd_round_sd, _mm_maskz_fnmadd_round_ss, _mm_maskz_fnmsub_round_sd, _mm_maskz_fnmsub_round_ss): Use _maskz builtin instead of _mask3. PR target/90125 * gcc.target/i386/avx512f-vfmsubXXXss-2.c (avx512f_test): Adjust constants to ensure precise result even when not using fma. * gcc.target/i386/avx512f-vfnmaddXXXss-2.c (avx512f_test): Likewise. * gcc.target/i386/avx512f-vfmaddXXXsd-3.c: New test. * gcc.target/i386/avx512f-vfmaddXXXss-3.c: New test. * gcc.target/i386/avx512f-vfmsubXXXsd-3.c: New test. * gcc.target/i386/avx512f-vfmsubXXXss-3.c: New test. * gcc.target/i386/avx512f-vfnmaddXXXsd-3.c: New test. * gcc.target/i386/avx512f-vfnmaddXXXss-3.c: New test. * gcc.target/i386/avx512f-vfnmsubXXXsd-3.c: New test. * gcc.target/i386/avx512f-vfnmsubXXXss-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-vfmaddXXXsd-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-vfmaddXXXss-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-vfmsubXXXsd-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-vfmsubXXXss-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-vfnmaddXXXsd-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-vfnmaddXXXss-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-vfnmsubXXXsd-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-vfnmsubXXXss-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/avx512f-vfmsubXXXss-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-vfnmaddXXXss-2.c
[Bug translation/79183] Hard coded plurals in gimple-ssa-sprintf.c:2050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
Roland Illig changed:
What|Removed |Added
CC||roland.illig at gmx dot de
--- Comment #6 from Roland Illig ---
Also in gimple-ssa-sprintf.c:
inform (callloc,
(min == 1
? G_("%qE output %wu byte")
: G_("%qE output %wu bytes")),
info.func, min);
inform (callloc,
(min == 1
? G_("%qE output %wu byte into a destination of size %wu")
: G_("%qE output %wu bytes into a destination of size "
"%wu")),
info.func, min, info.objsize);
[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Marek Polacek --- Fixed.
[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124 --- Comment #10 from Marek Polacek --- Author: mpolacek Date: Wed Apr 17 18:26:42 2019 New Revision: 270418 URL: https://gcc.gnu.org/viewcvs?rev=270418=gcc=rev Log: PR c++/90124 - bogus error with incomplete type in decltype. * typeck.c (build_class_member_access_expr): Check cp_unevaluated_operand. * g++.dg/cpp0x/decltype70.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype70.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #9 from Justin Bassett --- After more reflection, I do believe that ignoring attributes from unknown namespaces is one of the best options. My suggestion of whitelisting attributes falls apart when we consider how many attributes there may be. It's not unreasonable to expect that there could be 100s of unknown attributes, or at least around 30. Having to pass 30-100+ flags to whitelist each of those is not reasonable.
[Bug target/90125] Typo of AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/90047] [8/9 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90047 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #9 from Marek Polacek --- Thanks -- I just moved the "!cp_unevaluated_operand" check before dependent_type_p, as that's cheaper. Testing in progress.
[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124 --- Comment #8 from Jason Merrill --- (In reply to Marek Polacek from comment #7) > (In reply to Marek Polacek from comment #6) > > The operand of the decltype specifier is an unevaluated operand and perhaps > > we have to take that into account here. > > ...i.e., naming of objects does not, by itself, require that a definition be > provided. This should fix it: > > --- a/gcc/cp/typeck.c > +++ b/gcc/cp/typeck.c > @@ -2478,6 +2478,7 @@ build_class_member_access_expr (cp_expr object, tree > member, > must: we don't know how to refer to a base member before layout is > complete. But still don't complain in a template. */ > if (!dependent_type_p (object_type) > + && !cp_unevaluated_operand > && !complete_type_or_maybe_complain (object_type, object, >complain)) > return error_mark_node; Looks good.
[Bug bootstrap/90132] New: make bootstrap fails with -O3 (gcc9 snapshot 20190414)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132 Bug ID: 90132 Summary: make bootstrap fails with -O3 (gcc9 snapshot 20190414) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jayrusman at hotmail dot com Target Milestone: --- (I don't know what the correct 'component' is, please adjust as necessary.) On x86_64 with gcc9 snapshot 20190414 while building c,c++ targets, I noticed that -O2 works, but -O3 fails with: checking for vsprintf... checking whether byte ordering is bigendian... ../../gcc-9-20190414/libdecnumber/decNumber.c: In function 'decNumberPower': cc1: error: '__builtin_memcpy' reading 2 or more bytes from a region of size 0 [-Werror=stringop-overflow=] yes
[Bug tree-optimization/90078] [7/8/9 Regression] ICE with deep templates caused by overflow [PATCH]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078 --- Comment #8 from Walter Landry --- (In reply to Martin Liška from comment #5) > (In reply to bin cheng from comment #4) > > Another problem is the generated binary has segment fault issue even > > compiled O0: > > > > $ ./g++ -O0 pr90078.cc -o a.out -ftemplate-depth=100 -ftime-report -g > > -std=c++14 > > $ gdb --args ./a.out > > > > Dump of assembler code for function main(): > >0x00400572 <+0>: push %rbp > >0x00400573 <+1>: mov%rsp,%rbp > >0x00400576 <+4>: sub$0x2625a020,%rsp > >0x0040057d <+11>:lea-0x2625a020(%rbp),%rax > >0x00400584 <+18>:mov%rax,%rdi > > => 0x00400587 <+21>:callq 0x4006c0 > 100, 100>::Tensor4()> > >0x0040058c <+26>:lea-0x4c4b410(%rbp),%rax > >0x00400593 <+33>:lea-0xe4e1c10(%rbp),%rdx > > > > The segment fault happens at the callq instruction. > > Yes, same happens also for clang. It's a stack overflow: That is not surprising. The code recurses 1000 times. I would not consider crashing at runtime to be a bug.
[Bug target/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #9 from Martin Jambor --- I have only seen this when compiling with -march=native on Zen, but even at -O2 (which I overlooked yesterday, and which is also confirmed by LNT).
[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124 --- Comment #7 from Marek Polacek --- (In reply to Marek Polacek from comment #6) > The operand of the decltype specifier is an unevaluated operand and perhaps > we have to take that into account here. ...i.e., naming of objects does not, by itself, require that a definition be provided. This should fix it: --- a/gcc/cp/typeck.c +++ b/gcc/cp/typeck.c @@ -2478,6 +2478,7 @@ build_class_member_access_expr (cp_expr object, tree member, must: we don't know how to refer to a base member before layout is complete. But still don't complain in a template. */ if (!dependent_type_p (object_type) + && !cp_unevaluated_operand && !complete_type_or_maybe_complain (object_type, object, complain)) return error_mark_node;
[Bug c++/88330] Implement P0542R5, P1289R1, C++20 contract based programming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88330 --- Comment #1 from emsr at gcc dot gnu.org --- I saw this through reddit: https://gitlab.com/lock3/gcc-new.git branch origin/contracts-jac-kona This user has several interesting branches of contracts and concepts! Wiki: http://gummif.github.io/blog/contract_code_gen.html This Wiki is a 3rd party one. This is the wiki connected to the repo: https://gitlab.com/lock3/gcc-new/wikis/contract-assertions
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #61 from Jakub Jelinek --- At least looking at x86_64-linux gcc/deh.o, I really don't see any .text comdats, only data comdats, all STT_FUNC symbols are in the same section, except for the global ctors in .text.startup and dtors in .text.exit.
[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- The operand of the decltype specifier is an unevaluated operand and perhaps we have to take that into account here.
[Bug debug/90109] gstabs flag generates wrong entry for long on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109 --- Comment #5 from Jim Wilson --- Stabs requires that we emit info for all of the base types at the start. But if one of the base types does not exist for a 32-bit K C target, then we are struck, as that can't be described. And if we can't describe one or more of the base types, then we can't safely describe derived types. Currently, we just lie about the base types we can't describe, which lets us emit debug info for the derived types that we can describe. It is possible to describe some things as derived types that can't be described as base types. But if we aren't allowed to lie about base types, then we probably have to refuse to emit any debug info at all for the file, which doesn't help. You can get correct debug info for this testcase if you use stabs-plus-gdb-extensions. At least until you try to use some language feature invented in the last decade or two that we never added stabs-plus-gdb-extensions support for, and then you are screwed again. Which takes me back to don't use stabs again.
[Bug target/89146] arm: "nor" constraint prefers memory reference over constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89146 --- Comment #2 from Richard Earnshaw --- (In reply to Jakub Jelinek from comment #1) > I've looked for constraints that include [ijnIJKLMNO] together with [mo] and > couldn't find any. So, not really sure what note_invalid_constants is > supposed to handle (why would reload let a constant get through as constant > if it required only memory). GCC simply doesn't know how to deal with architectures that don't have unlimited offsets from the PC for the constant pool without generating stupidly bad code. So we run an additional pass late on to fix up constants that aren't valid by dumping them into 'minipools' that get inlined within the function code. We do this by using special constraints to handle this, knowing that the final pass will deal with them. All *real* patterns in the back-end can deal with this; but this artificial asm is confusing things. Perhaps for ASM insns we should just skip them entirely and assume that the user knows what they are doing, but I'm worried that users might somehow be relying on the existing behaviour.
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 --- Comment #9 from Ian Lance Taylor --- > I think the *end != '\0' check is the problem here. The temporary object is > gone at that point. Ah ha. Thanks.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #60 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #59)
> That looks like a D FE bug then.
> In any case, why can't you just use -mgeneral-regs-only on the deh.d
> compilation command line?
Could work, just anxious, that something in comdat segment depends on this
flag.
Another alternative would be to re-factor the code so that
CONTINUE_UNWINDING just returns _URC_CONTINUE_UNWIND,
and _only_ gdc_personality does call __gnu_unwind_frame and has the
@attribute("target", ("general-regs-only")).
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #7)
> (In reply to rsand...@gcc.gnu.org from comment #6)
>
> Thanks for handling this.
>
> > > template
> > > inline POLY_BINARY_COEFF (Ca, Ca)
> > > known_alignment (const poly_int_pod )
> > > {
> > > typedef POLY_BINARY_COEFF (Ca, Ca) C;
> > > C r = a.coeffs[0];
> > > for (unsigned int i = 1; i < N; ++i)
> > > r |= a.coeffs[i];
> > > return r & -r;
> > > }
> > >
> > > The poly_int* stuff makes this much harder to fix, it is unclear if there
> > > is
> > > some way to get the unsigned type for the C type and use that as r &
> > > -(Cuns)
> > > r;
> > > to avoid the UB, and there is no poly_uint_rtx_p or something to request
> > > poly_uint64 from the rtx. Richard?
> >
> > Changing:
> >
> > (unsigned HOST_WIDE_INT) known_alignment (const_op0)
> >
> > to:
> >
> > known_alignment (poly_uint64 (const_op0))
> >
> > should work.
>
> That will handle this specific case, I was just hoping that for
> known_alignment we could fix all the cases that could be called on
> poly_int64. For HOST_WIDE_INT_MIN, do we want known_alignment to return
> HOST_WIDE_INT_MIN or something different? It is maximum alignment
> admittedly only if we are treating the result as unsigned. Or shall we in
> known_alignment assert or compile time assert that it is unsigned and fix
> all the users?
A compile-time assert sounds good. Will try that on top to see how
invasive it ends up being. (Shouldn't be too bad, since there aren't
many callers.)
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #7 from Jakub Jelinek ---
(In reply to rsand...@gcc.gnu.org from comment #6)
Thanks for handling this.
> > template
> > inline POLY_BINARY_COEFF (Ca, Ca)
> > known_alignment (const poly_int_pod )
> > {
> > typedef POLY_BINARY_COEFF (Ca, Ca) C;
> > C r = a.coeffs[0];
> > for (unsigned int i = 1; i < N; ++i)
> > r |= a.coeffs[i];
> > return r & -r;
> > }
> >
> > The poly_int* stuff makes this much harder to fix, it is unclear if there is
> > some way to get the unsigned type for the C type and use that as r & -(Cuns)
> > r;
> > to avoid the UB, and there is no poly_uint_rtx_p or something to request
> > poly_uint64 from the rtx. Richard?
>
> Changing:
>
> (unsigned HOST_WIDE_INT) known_alignment (const_op0)
>
> to:
>
> known_alignment (poly_uint64 (const_op0))
>
> should work.
That will handle this specific case, I was just hoping that for known_alignment
we could fix all the cases that could be called on poly_int64. For
HOST_WIDE_INT_MIN, do we want known_alignment to return HOST_WIDE_INT_MIN or
something different? It is maximum alignment admittedly only if we are
treating the result as unsigned. Or shall we in known_alignment assert or
compile time assert that it is unsigned and fix all the users?
[Bug tree-optimization/90037] [9 Regression] -Wnull-dereference false positive after r269302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037 --- Comment #11 from Jeffrey A. Law --- That may be an interesting approach. I think we'd want the new blocks created by threading as well as the original blocks we threaded through since their in-degree gets reduced which in turn can expose new cprop opportunities. We'd have to somehow be able to mark or otherwise remember the blocks in question across a call to cfgcleanup so we'd know what SEME regions to optimize. But I guess missing one or more regions isn't fatal, it's "just" a missed optimization.
[Bug tree-optimization/87008] [8 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Jambor --- And fixed on the gcc-8-branch too.
[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85762 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Martin Jambor --- And fixed on the gcc-8-branch too.
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Jambor --- And fixed on the gcc-8-branch too.
[Bug tree-optimization/87008] [8 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008 --- Comment #12 from Martin Jambor --- Author: jamborm Date: Wed Apr 17 15:52:16 2019 New Revision: 270414 URL: https://gcc.gnu.org/viewcvs?rev=270414=gcc=rev Log: 2019-04-17 Martin Jambor Backport from mainline 2019-03-10 Martin Jambor PR tree-optimization/85762 PR tree-optimization/87008 PR tree-optimization/85459 * tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool it points to if there is a type changing MEM_REF. Adjust all callers. (build_accesses_from_assign): Disable total scalarization if contains_vce_or_bfcref_p returns true through the new parameter, for both rhs and lhs. testsuite/ * g++.dg/tree-ssa/pr87008.C: New test. * gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-ssa/pr87008.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/guality/pr54970.c branches/gcc-8-branch/gcc/tree-sra.c
[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85762 --- Comment #10 from Martin Jambor --- Author: jamborm Date: Wed Apr 17 15:52:16 2019 New Revision: 270414 URL: https://gcc.gnu.org/viewcvs?rev=270414=gcc=rev Log: 2019-04-17 Martin Jambor Backport from mainline 2019-03-10 Martin Jambor PR tree-optimization/85762 PR tree-optimization/87008 PR tree-optimization/85459 * tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool it points to if there is a type changing MEM_REF. Adjust all callers. (build_accesses_from_assign): Disable total scalarization if contains_vce_or_bfcref_p returns true through the new parameter, for both rhs and lhs. testsuite/ * g++.dg/tree-ssa/pr87008.C: New test. * gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-ssa/pr87008.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/guality/pr54970.c branches/gcc-8-branch/gcc/tree-sra.c
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 --- Comment #12 from Martin Jambor --- Author: jamborm Date: Wed Apr 17 15:52:16 2019 New Revision: 270414 URL: https://gcc.gnu.org/viewcvs?rev=270414=gcc=rev Log: 2019-04-17 Martin Jambor Backport from mainline 2019-03-10 Martin Jambor PR tree-optimization/85762 PR tree-optimization/87008 PR tree-optimization/85459 * tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool it points to if there is a type changing MEM_REF. Adjust all callers. (build_accesses_from_assign): Disable total scalarization if contains_vce_or_bfcref_p returns true through the new parameter, for both rhs and lhs. testsuite/ * g++.dg/tree-ssa/pr87008.C: New test. * gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-ssa/pr87008.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/guality/pr54970.c branches/gcc-8-branch/gcc/tree-sra.c
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #5)
> The first above is on:
> case MINUS:
> /* If X is (minus C Y) where C's least set bit is larger than any bit
> in the mask, then we may replace with (neg Y). */
> if (poly_int_rtx_p (XEXP (x, 0), _op0)
> && (unsigned HOST_WIDE_INT) known_alignment (const_op0) > mask)
> and
> template
> inline POLY_BINARY_COEFF (Ca, Ca)
> known_alignment (const poly_int_pod )
> {
> typedef POLY_BINARY_COEFF (Ca, Ca) C;
> C r = a.coeffs[0];
> for (unsigned int i = 1; i < N; ++i)
> r |= a.coeffs[i];
> return r & -r;
> }
>
> The poly_int* stuff makes this much harder to fix, it is unclear if there is
> some way to get the unsigned type for the C type and use that as r & -(Cuns)
> r;
> to avoid the UB, and there is no poly_uint_rtx_p or something to request
> poly_uint64 from the rtx. Richard?
Changing:
(unsigned HOST_WIDE_INT) known_alignment (const_op0)
to:
known_alignment (poly_uint64 (const_op0))
should work.
>
> The second one is
> return (!known_size_p (decl_size) || known_eq (decl_size, 0)
> ? maybe_ne (offset, 0)
> : maybe_gt (offset + size, decl_size));
> and again, both offset and size are poly_int64, not sure how can one
> reinterpret cast that to poly_uint64 for the operation and then cast back to
> poly_int64.
Normal casts between poly_X and poly_Y work if casts between X and Y work.
> But in that case also if we shouldn't punt on the overflow somehow.
I guess using known_subrange_p would do that.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #31 from Segher Boessenkool --- It's how you do a parallel of a mov and a flags set, which of course you can have before RA, and you want created by combine, typically. Or do I misunderstand the question? (I though Arm have a "movs" op for this, btw?)
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #18 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Wed Apr 17 15:40:12 2019 New Revision: 270413 URL: https://gcc.gnu.org/viewcvs?rev=270413=gcc=rev Log: gcc/ChangeLog: 2019-04-17 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): When handling vec_extract, use modular arithmetic to allow constant selectors greater than vector length. * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Allow V1TImode vectors to have constant selector values greater than 0. Use modular arithmetic to compute vector index. (rs6000_split_vec_extract_var): Use modular arithmetic to compute index for in-memory vectors. Correct code generation for in-register vectors. Use inner mode of vector rather than mode of destination for move instruction. (altivec_expand_vec_ext_builtin): Use modular arithmetic to compute index. 2019-04-12 Kelvin Nilsen PR target/87532 * config/rs6000/vsx.md (*vsx_extract__mode_var): Use QI inner mode with V16QI vector mode. gcc/testsuite/ChangeLog: 2019-04-17 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * gcc.target/powerpc/pr87532.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2.h: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2a.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2b.c: New test. * gcc.target/powerpc/vsx-builtin-10a.c: New test. * gcc.target/powerpc/vsx-builtin-10b.c: New test. * gcc.target/powerpc/vsx-builtin-11a.c: New test. * gcc.target/powerpc/vsx-builtin-11b.c: New test. * gcc.target/powerpc/vsx-builtin-12a.c: New test. * gcc.target/powerpc/vsx-builtin-12b.c: New test. * gcc.target/powerpc/vsx-builtin-13a.c: New test. * gcc.target/powerpc/vsx-builtin-13b.c: New test. * gcc.target/powerpc/vsx-builtin-14a.c: New test. * gcc.target/powerpc/vsx-builtin-14b.c: New test. * gcc.target/powerpc/vsx-builtin-15a.c: New test. * gcc.target/powerpc/vsx-builtin-15b.c: New test. * gcc.target/powerpc/vsx-builtin-16a.c: New test. * gcc.target/powerpc/vsx-builtin-16b.c: New test. * gcc.target/powerpc/vsx-builtin-17a.c: New test. * gcc.target/powerpc/vsx-builtin-17b.c: New test. * gcc.target/powerpc/vsx-builtin-18a.c: New test. * gcc.target/powerpc/vsx-builtin-18b.c: New test. * gcc.target/powerpc/vsx-builtin-19a.c: New test. * gcc.target/powerpc/vsx-builtin-19b.c: New test. * gcc.target/powerpc/vsx-builtin-20a.c: New test. * gcc.target/powerpc/vsx-builtin-20b.c: New test. * gcc.target/powerpc/vsx-builtin-9a.c: New test. * gcc.target/powerpc/vsx-builtin-9b.c: New test. 2019-03-19 Kelvin Nilsen PR target/89736 * gcc.target/powerpc/pr87532-mc.c: Modify dejagnu directives to restrict this test to vsx targets. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr87532-mc.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr87532.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2.h branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18a.c
[Bug target/89736] New test pr87532-mc.c fails on compiler not defaulting to VSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89736 --- Comment #5 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Wed Apr 17 15:40:12 2019 New Revision: 270413 URL: https://gcc.gnu.org/viewcvs?rev=270413=gcc=rev Log: gcc/ChangeLog: 2019-04-17 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): When handling vec_extract, use modular arithmetic to allow constant selectors greater than vector length. * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Allow V1TImode vectors to have constant selector values greater than 0. Use modular arithmetic to compute vector index. (rs6000_split_vec_extract_var): Use modular arithmetic to compute index for in-memory vectors. Correct code generation for in-register vectors. Use inner mode of vector rather than mode of destination for move instruction. (altivec_expand_vec_ext_builtin): Use modular arithmetic to compute index. 2019-04-12 Kelvin Nilsen PR target/87532 * config/rs6000/vsx.md (*vsx_extract__mode_var): Use QI inner mode with V16QI vector mode. gcc/testsuite/ChangeLog: 2019-04-17 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * gcc.target/powerpc/pr87532.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2.h: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2a.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2b.c: New test. * gcc.target/powerpc/vsx-builtin-10a.c: New test. * gcc.target/powerpc/vsx-builtin-10b.c: New test. * gcc.target/powerpc/vsx-builtin-11a.c: New test. * gcc.target/powerpc/vsx-builtin-11b.c: New test. * gcc.target/powerpc/vsx-builtin-12a.c: New test. * gcc.target/powerpc/vsx-builtin-12b.c: New test. * gcc.target/powerpc/vsx-builtin-13a.c: New test. * gcc.target/powerpc/vsx-builtin-13b.c: New test. * gcc.target/powerpc/vsx-builtin-14a.c: New test. * gcc.target/powerpc/vsx-builtin-14b.c: New test. * gcc.target/powerpc/vsx-builtin-15a.c: New test. * gcc.target/powerpc/vsx-builtin-15b.c: New test. * gcc.target/powerpc/vsx-builtin-16a.c: New test. * gcc.target/powerpc/vsx-builtin-16b.c: New test. * gcc.target/powerpc/vsx-builtin-17a.c: New test. * gcc.target/powerpc/vsx-builtin-17b.c: New test. * gcc.target/powerpc/vsx-builtin-18a.c: New test. * gcc.target/powerpc/vsx-builtin-18b.c: New test. * gcc.target/powerpc/vsx-builtin-19a.c: New test. * gcc.target/powerpc/vsx-builtin-19b.c: New test. * gcc.target/powerpc/vsx-builtin-20a.c: New test. * gcc.target/powerpc/vsx-builtin-20b.c: New test. * gcc.target/powerpc/vsx-builtin-9a.c: New test. * gcc.target/powerpc/vsx-builtin-9b.c: New test. 2019-03-19 Kelvin Nilsen PR target/89736 * gcc.target/powerpc/pr87532-mc.c: Modify dejagnu directives to restrict this test to vsx targets. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr87532-mc.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr87532.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2.h branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18a.c
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 maic changed: What|Removed |Added CC||maic23 at live dot de --- Comment #8 from maic --- Indeed this will be hit even when the own code has no issue, but qt headers are included. See also https://github.com/bitcoin/bitcoin/issues/15822
[Bug web/90127] Disable bugzilla [[wiki_links]] and don't confuse r12 register names with r12345 svn revisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90127 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- oh yeah this has been bothering me for a while now; good to see an effort to finally do something about it!
[Bug debug/90131] New: wrong debug info at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90131
Bug ID: 90131
Summary: wrong debug info at -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
This issue is similar to bug 90074 --- same flag, same gcc versions. The
bisection also points to r255267. It appears that the issue remains after the
patch.
$ gcc-trunk -v
gcc version 9.0.1 20190417 (experimental) [trunk revision 270407] (GCC)
$ gdb -v
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
#Wrong result#
$ gcc-trunk -g abc.c outer.c -O3
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x40040f: file abc.c, line 16.
Breakpoint 1, main () at abc.c:16
16optimize_me_not();
$1 = 9
#Correct result#
$ gcc-trunk -g abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x4004c8: file abc.c, line 16.
Breakpoint 1, main () at abc.c:16
16optimize_me_not();
$1 = 0
$ cat abc.c
volatile long a;
int b[9][1];
static short c[2][1] = {3};
int main() {
int i, d, e;
i = 0;
for (; i < 9; i++)
a = b[i][0];
i = 0;
for (; i < 2; i++) {
d = 0;
for (; d < 1; d++) {
e = 0;
for (; e < 1; e++)
a = c[i][e];
optimize_me_not();
}
}
}
$ cat outer.c
void optimize_me_not() {}
$ cat cmds
b 16
r
p i
kill
q
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #8 from Florian Weimer --- (In reply to Ian Lance Taylor from comment #7) > > What is the condition i > 0x7fff for? Shouldn't that test val instead? > > Yes, it certainly should. Thanks. It's not the problem here, but should be > fixed. > > > Just a wild guess - does this->body_.substr(start, i - start).c_str() > really live until after strtol has completed? > > I *think* it should be OK. The rule in C++ is that temporary objects are > destroyed after the full expression that lexically contains the point at > which they are created has been evaluated. In this case the full expression > is the call to strtol, so the temporary object created by the call to substr > should live until the call to strtol is complete. I think the *end != '\0' check is the problem here. The temporary object is gone at that point.
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 --- Comment #7 from Ian Lance Taylor --- > What is the condition i > 0x7fff for? Shouldn't that test val instead? Yes, it certainly should. Thanks. It's not the problem here, but should be fixed. > Just a wild guess - does this->body_.substr(start, i - start).c_str() really live until after strtol has completed? I *think* it should be OK. The rule in C++ is that temporary objects are destroyed after the full expression that lexically contains the point at which they are created has been evaluated. In this case the full expression is the call to strtol, so the temporary object created by the call to substr should live until the call to strtol is complete.
[Bug d/90130] New: gdc.test/runnable/test12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130
Bug ID: 90130
Summary: gdc.test/runnable/test12.d FAILs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc*-*-solaris2.11
The gdc.test/runnable/test12.d test FAILs on Solaris 11/SPARC with Robin's
big-endian
patches applied:
FAIL: gdc.test/runnable/test12.d -finline-functions -funittest -g execution
test
core.exception.AssertError@runnable/test12.d(630): Assertion failure
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gcc/deh.d:499 _d_throw
[0x1001bb58f]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:441
onAssertError [0x1001b880b]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:641
_d_assert [0x1001b8e13]
runnable/test12.d:630 int test12.hoge(test12.S29) [0x100112ddf]
runnable/test12.d:642 void test12.test29() [0x100112e4b]
runnable/test12.d:1220 _Dmain [0x100114fc7]
Thread 2 hit Breakpoint 1, test12.hoge(test12.S29) (s=...)
at runnable/test12.d:624
624 char[10] b;
(gdb) n
625 printf("%x\n", s);
(gdb) p s
$1 = {a = 1 '\001', b = 2 '\002', c = 3 '\003', d = 4 '\004'}
(gdb) n
ffbfe4d0
626 sprintf(b.ptr, "%x", s);
(gdb) n
630 assert(b[0 .. 7] == "1020304");
(gdb) p b
$2 = "ffbfe4d0\000\377"
This ia another call-by-value vs. call-by-reference issue: the test assumes
that passing a small struct (struct S29) happens by value. While this is true
in some ABIs, it's certainly not in others (like the 32-bit SPARC one) where
even small structs are passed by reference. PR d/90079 is another instance
of the same problem.
(gdb) p/x *
$11 = {a = 0x1, b = 0x2, c = 0x3, d = 0x4}
(gdb) p s
$12 = {a = 1 '\001', b = 2 '\002', c = 3 '\003', d = 4 '\004'}
(gdb) p/x *(int *)
$13 = 0x1020304
However, the test also FAILs on 64-bit SPARC where small structs *are* passed
by value:
(gdb) p s
$1 = {a = 1 '\001', b = 2 '\002', c = 3 '\003', d = 4 '\004'}
(gdb) p b
$2 = "\000\000\000\000\000\000\000\000\000"
(gdb) n
625 printf("%x\n", s);
(gdb) n
0
626 sprintf(b.ptr, "%x", s);
(gdb) n
630 assert(b[0 .. 7] == "1020304");
(gdb) p b
$3 = "0\000\377\377\377\377\377\377\377\377"
(gdb) p/x *(int *)
$9 = 0x1020304
I don't fully see why yet, however all this strongly argues that this part of
testcase is bogus: you cannot pass a struct to sprintf whose format string
expects an int.
[Bug d/90130] gdc.test/runnable/test12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #59 from Jakub Jelinek --- That looks like a D FE bug then. In any case, why can't you just use -mgeneral-regs-only on the deh.d compilation command line?
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #58 from Bernd Edlinger ---
No, sorry, the attribute on the prototype gets ignored, as the following
is compiled without generating an error:
private int test(double x)
{
return x > 1.0;
}
static if (GNU_ARM_EABI_Unwinder)
{
@attribute("target", ("general-regs-only"))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception*
unwindHeader,
_Unwind_Context* context);
}
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
const(ubyte)* lsda;
_Unwind_Ptr landingPad;
_Unwind_Word cfa;
int handler;
test(3.14);
// Shortcut for phase 2 found handler for domestic exception.
if (actions == (_UA_CLEANUP_PHASE | _UA_HANDLER_FRAME)
&& isGdcExceptionClass(exceptionClass))
{
ExceptionHeader.restore(unwindHeader, handler, lsda, landingPad, cfa);
but with the previous patch calling test(3.14) gives this:
../../../../gcc-trunk/libphobos/libdruntime/gcc/deh.d: In function
'__gdc_personality':
../../../../gcc-trunk/libphobos/libdruntime/gcc/deh.d:906:1: error: argument of
type 'double' not permitted with -mgeneral-regs-only
906 | test(3.14);
| ^
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #30 from Jakub Jelinek --- Is the *movsi_compare0 pattern actually ever a benefit before RA? At least in this case it clearly results in a worse generated code rather than better, and I bet in other cases too, it just ties the hands of the RA too much. I wonder if it better shouldn't be a pattern that is only matched when reload_completed and recognized say by a peephole2 or something similar.
[Bug target/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #8 from Richard Biener --- (In reply to Richard Biener from comment #7) > Benchmarking r270408 on branch vs. trunk on Haswell doesn't show any > regression > for me. Will double-check with up-to-date CPU 2017 tree. Confirmed.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #20 from Martin Liška ---
>
> Does this mean that if I have an avx512bw+dq function, I'd have to have two
> identical versions of it that I have to target with arch=canonlake and
> arch=amd-something-with-avx512? Seems a bit... unellegant.
>
If you use target_clone attribute of target attribute in C++ (with
automatically generated resolver function), then yes. You'll need 2 functions,
but you can use alias as seen here:
void xxx () { __builtin_printf ("haswell or skylake CPU\n"); }
void __attribute__ ((target("arch=haswell"),alias("_Z3xxxv"))) foo ();
void __attribute__ ((target("arch=skylake-avx512"),alias("_Z3xxxv"))) foo ();
void __attribute__ ((target("arch=skylake"))) foo () {}
void __attribute__ ((target("default"))) foo () {}
int main()
{
foo ();
return 0;
}
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #6 from rguenther at suse dot de ---
On Wed, 17 Apr 2019, ian at airs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
>
> --- Comment #4 from Ian Lance Taylor ---
> Thanks for the file. Unfortunately it looks fine.
>
> The error is coming from Import_function_body::read_type in
> gcc/go/gofrontend/import.cc. At the point of the error this->body_ +
> this->off_ points to a string starting with ",". The function starts
> like this:
>
> this->require_c_string(" size_t start = this->off_;
> size_t i;
> int c = '\0';
> for (i = start; i < this->body_.length(); ++i)
> {
> c = static_cast(this->body_[i]);
> if (c != '-' && (c < '0' || c > '9'))
> break;
> }
> this->off_ = i + 1;
>
> char *end;
> long val = strtol(this->body_.substr(start, i - start).c_str(), , 10);
Just a wild guess - does this->body_.substr(start, i - start).c_str()
really live until after strtol has completed? IIRC I saw this kind
of errors in other codes... since the temporary std::string isn't
passed to the function it should be destroyed. Assuming this->body_
is a std::string, of course.
Using profiledbootstrap might just expose this "issue" I guess.
Trying whether
Index: gcc/go/gofrontend/import.cc
===
--- gcc/go/gofrontend/import.cc (revision 270403)
+++ gcc/go/gofrontend/import.cc (working copy)
@@ -1478,7 +1478,8 @@ Import_function_body::read_type()
this->off_ = i + 1;
char *end;
- long val = strtol(this->body_.substr(start, i - start).c_str(), ,
10);
+ std::string subs = this->body_.substr(start, i - start);
+ long val = strtol(subs.c_str(), , 10);
if (*end != '\0' || i > 0x7fff)
{
if (!this->saw_error_)
fixes the issue for me (will report back tomorrow). Just in case
this is indeed an obvious error feel free to fix faster than that ;)
[Bug middle-end/90095] [9 Regression] wrong code with -Os -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Apr 17 13:28:39 2019 New Revision: 270410 URL: https://gcc.gnu.org/viewcvs?rev=270410=gcc=rev Log: PR middle-end/90095 * internal-fn.c (expand_mul_overflow): Don't set SUBREG_PROMOTED_VAR_P on lowpart SUBREGs. * gcc.dg/pr90095-1.c: New test. * gcc.dg/pr90095-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr90095-1.c trunk/gcc/testsuite/gcc.dg/pr90095-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c trunk/gcc/testsuite/ChangeLog
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 --- Comment #5 from Andreas Schwab --- What is the condition i > 0x7fff for? Shouldn't that test val instead?
[Bug target/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 Richard Biener changed: What|Removed |Added Component|tree-optimization |target --- Comment #7 from Richard Biener --- Benchmarking r270408 on branch vs. trunk on Haswell doesn't show any regression for me. Will double-check with up-to-date CPU 2017 tree.
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #4 from Ian Lance Taylor ---
Thanks for the file. Unfortunately it looks fine.
The error is coming from Import_function_body::read_type in
gcc/go/gofrontend/import.cc. At the point of the error this->body_ +
this->off_ points to a string starting with ",". The function starts
like this:
this->require_c_string("off_;
size_t i;
int c = '\0';
for (i = start; i < this->body_.length(); ++i)
{
c = static_cast(this->body_[i]);
if (c != '-' && (c < '0' || c > '9'))
break;
}
this->off_ = i + 1;
char *end;
long val = strtol(this->body_.substr(start, i - start).c_str(), , 10);
if (*end != '\0' || i > 0x7fff)
{
if (!this->saw_error_)
go_error_at(this->location(),
"invalid export data for %qs: expected integer at %lu",
this->name().c_str(),
static_cast(start));
this->saw_error_ = true;
return Type::make_error_type();
}
It skips ",". It steps past the "4".
Then it passes "4\0" to strtol. Somehow that is failing.
Since, needless to say, I can't reproduce the problem, do you have time to add
a bit of debugging around the strtol call, to see what is being passed and
returned?
[Bug target/90129] Wrong error: inlining failed in call to always_inline ‘_mm256_adds_epi16’: target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This one is because of: /* See if arch, tune, etc. are the same. */ else if (caller_opts->arch != callee_opts->arch) ret = false; For tune we ignore it if always_inline, the question is what should we do for arch for always_inline. I'm afraid we don't have a notion of arches being subset or superset of each other.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929 --- Comment #19 from Nikolay Bogoychev --- (In reply to Martin Liška from comment #18) > (In reply to Martin Liška from comment #17) > > > > > > @Martin: > > > > > > Thank you for the detailed answer. This could work for now. I have a few > > > questions about it: > > > > > > Wouldn't that create issues in the future if AMD decide to release avx512 > > > for their CPUs? > > > > No, that will only require to add target(arch=amd-name-with-avx512). > > Does this mean that if I have an avx512bw+dq function, I'd have to have two identical versions of it that I have to target with arch=canonlake and arch=amd-something-with-avx512? Seems a bit... unellegant. > > > > > > > Cheers, > > > > > > Nick > > > > Let me investigate that. Thanks for opening the bug Cheers, Nick
[Bug d/88150] Use sections_elf_shared.d on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150 --- Comment #16 from Martin Nowak --- Regarding the dlopen/dlclose in handleForName, the semantics of RTLD_NOLOAD are so that it bumps the reference count if the library had been previously loaded. The sections module uses the handle as identifier to distinguish different DSOs and store metadata. Due to the self-registration mechanism of D DSOs (see _d_dso_registry) any D library remains loaded and (presumably) keeps the same handle if it is needed by the executable and loaded during startup. If a shared library is loaded dynamically, then the dlopen/dlclose actions will surround the calls to _d_dso_registry by the library, hence the handle should stay valid while until the DSO is unregistered. This is a lot of low-level plumbing (without going into private runtime linker structs) and semantics have been modeled after Linux and FreeBSD. If they differ on Solaris the code might indeed need some fixup. The RTLD_NOLOAD behavior of only inc-refing already loaded libs isn't well documented but seems like the only sensible one.
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #6 from Richard Biener --- (In reply to Richard Biener from comment #5) > CPU 2006 436.cactusADM also has an interesting history: > https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/ > 436_cactusADM_big.png compared to other benchmarks it is also quite noisy - esp. in the timeframe of this regression.
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #5 from Richard Biener --- CPU 2006 436.cactusADM also has an interesting history: https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/436_cactusADM_big.png
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #57 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #56)
> Can't you just add prototypes?
> Like:
> static if (GNU_ARM_EABI_Unwinder)
> {
> @attribute("target", ("general-regs-only"))
> private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
> _Unwind_Exception_Class
> exceptionClass,
> _Unwind_Exception*
> unwindHeader,
> _Unwind_Context* context);
> }
> etc. before the actual definitions? attribute ("", ("")) seems ugly.
I think that is worth a try. hang on...
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #56 from Jakub Jelinek ---
Can't you just add prototypes?
Like:
static if (GNU_ARM_EABI_Unwinder)
{
@attribute("target", ("general-regs-only"))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
_Unwind_Context* context);
}
etc. before the actual definitions? attribute ("", ("")) seems ugly.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #55 from Bernd Edlinger ---
But, how about that:
Index: deh.d
===
--- deh.d (revision 270395)
+++ deh.d (working copy)
@@ -28,6 +28,7 @@
import gcc.unwind.pe;
import gcc.builtins;
import gcc.config;
+import gcc.attribute;
extern(C)
{
@@ -519,10 +520,21 @@
terminate("unwind error", __LINE__);
}
+static if (GNU_ARM_EABI_Unwinder)
+{
+enum ATTRIBUTE_NAME = "target";
+enum ATTRIBUTE_ARGS = "general-regs-only";
+}
+else
+{
+enum ATTRIBUTE_NAME = "";
+enum ATTRIBUTE_ARGS = "";
+}
/**
* Read and extract information from the LSDA (.gcc_except_table section).
*/
+@attribute(ATTRIBUTE_NAME, (ATTRIBUTE_ARGS))
_Unwind_Reason_Code scanLSDA(const(ubyte)* lsda, _Unwind_Exception_Class
exceptionClass,
_Unwind_Action actions, _Unwind_Exception*
unwindHeader,
_Unwind_Context* context, _Unwind_Word cfa,
@@ -772,6 +784,7 @@
* Called when the personality function has found neither a cleanup or
handler.
* To support ARM EABI personality routines, that must also unwind the stack.
*/
+@attribute(ATTRIBUTE_NAME, (ATTRIBUTE_ARGS))
_Unwind_Reason_Code CONTINUE_UNWINDING(_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
static if (GNU_ARM_EABI_Unwinder)
@@ -814,6 +827,7 @@
static if (GNU_ARM_EABI_Unwinder)
{
pragma(mangle, PERSONALITY_FUNCTION)
+@attribute(ATTRIBUTE_NAME, (ATTRIBUTE_ARGS))
extern(C) _Unwind_Reason_Code gdc_personality(_Unwind_State state,
_Unwind_Exception*
unwindHeader,
_Unwind_Context* context)
@@ -873,6 +887,7 @@
}
}
+@attribute(ATTRIBUTE_NAME, (ATTRIBUTE_ARGS))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #54 from Bernd Edlinger ---
Hmm, I see. What I am trying to accomplish is, put the target
attribute on every function that calls directly or in-directly
to CONTINUE_UNWINDING. And do that only for ARM.
For gdc_personality it is straight forward to do, as you pointed out.
But for __gdc_personality and scanLSDA what I would like to do is
static if (GNU_ARM_EABI_Unwinder)
{
@attribute("target", ("general-regs-only"))
}
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
...
but that does not work, what would work is
static if (GNU_ARM_EABI_Unwinder)
{
@attribute("target", ("general-regs-only"))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
...
}
}
else
{
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
...
}
}
duplicating all that code is of course not an option.
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- (In reply to Richard Biener from comment #2) > Ugh. Cactus is really ugly code :/ For one there's an invariant switch () > in the innermost loop, expanded to a binary tree (slightly different split > point > GCC 8 vs. trunk), obviously unswitching cannot handle this. Yes, the binary tree is bit different, but equally good to me: GCC 8: if (fdOrder_15741 == 4) goto ; [20.00%] else goto ; [80.00%] [local count: 955630223]: if (fdOrder_15741 > 4) goto ; [62.50%] else goto ; [37.50%] [local count: 955630223]: if (fdOrder_15741 == 2) goto ; [66.67%] else goto ; [33.33%] [local count: 955630223]: if (fdOrder_15741 == 6) goto ; [40.00%] else goto ; [60.00%] [local count: 955630223]: if (fdOrder_15741 == 8) goto ; [66.67%] else goto ; [33.33%] GCC 9: if (fdOrder_13024 == 6) goto ; [20.00%] else goto ; [80.00%] [local count: 955630224]: if (fdOrder_13024 > 6) goto ; [37.50%] else goto ; [62.50%] [local count: 955630224]: if (fdOrder_13024 == 2) goto ; [40.00%] else goto ; [60.00%] [local count: 955630224]: if (fdOrder_13024 == 4) goto ; [100.00%] else goto ; [0.00%] [local count: 955630224]: if (fdOrder_13024 == 8) goto ; [66.67%] else goto ; [33.33%]
[Bug target/90129] Wrong error: inlining failed in call to always_inline ‘_mm256_adds_epi16’: target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129 --- Comment #1 from Richard Biener --- IIRC we have a duplicate for this (albeit with -msse2 vs. none)
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #3 from Martin Liška --- Direct graph link to branch comparison: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=148.437.0=59.437.0=76.437.0=33.437.0;
[Bug target/90129] New: Wrong error: inlining failed in call to always_inline ‘_mm256_adds_epi16’: target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129
Bug ID: 90129
Summary: Wrong error: inlining failed in call to always_inline
‘_mm256_adds_epi16’: target specific option mismatch
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Following code should be accepted:
$ cat pragma.c
#include
#include
#include
#pragma GCC target ("arch=haswell")
__m256i adds_epi16(__m256i first, __m256i second) {
return _mm256_adds_epi16(first, second);
}
But we reject that since for ever:
gcc pragma.c
In file included from
/usr/lib64/gcc/x86_64-suse-linux/8/include/immintrin.h:43,
from pragma.c:3:
pragma.c: In function ‘adds_epi16’:
/usr/lib64/gcc/x86_64-suse-linux/8/include/avx2intrin.h:140:1: error: inlining
failed in call to always_inline ‘_mm256_adds_epi16’: target specific option
mismatch
_mm256_adds_epi16 (__m256i __A, __m256i __B)
^
pragma.c:8:10: note: called from here
return _mm256_adds_epi16(first, second);
^~~~
While:
cat pragma.c && gcc pragma.c -march=haswell -c
#include
#include
#include
__m256i adds_epi16(__m256i first, __m256i second) {
return _mm256_adds_epi16(first, second);
}
is fine
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #18 from Martin Liška ---
(In reply to Martin Liška from comment #17)
> >
> > @Martin:
> >
> > Thank you for the detailed answer. This could work for now. I have a few
> > questions about it:
> >
> > Wouldn't that create issues in the future if AMD decide to release avx512
> > for their CPUs?
>
> No, that will only require to add target(arch=amd-name-with-avx512).
>
> >
> > In case we are using C style target annotation (and not function
> > multi-versioning), should we also use target(arch=skylake-avx512) instead of
> > target(avx512bw)?
For C style, the functionality will be preserved as is.
>
> Yes. Let me discuss that with H.J.
>
> >
> > Also it seems that target("arch=foo") fails for my simple example with
> > target specific option mismatch error (but works in clang).
> >
> > If I change target to avx2 it compiles again.
This looks to me a bug, I'll create a separated PR for that.
Thanks
> >
> > Cheers,
> >
> > Nick
>
> Let me investigate that.
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #2 from Richard Biener --- Ugh. Cactus is really ugly code :/ For one there's an invariant switch () in the innermost loop, expanded to a binary tree (slightly different split point GCC 8 vs. trunk), obviously unswitching cannot handle this. This is a general missed optimization precluding any vectorization attempt here. Then we spill the hell out of us because of the way the code is written. Other than that I don't see anything obvious here. It might be that trunk: 5802: 83 fb 06cmp$0x6,%ebx 5805: 0f 84 25 84 00 00 je dc30 <_ZL19ML_BSSN_Advect_BodyPK4 _cGHiiPKdS3_S3_PKiS5_iPKPd+0xdc30> 580b: 0f 8f cf 1d 00 00 jg 75e0 <_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0x75e0> 5811: 83 fb 02cmp$0x2,%ebx 5814: 0f 85 06 c0 ff ff jne1820 <_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0x1820> is worse to the branch predictor than the GCC 8 version 89ee: 0f 84 bc 64 00 00 je eeb0 <_ZL19ML_BSSN_Advect_BodyPK4 _cGHiiPKdS3_S3_PKiS5_iPKPd+0xeeb0> 89f4: 0f 8e 96 45 00 00 jlecf90 <_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0xcf90> 89fa: 8b b4 24 a8 08 00 00mov0x8a8(%rsp),%esi 8a01: 83 fe 06cmp$0x6,%esi 8a04: 0f 85 e6 8e ff ff jne18f0 <_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0x18f0> (notice the "padding" reload). That is probably going to depend on final code layout again of course. I recall reading a third conditional jump in a fetch word requires an additional branch predictor slot or so. So it would be interesting to see if the branch misses accumulate on that binary tree generated from the loop invariant switch where in theory those should be all totally predictable. That said, I'm not yet able to reproduce the slowdown but will try.
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-17 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- So the issue is in ML_BSSN_Advect_Body (the other function rebounded). I will have a look.
[Bug target/79869] i18n: document placeholders for translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869 --- Comment #3 from Claudiu Zissulescu --- DOC is string that shortly describes an machine dependent option. This string is used to throw an warning/error when the underling option is not available for a specific architecture, which can be arcem, arc700, arc6xx or archs. The DOC definitions are in arc/arc-options.def The arches name are defined in arc/arc-arches.def
[Bug tree-optimization/90128] New: 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 Bug ID: 90128 Summary: 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux In my own measurements, 507.cactuBSSN_r is about 9.4% slower on an AMD Zen CPU when compiled with GCC 9 with -Ofast and native march/mtune than when it si compiled with GCC 8. LNT currently even shows 11.4% regression: https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch I have done some bisecting and the slowdown happened in three steps. First, the benchmark slowed by about 2% at some point before r262510 which I have not tracked down yet. Second, it then dived 3% with r263874 but this seems to be some code-placement issue again because the assembly of the functions which gained perf samples has not changed in that revision and perf reported stalled-cycles-frontend went from 4.58% to 5.02%. However, the third regression was caused by the immediately following revision r263875, the difference is 4.5% (7.5% is compared to GCC 8 run-time) while perf reported stalled-cycles-frontend were only 4.05%. r263872 (good) perf stat and report: Performance counter stats for 'numactl -C 0 -l specinvoke': 238848.989836 task-clock:u (msec) #0.999 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 92923 page-faults:u #0.389 K/sec 758195547230 cycles:u #3.174 GHz (83.33%) 34727040659 stalled-cycles-frontend:u #4.58% frontend cycles idle (83.33%) 15457735869 stalled-cycles-backend:u #2.04% backend cycles idle (83.33%) 1225370192228 instructions:u#1.62 insn per cycle #0.03 stalled cycles per insn (83.33%) 23031544594 branches:u# 96.427 M/sec (83.34%) 18985096 branch-misses:u #0.08% of all branches (83.33%) 239.158442295 seconds time elapsed # Event count (approx.): 758374775503 # # OverheadSamples Command Shared Object Symbol # . . . # 40.51% 387505 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_RHS_Body 22.34% 214782 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_Advect_Body 8.42% 80594 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_constraints_Body 7.40% 70897 cactusBSSN_r libm-2.26.so __ieee754_exp_avx 5.77% 55393 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_convertToADMBaseDtLapseShift_Body 4.99% 47952 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_convertToADMBase_Body 2.98% 28573 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_InitRHS_Body 2.44% 23623 cactusBSSN_r cactusBSSN_r_peak MoL_LinearCombination r263874 (worse) perf stat and report: Performance counter stats for 'numactl -C 0 -l specinvoke': 244036.523777 task-clock:u (msec) #0.999 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 93013 page-faults:u #0.381 K/sec 774757677736 cycles:u #3.175 GHz (83.33%) 38930288027 stalled-cycles-frontend:u #5.02% frontend cycles idle (83.33%) 15508961324 stalled-cycles-backend:u #2.00% backend cycles idle (83.34%) 1226167776333 instructions:u#1.58 insn per cycle #0.03 stalled cycles per insn (83.33%) 23218262947 branches:u# 95.143 M/sec (83.33%) 18890390 branch-misses:u #0.08% of all branches (83.33%) 244.344340731 seconds time elapsed # Samples: 979K of event 'cycles' # Event count (approx.): 775138268715 # # OverheadSamples Command Shared Object Symbol # . . . # 41.43% 404835 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_RHS_Body
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #17 from Martin Liška ---
>
> @Martin:
>
> Thank you for the detailed answer. This could work for now. I have a few
> questions about it:
>
> Wouldn't that create issues in the future if AMD decide to release avx512
> for their CPUs?
No, that will only require to add target(arch=amd-name-with-avx512).
>
> In case we are using C style target annotation (and not function
> multi-versioning), should we also use target(arch=skylake-avx512) instead of
> target(avx512bw)?
Yes. Let me discuss that with H.J.
>
> Also it seems that target("arch=foo") fails for my simple example with
> target specific option mismatch error (but works in clang).
>
> If I change target to avx2 it compiles again.
>
> Cheers,
>
> Nick
Let me investigate that.
[Bug translation/90120] inconsistent punctuation in translation messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120 --- Comment #3 from Claudiu Zissulescu --- Added a patch to solve upper/lower issue: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00696.html
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #16 from Nikolay Bogoychev ---
Created attachment 46187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46187=edit
target("arch=foo") doesn't work
(In reply to Martin Liška from comment #15)
> @Nikolay:
>
> As discussed in https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00416.html
> email thread, we reached the following consensus with H.J:
>
> - As any AVX512 extensions (apart from AVX512F) can be enabled individually,
> it's difficult to come up with priorities in dispatcher.
> - We don't have a syntax for target_clone attribute where one would say e.g.
> avx512f+avx512cd+avx512er.
> - So that we would reject these (AVX512* except AVX512F) in target_clone
> attribute and we recommend to use rather.
> target_clones(arch=skylake,arch=skylake-avx512,arch=cannonlake,arch=icelake-
> client,arch=icelake-server, ..)
> - Using that one can cover used AVX512 ISA combinations for existing CPUs
>
> Does it work for you Nikolay?
@Martin:
Thank you for the detailed answer. This could work for now. I have a few
questions about it:
Wouldn't that create issues in the future if AMD decide to release avx512 for
their CPUs?
In case we are using C style target annotation (and not function
multi-versioning), should we also use target(arch=skylake-avx512) instead of
target(avx512bw)?
Also it seems that target("arch=foo") fails for my simple example with target
specific option mismatch error (but works in clang).
If I change target to avx2 it compiles again.
Cheers,
Nick
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
The first above is on:
case MINUS:
/* If X is (minus C Y) where C's least set bit is larger than any bit
in the mask, then we may replace with (neg Y). */
if (poly_int_rtx_p (XEXP (x, 0), _op0)
&& (unsigned HOST_WIDE_INT) known_alignment (const_op0) > mask)
and
template
inline POLY_BINARY_COEFF (Ca, Ca)
known_alignment (const poly_int_pod )
{
typedef POLY_BINARY_COEFF (Ca, Ca) C;
C r = a.coeffs[0];
for (unsigned int i = 1; i < N; ++i)
r |= a.coeffs[i];
return r & -r;
}
The poly_int* stuff makes this much harder to fix, it is unclear if there is
some way to get the unsigned type for the C type and use that as r & -(Cuns) r;
to avoid the UB, and there is no poly_uint_rtx_p or something to request
poly_uint64 from the rtx. Richard?
The second one is
return (!known_size_p (decl_size) || known_eq (decl_size, 0)
? maybe_ne (offset, 0)
: maybe_gt (offset + size, decl_size));
and again, both offset and size are poly_int64, not sure how can one
reinterpret cast that to poly_uint64 for the operation and then cast back to
poly_int64.
But in that case also if we shouldn't punt on the overflow somehow.
