[Bug bootstrap/92699] Slash should be removed from C/C++ plugin install destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92699 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-28 CC||dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- OK, so almost all other uses of $(DESTDIR) do not have a following '/' character so the proposed change sounds quite obvious. All cases containing '$(DESTDIR)/': ./gcc/c/Make-lang.in: $(INSTALL_DATA) cc1$(exeext).a $(DESTDIR)/$(plugin_resourcesdir)/cc1$(exeext).a ./gcc/jit/ChangeLog.jit:"$(DESTDIR)/$(libdir)/pkgconfig". ./gcc/jit/Make-lang.in: $(DESTDIR)/$(libdir)/$(LIBGCCJIT_FILENAME) ./gcc/jit/Make-lang.in: $(DESTDIR)/$(libdir)/$(LIBGCCJIT_SONAME_SYMLINK) ./gcc/jit/Make-lang.in: $(DESTDIR)/$(libdir)/$(LIBGCCJIT_LINKER_NAME_SYMLINK) ./gcc/jit/Make-lang.in: $(DESTDIR)/$(includedir)/libgccjit.h ./gcc/jit/Make-lang.in: $(DESTDIR)/$(includedir)/libgccjit++.h ./gcc/cp/Make-lang.in: $(INSTALL_DATA) cc1plus$(exeext).a $(DESTDIR)/$(plugin_resourcesdir)/cc1plus$(exeext).a David - most of them are in libjit, would you please take care of adjusting those and also the rest and do some testing (you seem to play with plugins as well recently ;)). The other '/' in libjit are probably similarly bogus. Thanks.
[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123 --- Comment #21 from paul.richard.thomas at gmail dot com --- Hi All, I took one of the other fn_spec's as a template - it might well have been internal_pack. Thanks for looking at this. Cheers Paul On Mon, 25 Nov 2019 at 13:04, jakub at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123 > > --- Comment #15 from Jakub Jelinek --- > I think other fn spec attributes in trans-decl.c should be checked. > E.g. for internal_pack, I see ".r", when the function sometimes returns a > pointer to a field pointed by the first argument. The address of the > descriptor doesn't escape then, but there is indirect escape. What about > internal_unpack? > Both cfi_desc_to_gfc_desc and gfc_desc_to_cfi_desc should be ".w." as Richi > said. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug preprocessor/92696] #pragma GCC diagnostic ... interferes with if/else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Biener --- Not a bug then.
[Bug bootstrap/92699] Slash should be removed from C/C++ plugin install destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92699 Richard Biener changed: What|Removed |Added Keywords||build Host||MinGW-w64 --- Comment #1 from Richard Biener --- Hmm, I think people just call make install DESTDIR=/foo/bar without a trailing slash so we do need some kind of dir separator or canonicalization of DESTDIR?
[Bug c++/92700] wrong "unintialized" warning with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92700 Richard Biener changed: What|Removed |Added Keywords||diagnostic Blocks||24639 --- Comment #1 from Richard Biener --- We at least do have other PRs complaining about std::optional Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 Roman Zhuykov changed: What|Removed |Added Attachment #47379|0 |1 is obsolete|| --- Comment #4 from Roman Zhuykov --- Created attachment 47386 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47386=edit Proposed patch v2 Found a mistake in previous patch
[Bug target/92566] rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Kewen Lin --- Fixed.
[Bug target/92566] rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 --- Comment #13 from Kewen Lin --- Author: linkw Date: Thu Nov 28 06:34:31 2019 New Revision: 278800 URL: https://gcc.gnu.org/viewcvs?rev=278800=gcc=rev Log: [rs6000] Fix PR92566 by checking VECTOR_UNIT_NONE_P As Segher pointed out in PR92566, we shouldn't offer some vector modes which aren't supported under current setting. This patch is to make it check by VECTOR_UNIT_NONE_P which is initialized as current architecture masks. 2019-11-28 Kewen Lin PR target/92566 * gcc/config/rs6000/rs6000.c (rs6000_preferred_simd_mode): Check by VECTOR_UNIT_NONE_P instead. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #20 from Daniel Marjamäki ---
(In reply to Segher Boessenkool from comment #15)
> (In reply to Daniel Marjamäki from comment #12)
> > So, how would you fix the warning for `f`? Many programmers would "fix" it
> > with a cast.
> >
> > Assuming that `s` and `u` can have arbitrary values, here is the proper
> > code:
> >
> > void f(long s, unsigned long u) { if (s >= 0 && s == u) g(); }
> >
> > For this correct code, gcc warns.
>
> A much better fix is
>
> void f1(long s, unsigned long u) { unsigned long su = s; if (su == u) g(); }
>
> which makes it rather explicit what is going on.
>
> Still much better is to not mixed signedness in types at all.
Ping. Your "much better" code does not work. This code prints "equal" on the
screen:
void f1(long s, unsigned long u) {
unsigned long su = s;
if (su == u) printf("equal\n");
}
int main() { f1(-1L, ~0UL); return 0; }
Please try again.
You proved my point somewhat. The programmer gets a warning, the programmer
tries to fix it, the code still has the same bug but the warning has gone away.
However I feel that your fix is much safer than a cast because Cppcheck,
sanitizers, etc can still warn.
[Bug tree-optimization/92689] Improve stmt_may_clobber_ref_p_1 on constant memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92689 --- Comment #6 from Feng Xue --- Good case. I did missed something, a const pointer does not imply it is restrict and for a real const data, we can even create a non-const pointer alias to it by using explicit type cast.
[Bug c++/92675] sign-conversion C++ unsigned int j = -1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675 --- Comment #5 from Jonny Grant --- I tried godbolt trunk again for C++ today with -Wsign-conversion and it does give a warning. I can only think I made a mistake while checking - unless a patch has just gone in?
[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692 --- Comment #6 from Andrew Pinski --- (In reply to Wilco from comment #5) > Well I'm looking at the latest version > (https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.pdf) where in > figure B2-5 it explicitly states that a store that does not match the > reservation granule on the same CPU must not change the exclusive state. > > However if a store does match the granule it is implementation defined, > hence the reason for the text you quote to guarantee forward progress - > otherwise a random store in the loop could accidentally match the exclusive > granule and block progress. However I don't see it saying anywhere that all > stores must clear the exclusive state. That is for the global monitor which yes is depdenent on the granule. But the local monitor is taken into account too and you missed that. As mentioned in Section B2.9.2: "For shareable memory locations, exclusive access instructions rely on: • A local monitor for each PE in the system, that marks any address from which the PE executes a Load-Exclusive." The local monitor is described in B2.9.1 and figure B2-4 which has the following note about the local monitor state machine: "The IMPLEMENTATION DEFINED options for the local monitor are consistent with the local monitor being constructed so that it does not hold any PA, but instead treats any access as matching the address of the previous Load-Exclusive instruction."
[Bug fortran/92701] ICE assigning to assumed rank derived type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92701 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-27 CC||burnus at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Tobias Burnus --- No regression as 'select rank' is new. In gfc_check_vardef_context, assoc->variable == NULL and assoc->target == NULL [this one causes the segfault] and assoc->st->name == "__tmp_class___class_a_R_15_0t_rank_1" On the other hand, e->symtree->n.sym->assoc->target exists and e->symtree->n.sym->assoc->target->symtree == assoc->st. assoc gets set (ll. 6213–6219) as: gfc_expr* t = sym->assoc->target; gcc_assert (t->expr_type == EXPR_VARIABLE); name = t->symtree->name; if (t->symtree->n.sym->assoc) assoc = t->symtree->n.sym->assoc; else assoc = sym->assoc; That's sufficient for: gcc_assert (name && assoc); But then it fails when doing: assoc->target->expr_type (That's for !assoc->variable – but also the else branch assumes that assoc->target != NULL.)
[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692 --- Comment #5 from Wilco --- (In reply to Andrew Pinski from comment #4) > (In reply to Wilco from comment #3) > > (In reply to Andrew Pinski from comment #2) > > > I think this has been a latent bug since revision 243200: > > > [AArch64] Separate shrink wrapping hooks implementation > > > > > > I think aarch64_disqualify_components would be a location which should > > > disqualify the Separate for the register 19. > > > > What is the "exclusives reservation granule" size? It could only fail if the > > granule is large and the spill happens to be in the same granule as the > > stxr. > NO "exclusives reservation granule" does not matter here, please read the > ARMv8 spec again copied below (B2-142): > LoadExcl/StoreExcl loops are guaranteed to make forward progress only if, > for any LoadExcl/StoreExcl loop > within a single thread of execution, the software meets all of the following > conditions: > 1 Between the Load-Exclusive and the Store-Exclusive, there are no > explicit memory accesses, > preloads, direct or indirect System register writes, address translation > instructions, cache or TLB > maintenance instructions, exception generating instructions, exception > returns, or indirect branches. > --- CUT > > no explicit memory accesses > Is a requirement so it does not matter what "exclusives reservation granule" > size is really. > We had gone through this beforehand with the ARM architectures and made sure > that the specifications was worded correctly to the above effect. The > wording change happened in 2016. Well I'm looking at the latest version (https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.pdf) where in figure B2-5 it explicitly states that a store that does not match the reservation granule on the same CPU must not change the exclusive state. However if a store does match the granule it is implementation defined, hence the reason for the text you quote to guarantee forward progress - otherwise a random store in the loop could accidentally match the exclusive granule and block progress. However I don't see it saying anywhere that all stores must clear the exclusive state.
[Bug rtl-optimization/90007] [9/10 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007 --- Comment #14 from Vladimir Makarov --- (In reply to Segher Boessenkool from comment #13) > Does that work? You cannot put all hard registers in memory I think? > Or do we require that and it is just not documented? It depends on insns. For example, if insn only requires memory operand but we have hard register instead, we spill it into memory. Generally speaking I think we can "invent" an architecture where such feature may result in problems. But the same possible for other aspects of LRA/reload work. In practice, I believe it is not a problem for real architectures.
[Bug fortran/92701] New: ICE assigning to assumed rank derived type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92701 Bug ID: 92701 Summary: ICE assigning to assumed rank derived type component Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following code causes an ICE with gfortran 10.0 (r278783): module a type :: r end type r type, extends(r) :: rr double precision:: d end type rr contains subroutine abd(p) implicit none class(r), intent(inout), dimension(..) :: p double precision, dimension(:), allocatable :: d select rank (p) rank (1) select type (p) type is (rr) allocate(d(size(p,dim=1))) d=0.0d0 p%d=d end select end select return end subroutine abd end module a $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib : (reconfigured) ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --disable-multilib --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.0 20191127 (experimental) (GCC) $ gfortran -c bug.F90 -o bug.o f951: internal compiler error: Segmentation fault 0xdd4adf crash_signal ../../gcc-trunk/gcc/toplev.c:328 0x7fa79dd101ef ??? /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x7d41a1 gfc_check_vardef_context(gfc_expr*, bool, bool, bool, char const*) ../../gcc-trunk/gcc/fortran/expr.c:6237 0x84cff7 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:11768 0x8508b7 resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:17180 0x83c2ce gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:17215 0x83c2ce gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:17194 0x84cc58 resolve_block_construct ../../gcc-trunk/gcc/fortran/resolve.c:10549 0x84cc58 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:11899 0x84ef43 gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:10691 0x84fa0b resolve_select_type ../../gcc-trunk/gcc/fortran/resolve.c:9544 0x84cbe1 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:11891 0x84ef43 gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:10691 0x84c3b8 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:11654 0x8508b7 resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:17180 0x8507ee resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:17163 0x83c2ce gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:17215 0x83c2ce gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:17194 0x82f078 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:6443 0x87f30f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:210 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. The ICE seems to be triggered by the "p%d=d" assignment.
[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206 --- Comment #12 from Jason Merrill --- Author: jason Date: Wed Nov 27 22:05:41 2019 New Revision: 278784 URL: https://gcc.gnu.org/viewcvs?rev=278784=gcc=rev Log: PR c++/92206 - ICE with typedef to dependent alias. rsandifo's patch for 92206 demonstrated a problem with the existing checking for alias template specializations: they were returning false for a typedef to an alias template specialization. Which is sometimes what the caller wants, and sometimes not: Sometimes we're interested in whether the type was written as an alias template-id, and sometimes whether it represents one. The testcase illustrates a case that remained wrong with the earlier patch: if the typedef is itself an alias template specialization, we can't strip an underlying dependent alias. * pt.c (dependent_alias_template_spec_p) (alias_template_specialization_p): Add transparent_typedefs parameter. (iterative_hash_template_arg, any_template_parm_r) (primary_template_specialization_p, tsubst, dependent_type_p_r): Adjust. * decl.c (check_elaborated_type_specifier): Adjust. * error.c (dump_template_bindings, dump_aggr_type): Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-pr92206-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c
[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692 --- Comment #4 from Andrew Pinski --- (In reply to Wilco from comment #3) > (In reply to Andrew Pinski from comment #2) > > I think this has been a latent bug since revision 243200: > > [AArch64] Separate shrink wrapping hooks implementation > > > > I think aarch64_disqualify_components would be a location which should > > disqualify the Separate for the register 19. > > What is the "exclusives reservation granule" size? It could only fail if the > granule is large and the spill happens to be in the same granule as the stxr. NO "exclusives reservation granule" does not matter here, please read the ARMv8 spec again copied below (B2-142): LoadExcl/StoreExcl loops are guaranteed to make forward progress only if, for any LoadExcl/StoreExcl loop within a single thread of execution, the software meets all of the following conditions: 1 Between the Load-Exclusive and the Store-Exclusive, there are no explicit memory accesses, preloads, direct or indirect System register writes, address translation instructions, cache or TLB maintenance instructions, exception generating instructions, exception returns, or indirect branches. --- CUT no explicit memory accesses Is a requirement so it does not matter what "exclusives reservation granule" size is really. We had gone through this beforehand with the ARM architectures and made sure that the specifications was worded correctly to the above effect. The wording change happened in 2016.
[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #3 from Wilco --- (In reply to Andrew Pinski from comment #2) > I think this has been a latent bug since revision 243200: > [AArch64] Separate shrink wrapping hooks implementation > > I think aarch64_disqualify_components would be a location which should > disqualify the Separate for the register 19. What is the "exclusives reservation granule" size? It could only fail if the granule is large and the spill happens to be in the same granule as the stxr. I guess it's easy to fix by delaying the expansion or inserting a clobber of x19 before the loop starts.
[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #10 from Peter Bergner --- The commit above fixes the bootstrap issue. However, we still have an issue with the testsuite test case dtstsfi-0.c. That test case calls a builtin function that overloads one of the DFP builtins we skipped defining with per this commit. The current code uses standin types rather than DFP types, so we do not recognize that DFP has been disabled.
[Bug c++/92411] conformance issue with reinterpret_cast in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92411 --- Comment #1 from Darrell Wright --- sorry, posted incorrect CE link, but code below demonstrates it
[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695 Jakub Jelinek changed: What|Removed |Added Attachment #47383|0 |1 is obsolete|| --- Comment #9 from Jakub Jelinek --- Created attachment 47385 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47385=edit gcc10-pr92695-2.patch Oops, the second patch I've attached was the same as the first one, instead of this one.
[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695 --- Comment #8 from Jakub Jelinek --- Created attachment 47384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47384=edit gcc10-pr92695-3.patch That is another bug.
[Bug c++/92700] New: wrong "unintialized" warning with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92700
Bug ID: 92700
Summary: wrong "unintialized" warning with std::optional
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
#include
#include
int e;
template std::optional f ()
{
if (auto i = std::string ().find ('a'))
return i;
return { };
}
int main ()
{
size_t j = 1;
while (j)
{
auto i = f ();
if (e != 1 && e != 4 && e != 7)
throw 0;
if (i)
j = *i;
}
}
% g++-9 --version
g++-9 (GCC) 9.1.0
% g++-9 --std=c++17 test.cpp -Wall -O3
test.cpp: In function 'int main()':
test.cpp:10:12: warning: '' may be used uninitialized in this
function [-Wmaybe-uninitialized]
This may be a duplicate, but I can't really tell since this warning seems to
depend on many seemingly unrelated conditions, e.g. f must be a template,
std::string::find seems required (at least a simple external function won't
do),
the seemingly unrelated test of e is required (and must contain at least
3 clauses with specific values -- 1, 2, 3 won't do).
[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190 --- Comment #10 from rsandifo at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #8) > (In reply to Liu Hao from comment #7) > > MSDN says 'the upper portions of YMM0-15 and ZMM0-15 are considered volatile > > and must be considered destroyed on function calls' explicitly [1]. > > > > I am not clear about the cause of OP's ICE, but I think it should conform to > > MSABI to emit VZEROUPPER in the epilog, followed by restoring XMM6 - XMM15, > > destroying their upper halves. Similar with the prolog. > > The insertion of vzeroupper is not "invisible" to stack frame management > code any more, since vzeroupper is now defined as: > > (insn 738 619 434 2 (parallel [ > (unspec_volatile [ > (const_int 0 [0]) > ] UNSPECV_VZEROUPPER) > (clobber (reg:V2DI 20 xmm0)) > (clobber (reg:V2DI 21 xmm1)) > (clobber (reg:V2DI 22 xmm2)) > (clobber (reg:V2DI 23 xmm3)) > (clobber (reg:V2DI 24 xmm4)) > (clobber (reg:V2DI 25 xmm5)) > (set (reg:V2DI 26 xmm6) > (reg:V2DI 26 xmm6)) > (clobber (reg:V2DI 27 xmm7)) > (clobber (reg:V2DI 44 xmm8)) > (clobber (reg:V2DI 45 xmm9)) > (clobber (reg:V2DI 46 xmm10)) > (clobber (reg:V2DI 47 xmm11)) > (clobber (reg:V2DI 48 xmm12)) > (clobber (reg:V2DI 49 xmm13)) > (clobber (reg:V2DI 50 xmm14)) > (clobber (reg:V2DI 51 xmm15)) > ]) "pr92190.c":8:3 -1 > (nil)) > > > . The insertion point of vzeroupper pass is just after reload pass, and now > all xmm registers (xmm0 - xmm15) become live. This is not a problem in SYSV > ABI, where all registers are call_used, but in MS ABI, the prologue now > tries to save xmm6 - xmm15 to the stack. > > So, vzeroupper should be described in a way that won't trigger saves of xmm6 > - xmm15 to the stack, while still mark that high part of the register is > clobbered. Ah, OK. It should be safe to leave out a clobber if !df_regs_ever_live_p and if we're guaranteed not to introduce new references to the register later.
[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661 --- Comment #9 from Peter Bergner --- Author: bergner Date: Wed Nov 27 20:55:56 2019 New Revision: 278783 URL: https://gcc.gnu.org/viewcvs?rev=278783=gcc=rev Log: Do not define DFP builtin functions, if DFP has been disabled. PR bootstrap/92661 * config/rs6000/rs6000-call.c: (def_builtin): Do not define the builtin if we don't have an actual type. (builtin_function_type): If the builtin function uses a DFP type and decimal float has been disabled, then return NULL_TREE. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-call.c
[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190 --- Comment #9 from Uroš Bizjak --- (In reply to Liu Hao from comment #7) > MSDN says 'the upper portions of YMM0-15 and ZMM0-15 are considered volatile > and must be considered destroyed on function calls' explicitly [1]. BTW: MSDN is clear that xMM16-31 are volatile (call_used), so the current definition of CALL_USER_REGISTERS is wrong. At least this part should be: Index: i386.h === --- i386.h (revision 278455) +++ i386.h (working copy) @@ -1126,9 +1126,9 @@ /*xmm8,xmm9,xmm10,xmm11,xmm12,xmm13,xmm14,xmm15*/ \ 6, 6,6,6,6,6,6,6, \ /*xmm16,xmm17,xmm18,xmm19,xmm20,xmm21,xmm22,xmm23*/\ - 6,6, 6,6,6,6,6,6, \ + 1,1, 1,1,1,1,1,1, \ /*xmm24,xmm25,xmm26,xmm27,xmm28,xmm29,xmm30,xmm31*/\ - 6,6, 6,6,6,6,6,6, \ + 1,1, 1,1,1,1,1,1, \ /* k0, k1, k2, k3, k4, k5, k6, k7*/\ 1, 1, 1, 1, 1, 1, 1, 1 }
[Bug c/92699] New: Slash should be removed from C/C++ plugin install destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92699 Bug ID: 92699 Summary: Slash should be removed from C/C++ plugin install destination Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: brechtsanders at users dot sourceforge.net Target Milestone: --- I was trying to GCC with the --enable-plugin parameter on Windows with MinGW-w64. There was an error in the installation which I was able to solve by fixing gcc/c/Make-lang.in and gcc/cp/Make-lang.in with this command: sed -i.bak -e "s?\(\$(DESTDIR)\)/\(\$(plugin_resourcesdir)\)?\1\2?" gcc/c/Make-lang.in gcc/cp/Make-lang.in Basically the slash in $(DESTDIR)/$(plugin_resourcesdir) should be removed, so this reads as $(DESTDIR)$(plugin_resourcesdir), which is how it was done in the line above it that makes the directory if needed. Otherwise the path starts with 2 slashes, which on Windows would make it a UNC path instead of a local path. I can image this probably worked on almost any other OS.
[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661 Segher Boessenkool changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #8 from Segher Boessenkool --- Assigning this to Peter.
[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190 --- Comment #8 from Uroš Bizjak --- (In reply to Liu Hao from comment #7) > MSDN says 'the upper portions of YMM0-15 and ZMM0-15 are considered volatile > and must be considered destroyed on function calls' explicitly [1]. > > I am not clear about the cause of OP's ICE, but I think it should conform to > MSABI to emit VZEROUPPER in the epilog, followed by restoring XMM6 - XMM15, > destroying their upper halves. Similar with the prolog. The insertion of vzeroupper is not "invisible" to stack frame management code any more, since vzeroupper is now defined as: (insn 738 619 434 2 (parallel [ (unspec_volatile [ (const_int 0 [0]) ] UNSPECV_VZEROUPPER) (clobber (reg:V2DI 20 xmm0)) (clobber (reg:V2DI 21 xmm1)) (clobber (reg:V2DI 22 xmm2)) (clobber (reg:V2DI 23 xmm3)) (clobber (reg:V2DI 24 xmm4)) (clobber (reg:V2DI 25 xmm5)) (set (reg:V2DI 26 xmm6) (reg:V2DI 26 xmm6)) (clobber (reg:V2DI 27 xmm7)) (clobber (reg:V2DI 44 xmm8)) (clobber (reg:V2DI 45 xmm9)) (clobber (reg:V2DI 46 xmm10)) (clobber (reg:V2DI 47 xmm11)) (clobber (reg:V2DI 48 xmm12)) (clobber (reg:V2DI 49 xmm13)) (clobber (reg:V2DI 50 xmm14)) (clobber (reg:V2DI 51 xmm15)) ]) "pr92190.c":8:3 -1 (nil)) . The insertion point of vzeroupper pass is just after reload pass, and now all xmm registers (xmm0 - xmm15) become live. This is not a problem in SYSV ABI, where all registers are call_used, but in MS ABI, the prologue now tries to save xmm6 - xmm15 to the stack. So, vzeroupper should be described in a way that won't trigger saves of xmm6 - xmm15 to the stack, while still mark that high part of the register is clobbered. An alternative would be to consider the mode of call_used register and save only wide (> 128bits) registers in the caller. I'm not sure if the current implementation already clobbers the high part of the 256bit register.
[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695
--- Comment #7 from Toni Neubert ---
First of all thank you very much for your extremly fast help!
I testet the patch and it did work for my second example.
But this one still fails, if we do not use the addressof function:
struct A {
virtual int get() = 0;
};
struct B : A {
constexpr int get() override {
return 10;
}
};
struct D {
B b[2];
A* c{&(b[0])};
};
static_assert(D{}.c->get() == 10);
Error:
main.cpp:20:28: error: non-constant condition for static assertion
20 | static_assert(D{}.c->get() == 10);
| ~^
main.cpp:20:28: error: expression 'A::get' is not a constant expression
[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692 Andrew Pinski changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- I think this has been a latent bug since revision 243200: [AArch64] Separate shrink wrapping hooks implementation I think aarch64_disqualify_components would be a location which should disqualify the Separate for the register 19.
[Bug fortran/92698] New: Unnecessary copy in overlapping array assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92698 Bug ID: 92698 Summary: Unnecessary copy in overlapping array assignment Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mjr19 at cam dot ac.uk Target Milestone: --- subroutine cpy(a,src,dest,len) integer, intent(in) :: src,dest,len real(kind(1d0)), intent(inout) :: a(:) a(dest:dest+len-1)=a(src:src+len-1) end subroutine cpy seems to compile to malloc tmp array, inline copy to tmp, inline copy from tmp, free tmp in gfortran 7.4 and 8.3. Gfortran 9.2 modifies this by replacing the inline copies with memcpy at -O3. Fortran permits the source and destination to overlap, so a single call to memcpy would be wrong. However, it is always possible to do an overlapping copy in place either by incrementing from the start or by decrementing from the end, as glibc's memmove does. The use of a temporary array, whilst given as an example in the Fortran standard to illustrate that overlap is permitted, seems in practice unnecessary. Would it not be better to call memmove once rather than memcpy twice? Or perhaps a single inline copy, direction to be determined by the nature of the overlap? (Above observations from Linux / x86_64)
[Bug preprocessor/92696] #pragma GCC diagnostic ... interferes with if/else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Also #pragma are considered statements. There is another issue like this > but instead using _Pragma . I should say some Pragmas are considered statements. See PR 90400 Which shows the similar issue but with _Pragma. In this case, these Pragmas are considered statements.
[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692 --- Comment #1 from Andrew Pinski --- >it turns out the issue is a gcc issue and a glibc issue. NOTE I had missed out a word here: This should have read: it turns out the issue is a gcc issue and NOT a glibc issue.
[Bug tree-optimization/92596] [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92596 --- Comment #10 from rsandifo at gcc dot gnu.org --- Since it's been a while since the last update: I've been trying various non-invasive ways of fixing it, but even if they seem to be strict improvements, they still leave open obvious traps of a similar nature for later. I think we'll just have to get rid of the special deferred handling of boolean_type_node and stop computing so much of this stuff on the fly. I'm now testing a series of patches to do that.
[Bug ipa/92697] IPA-SRA modifies ifunc_resolvers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92697 --- Comment #1 from Martin Jambor --- And for the record, I'm testing a patch.
[Bug lto/91273] [8/9/10 Regression] ICE in warn_types_mismatch at ipa-devirt.c:995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91273 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 91222 ***
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #30 from Martin Liška --- *** Bug 91273 has been marked as a duplicate of this bug. ***
[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661 Joseph S. Myers changed: What|Removed |Added CC||green at redhat dot com --- Comment #7 from Joseph S. Myers --- *** Bug 92694 has been marked as a duplicate of this bug. ***
[Bug target/92694] Can't build powerpc-eabi cross compiler: : fatal error: internal error: builtin function ‘__builtin_ddedpd’ had an unexpected return type ‘DD’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92694 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Joseph S. Myers --- Duplicate. *** This bug has been marked as a duplicate of bug 92661 ***
[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695 --- Comment #6 from Jakub Jelinek --- Created attachment 47383 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47383=edit gcc10-pr92695.patch And here is a fix for the bogus warning. inline or constexpr on pure virtual functions looks useless, but the standard doesn't disallow that it seems.
[Bug rtl-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283 --- Comment #25 from rguenther at suse dot de --- On November 27, 2019 2:36:38 PM GMT+01:00, "vmakarov at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283 > >--- Comment #24 from Vladimir Makarov --- >(In reply to Richard Biener from comment #23) >> Vladimir, can you look into this LRA inheritance issue? > >Yes, I've started to work on this. I can not reproduce it on the >current >trunk. But yesterday, I've reproduced it on the revision mentioned in >the >title. > >Inheritance problems are usually hard to fix. So I can not say when I >find a >reason for the problem and solution for it. But I guess it will be >fixed on >the next week Heh, no problem. It took me a week to nail down the actual issue as well...
[Bug target/92693] Inconsistency between __UINTPTR_TYPE__ and __UINT32_TYPE__ on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92693 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Andrew Pinski --- Or just use the foundalmential types instead. And then layer above them.
[Bug preprocessor/92696] #pragma GCC diagnostic ... interferes with if/else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696 --- Comment #2 from Andrew Pinski --- Also #pragma are considered statements. There is another issue like this but instead using _Pragma .
[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695 Jakub Jelinek changed: What|Removed |Added Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 47382 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47382=edit gcc10-pr92695.patch Untested fix.
[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510 --- Comment #8 from rsandifo at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #7) > As Jakub mentioned in comment 1, the native_encode_rtx ICE is coming > from the call: > > simplify_subreg (DImode, const1_rtx, V1DImode, 0) >// (outermode, op, innermode, byte) > > i.e. the caller is claiming that the inner const1_rtx has mode V1DI. > And that can't be true, because vector constants have to be const_vectors > rather than const_ints. (The combination of outermode, innermode and op I meant "byte" rather than "op" :-) > are fine of course. The problem is "just" that the given innermode > doesn't match the inner rtx.)
[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510 --- Comment #7 from rsandifo at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #5) > (In reply to Jakub Jelinek from comment #4) > > I don't mind if simplify_subreg doesn't call native_encode_rtx in the cases > > where it ICEs and instead fails. > > I don't think native_encode_rtx (or simplify_immed_subreg) should ICE for > any valid input. This is valid input, for this API. As Jakub mentioned in comment 1, the native_encode_rtx ICE is coming from the call: simplify_subreg (DImode, const1_rtx, V1DImode, 0) // (outermode, op, innermode, byte) i.e. the caller is claiming that the inner const1_rtx has mode V1DI. And that can't be true, because vector constants have to be const_vectors rather than const_ints. (The combination of outermode, innermode and op are fine of course. The problem is "just" that the given innermode doesn't match the inner rtx.) So IMO the ICE is justified and we shouldn't change change simplify_subreg to handle cases in which innermode doesn't tally with op/GET_MODE (op).
[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Nov 27 16:32:54 2019 New Revision: 278777 URL: https://gcc.gnu.org/viewcvs?rev=278777=gcc=rev Log: PR rtl-optimization/92510 * combine.c (gen_lowpart_for_combine): Only transform lowpart subreg of comparison into a comparison with different mode if both imode and omode are scalar integral modes. * gcc.dg/pr92510.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr92510.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 --- Comment #7 from Jakub Jelinek --- Either the function guarantees that *seq will be always non-NULL (at least if the call doesn't return negative), but then there is no point in using out && *out, you can as well just use *out, because out will never be NULL. Or the function doesn't guarantee it and if it is NULL, the code will crash.
[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 --- Comment #6 from Roman Zhuykov --- Ok, this seems quite clear from compiler developer point of view. But I still want to add, that for compiler user, who knows how asprintf function works, "Line A" version is correct and warning seems unnecessary. While "Line B" version where user forget about bail-out is compiled smoothly.
[Bug ipa/92697] New: IPA-SRA modifies ifunc_resolvers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92697 Bug ID: 92697 Summary: IPA-SRA modifies ifunc_resolvers Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: jamborm at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 47381 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47381=edit testcase In the attached testcase, IPA-SRA thinks that an ifunc resolver (meanwhile IPA-split into two functions) function can be changed and so goes ahead. The cgraph machinery then however throws away the new clone of the caller instead of the "old" caller and inliner inlines the clone of the ".part" function into the original resolver, which results into an interesting miscompilation because IPA-SRA counted on that both the caller and the callee are modified. In any event, changing the signature of an ifunc resolver must not be done.
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 --- Comment #3 from Roman Zhuykov --- Created attachment 47380 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47380=edit Parameters patch
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 --- Comment #2 from Roman Zhuykov --- Created attachment 47379 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47379=edit Proposed patch
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 Roman Zhuykov changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-27 Assignee|unassigned at gcc dot gnu.org |zhroma at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Roman Zhuykov --- Oops, it seems that non-zero sms-dfa-history is untested since modulo-sched was added in 2004. This bugs is latent since r177235 in 2011, and logic is similar to bug 84032 comment #4. When we schedule some insn into row R we check that DFA can't see any conflicts in rows R-H .. R+H (modulo II), where H=sms-dfa-history. So, when we schedule branch into row R some of its neighbours were not yet scheduled and DFA tells OK. While scheduling neighbours DFA may check some nearby rows, for example, rows [R+1-H .. R+1+H] or something like that, but not exactly [R-H .. R+H]. Later we decide to temporarily remove branch insn from schedule and are pretty sure we could put it back (if rescheduling to another row fails). And this time DFA shows a conflict, because now all branch neighbours are scheduled already. Attached untested patch fixes this by running extra DFA checks for all rows [x-H..x+H] where X is any value in range [R-H,R+H], thus eliminating the issue. Certainly, these checks are expensive enough, so I also prepated a patch about modulo-sched params, which will set max sms-dfa-history value to 16. While at it, the patch also fixes other issues about sms parameters.
[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695
--- Comment #4 from Jakub Jelinek ---
To be precise, I meant something like:
--- gcc/cp/constexpr.c.jj 2019-11-27 10:03:37.916867165 +0100
+++ gcc/cp/constexpr.c 2019-11-27 16:55:17.475150697 +0100
@@ -1441,6 +1441,22 @@ cxx_bind_parameters_in_call (const const
arg = adjust_temp_type (type, arg);
if (!TREE_CONSTANT (arg))
*non_constant_args = true;
+ if (i == 0
+ && DECL_VIRTUAL_P (fun))
+ {
+ tree addr = arg;
+ STRIP_NOPS (addr);
+ if (TREE_CODE (addr) == ADDR_EXPR)
+ {
+ tree obj = TREE_OPERAND (addr, 0);
+ while (TREE_CODE (obj) == COMPONENT_REF
+&& DECL_FIELD_IS_BASE (TREE_OPERAND (obj, 1)))
+ obj = TREE_OPERAND (obj, 0);
+ if (obj != TREE_OPERAND (addr, 0))
+ arg = build_fold_addr_expr_with_type (obj,
+ TREE_TYPE (arg));
+ }
+ }
TREE_VEC_ELT (binds, i) = arg;
}
parms = TREE_CHAIN (parms);
This fixes the testcase. Note, there is still a weird warning:
pr92695.C:3:25: warning: inline function ‘virtual constexpr int A::set(A*)’
used but never defined
3 | constexpr virtual int set (A *o) = 0;
| ^~~
[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190 Liu Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #7 from Liu Hao --- MSDN says 'the upper portions of YMM0-15 and ZMM0-15 are considered volatile and must be considered destroyed on function calls' explicitly [1]. I am not clear about the cause of OP's ICE, but I think it should conform to MSABI to emit VZEROUPPER in the epilog, followed by restoring XMM6 - XMM15, destroying their upper halves. Similar with the prolog. [1] https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019#callercallee-saved-registers
[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #4)
> Sure, before that we would punt much earlier at simplification of the
> non-sensical subreg.
We probably should again then?
> I don't mind if simplify_subreg doesn't call native_encode_rtx in the cases
> where it ICEs and instead fails.
I don't think native_encode_rtx (or simplify_immed_subreg) should ICE for
any valid input. This is valid input, for this API.
> But, I believe what gen_lowpart_for_combine does for comparisons is
> completely wrong for non-scalar modes that are different from their previous
> mode.
> A same sized subreg of something is reinterpretation of the bits of
No. A subreg of "something" is just invalid RTL. But this isn't about
subregs, it's about lowpart, and I don't see how it is wrong there?
> something as something else, VIEW_CONVERT_EXPR or type punning through union.
> Changing the mode of a comparison isn't like that.
> Consider:
> typedef char __v8qi __attribute__((vector_size (8)));
>
> void
> foo (int x, __v8qi *y)
> {
> union U { __v8qi v; unsigned long long l; } u;
> u.l = x > 36;
> *y = *y + u.v;
> }
> on x86_64-linux, I see (subreg:V8QI (gt:DI (reg:CCGC 17 flags) (const_int 0
> [0])) 0) in the dumps
Which is invalid RTL.
> but for some reason gen_lowpart_for_combine actually
> hasn't been called except to convert originally gt:QI to gt:DI (that is
> correct). If it would be called, it would turn it into a completely bogus
> (gt:V8QI (reg:CCGC 17 flags) (const_int 0 [0])), which isn't clear what it
> actually would mean.
> (gt:V8QI (reg:V8QI ...) (reg:V8QI ...)) performs 8 comparisons and fills in
> the resulting vector with 8 0/-1 values, similarly (gt:V8QI (reg:V8QI ...)
> (const_vector:V8QI ...)). But if both operands of the comparison are scalar
> and result is a vector, what it is?
Ah sure, we should not change the mode to something not MODE_INT. Your
patch is okay, thanks; but there is more wrong here :-/
[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-11-27
CC||jakub at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek ---
Doesn't have to be an array,
struct A {
constexpr virtual int get () = 0;
constexpr virtual int set (A *o) = 0;
};
struct B : A {
constexpr int get () override { return 10; }
constexpr int set (A *o) override { a = o; return 20; }
A *a{};
};
constexpr auto addressof = [] (A ) { return };
struct Foo {
B b;
A *c { addressof (b) };
constexpr int add () { return c->set (addressof (b)); }
};
constexpr int get () { Foo f; return f.add (); }
constexpr auto a = get ();
static_assert (a == 20);
is rejected too.
I think the problem is that the r264408 testcase coverage doesn't try to
dereference this arguments of the virtual methods, which is what happens in
this testcase (the store to this->a in B::set(A *)).
The OBJ_TYPE_REF handling in cxx_eval_constant_expression has:
obj = TREE_OPERAND (obj, 0);
while (TREE_CODE (obj) == COMPONENT_REF
&& DECL_FIELD_IS_BASE (TREE_OPERAND (obj, 1)))
obj = TREE_OPERAND (obj, 0);
but something similar isn't done in cxx_eval_indirect_ref and I think generally
shouldn't be done there, it is (is it?) only the special case of virtual
method's first argument. So, I'd say this DECL_FIELD_IS_BASE handling should
be done in cxx_eval_call_expression.
[Bug preprocessor/92696] #pragma GCC diagnostic ... interferes with if/else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Diagnostic pragmas only work reliably at namespace-scope, not within functions. I thought that was documented, but maybe it's just something I learnt the hard way.
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #7 from asutton at gcc dot gnu.org --- Author: asutton Date: Wed Nov 27 15:23:02 2019 New Revision: 278775 URL: https://gcc.gnu.org/viewcvs?rev=278775=gcc=rev Log: 2019-11-27 Andrew Sutton PR c++/92236 Defer evaluation of concept checks so that static assertions can emit more detailed diagnostics. gcc/cp/ * constexpr.c (cxx_eval_call_expression): Handle concept checks. (cxx_eval_constant_expression): Diagnose misuse of function concepts as template-id expressions. Follow the usual return path for results. (cxx_eval_outermost_constant_expr): Avoid calling cp_get_callee_fndecl_nofold for function concepts. * constraint.cc (build_function_check): Fully type the concept check so that we don't ICE in conversions. * cp-gimplify.c (cp_genericize_r) [CALL_EXPR]: Handle concept checks. [TEMPLATE_ID_EXPR] Likewise. * cvt.c (convert_to_void): Always evaluate concept checks so we don't accidentally ignore them. Substitution during satisfaction can make a program ill-formed (example in g++.dg/cpp2a/concepts6.C). * pt.c (tsubst_copy_and_build): [CALL_EXPR]: Don't evaluate concepts. [TEMPLATE_ID_EXPR]: Likewise. * semantics.c (finish_call_expr): Don't evaluate concepts. (finish_id_expression_1): Likewise. (finish_static_assert): Preserve the original condition so we can diagnose concept errors when a check returns false. gcc/testsuite/ * g++.dg/cpp2a/concepts-iconv1.C: Update diagnostics. * g++.dg/cpp2a/concepts-requires5.C: Likewise. * g++.dg/cpp2a/concepts6.C: New test. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/constraint.cc trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/cvt.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp2a/concepts-iconv1.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-requires5.C
[Bug c++/92439] [concepts] trunk crashes on constraint satisfaction failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92439 --- Comment #3 from asutton at gcc dot gnu.org --- Author: asutton Date: Wed Nov 27 15:16:37 2019 New Revision: 278774 URL: https://gcc.gnu.org/viewcvs?rev=278774=gcc=rev Log: 2019-11-27 Andrew Sutton PR c++/92439 Improve quality of diagnostics for subexpressions that need parens. gcc/cp/ * parser.c (cp_parser_requires_clause_opt): Add a flag to indicate when parsing a requires-clause before lambda parameters, and... (cp_parser_lambda_declarator_opt): ... use that here ... (cp_parser_type_parameter): ... and here ... (cp_parser_late_return_type_opt): ... and here ... (cp_parser_explicit_template_declaration): ... and here. (cp_parser_diagnose_ungrouped_constraint_plain): Adjust the message because this can apply to subexpressions that are not immediately after a requires-clause. (cp_parser_diagnose_ungrouped_constraint_rich): Likewise. (primary_constraint_error): New. (cp_parser_constraint_requires_parens): New. (cp_parser_unary_constraint_requires_parens): New. (cp_parser_constraint_primary_expression): Check for unary expressions before parsing the primary expression. Also check for binary and postfix operators after a successful parse of the primary expression. Force a re-parse if the result would form a lower-precedence string. (cp_parser_constraint_logical_and_expression): Propagate lambda flag; move checks for ill-formed constraints into the constraint primary expression. (cp_parser_constraint_logical_or_expression): Likewise. (cp_parser_requires_clause_expression): Propagate lambda flag. gcc/testsuite/ * g++.dg/cpp2a/concepts-requires20.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp2a/concepts-requires20.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/88395] ICE: Segmentation fault signal terminated program cc1plus, with -std=c++2a -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395 --- Comment #12 from asutton at gcc dot gnu.org --- Author: asutton Date: Wed Nov 27 15:09:22 2019 New Revision: 278773 URL: https://gcc.gnu.org/viewcvs?rev=278773=gcc=rev Log: 2019-11-27 Andrew Sutton PR c++/88395 Prevent recursive satisfaction by adding requests to the instantiation stack. gcc/cp/ * constraint.cc (satisfy_declaration_constraints): Push tinst levels around satisfaction. gcc/testsuite/ * g++.dg/cpp2a/concepts-pr88395.C: New. * g++.dg/cpp2a/concepts-recursive-sat1.C: New. * g++.dg/cpp2a/concepts-recursive-sat2.C: New. * g++.dg/cpp2a/concepts-recursive-sat3.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp2a/concepts-pr88395.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-recursive-sat1.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-recursive-sat2.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-recursive-sat3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constraint.cc trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/90007] [9/10 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007 --- Comment #13 from Segher Boessenkool --- Does that work? You cannot put all hard registers in memory I think? Or do we require that and it is just not documented?
[Bug tree-optimization/92690] [10 Regression] vector CTOR optimization performs invalid conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92690 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #14 from Richard Biener --- Created attachment 47378 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47378=edit patch Patch I was playing with.
[Bug preprocessor/92696] New: #pragma GCC diagnostic ... interferes with if/else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696
Bug ID: 92696
Summary: #pragma GCC diagnostic ... interferes with if/else
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
At least with "gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)" and with recent GCC
10 trunk:
> $ cat test.c
> void f(int);
> void g(int b) {
> if (b)
> f(0);
> #pragma GCC diagnostic ignored "-Wformat"
> else
> f(1);
> }
> $ gcc -fsyntax-only test.c
> test.c: In function ‘g’:
> test.c:6:3: error: ‘else’ without a previous ‘if’
> 6 | else
> | ^~~~
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #13 from Richard Biener ---
So with all tricks I arrive at the following for the reduced testcase
f:
.LFB2:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movl%ecx, %r9d
vpxor %xmm4, %xmm4, %xmm4
movl$255, %eax
shrl$24, %r9d
subl%r9d, %eax
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
movl%eax, %r8d
vmovdqa %ymm4, -32(%rsp)
vmovd %ecx, %xmm4
shrl$7, %eax
vpshufd $0, %xmm4, %xmm4
addl%r8d, %eax
vmovaps %xmm4, -32(%rsp)
vpmovzxbw -32(%rsp), %ymm2
vmovd %eax, %xmm0
vpbroadcastb%xmm0, %xmm0
vpsllw $8, %ymm2, %ymm2
vpaddw .LC1(%rip), %ymm2, %ymm2
testq %rdx, %rdx
je .L10
vpxor %xmm5, %xmm5, %xmm5
vmovdqa .LC0(%rip), %xmm3
xorl%eax, %eax
vmovdqa %ymm5, -32(%rsp)
vmovaps %xmm0, -32(%rsp)
vpmovzxbw -32(%rsp), %ymm4
.p2align 4,,10
.p2align 3
.L7:
vmovdqu (%rsi,%rax), %xmm6
vpxor %xmm5, %xmm5, %xmm5
vmovdqa %ymm5, -32(%rsp)
vmovaps %xmm6, -32(%rsp)
vpmovzxbw -32(%rsp), %ymm0
vpmullw %ymm4, %ymm0, %ymm0
vpaddw %ymm2, %ymm0, %ymm0
vpsrlw $8, %ymm0, %ymm0
vmovdqa %xmm0, %xmm1
vextracti128$0x1, %ymm0, %xmm0
vpand %xmm1, %xmm3, %xmm1
vpand %xmm0, %xmm3, %xmm0
vpackuswb %xmm0, %xmm1, %xmm0
vmovups %xmm0, (%rdi,%rax)
addq$16, %rax
subq$4, %rdx
jne .L7
.L10:
vzeroupper
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE2:
.size f, .-f
where the stack spills still look bad - shomehow we don't like
_60 = BIT_INSERT_EXPR <{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, _4, 0>;
_61 = [vec_unpack_lo_expr] _60;
which is "widening" _4 to double vector size when we know we'll just need
the lowpart for the VEC_UNPACK_LO_EXPR. This _should_ translate to
a mov %xmm, %ymm but somehow it doesn't.
A small testcase for that is the zxt() function in the reduced testcase.
Using an undef SSA name in place off the { 0, ... } vector doesn't help
either. A simple VIEW_CONVERT isn't valid (it changes size).
[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Sure, before that we would punt much earlier at simplification of the
non-sensical subreg.
I don't mind if simplify_subreg doesn't call native_encode_rtx in the cases
where it ICEs and instead fails.
But, I believe what gen_lowpart_for_combine does for comparisons is completely
wrong for non-scalar modes that are different from their previous mode.
A same sized subreg of something is reinterpretation of the bits of something
as something else, VIEW_CONVERT_EXPR or type punning through union.
Changing the mode of a comparison isn't like that.
Consider:
typedef char __v8qi __attribute__((vector_size (8)));
void
foo (int x, __v8qi *y)
{
union U { __v8qi v; unsigned long long l; } u;
u.l = x > 36;
*y = *y + u.v;
}
on x86_64-linux, I see (subreg:V8QI (gt:DI (reg:CCGC 17 flags) (const_int 0
[0])) 0) in the dumps but for some reason gen_lowpart_for_combine actually
hasn't been called except to convert originally gt:QI to gt:DI (that is
correct). If it would be called, it would turn it into a completely bogus
(gt:V8QI (reg:CCGC 17 flags) (const_int 0 [0])), which isn't clear what it
actually would mean.
(gt:V8QI (reg:V8QI ...) (reg:V8QI ...)) performs 8 comparisons and fills in the
resulting vector with 8 0/-1 values, similarly (gt:V8QI (reg:V8QI ...)
(const_vector:V8QI ...)). But if both operands of the comparison are scalar
and result is a vector, what it is?
[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190 Martin Liška changed: What|Removed |Added CC||10walls at gmail dot com --- Comment #6 from Martin Liška --- I'm adding our maintainer to CC.
[Bug lto/91574] [10 Regression] ICE in types_same_for_odr at gcc/ipa-devirt.c:355 since r272037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91574 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|hubicka at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- I've got a patch candidate for this.
[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190 --- Comment #5 from Uroš Bizjak --- (In reply to Martin Liška from comment #4) > @Uros: Any update about this? Do you know about somebody who can help us > with an answer to your question? This is MS ABI, so perhaps cygwin/mingw-w64 maintainer could review the ABI issues in the compiler.
[Bug lto/92599] ICE in speculative_call_info, at cgraph.c:1142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599 Martin Liška changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org
[Bug lto/92600] ICE: symtab_node::verify failed, building 523.xalancbmk_r with -flto -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92600 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92599 --- Comment #3 from Martin Liška --- It's related to PR92599. It's also an ODR violation that leads to the ICE.
[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool ---
This is caused by r275959, the commit that added this assert.
combine does
Trying 14 -> 15:
14: r96:V1DI#0=flags:CCZ!=0
REG_DEAD flags:CCZ
15: {r99:DI=r100:DI|r96:V1DI#0;clobber flags:CC;}
REG_DEAD r100:DI
REG_UNUSED flags:CC
REG_DEAD r96:V1DI
Failed to match this instruction:
(parallel [
(set (reg:DI 99 [ vect_sq_12.9 ])
(ior:DI (ne:DI (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:DI 100)))
(clobber (reg:CC 17 flags))
])
Failed to match this instruction:
(set (reg:DI 99 [ vect_sq_12.9 ])
(ior:DI (ne:DI (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:DI 100)))
and that is all perfectly okay (the subregs here are mode DI, one of the
crucial things slim doesn't print).
[Bug rtl-optimization/90007] [9/10 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007 --- Comment #12 from Vladimir Makarov --- Author: vmakarov Date: Wed Nov 27 14:24:47 2019 New Revision: 278770 URL: https://gcc.gnu.org/viewcvs?rev=278770=gcc=rev Log: 2019-11-27 Vladimir Makarov PR rtl-optimization/90007 * recog.c (constrain_operands): Permit hard registers too for memory when LRA is used. 2019-11-27 Vladimir Makarov PR rtl-optimization/90007 * gcc.target/i386/pr90007.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr90007.c Modified: trunk/gcc/ChangeLog trunk/gcc/recog.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Richard Biener changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
||uros at gcc dot gnu.org
--- Comment #12 from Richard Biener ---
So it's probably better but not great yet. It would help tremendously to look
at PR92658, for this testcase we specifically need truncv16hiv16qi2 which
can be implemented with pshufb (maybe also better). I tried the following
(the upper half of the selector is just "garbage")
(define_expand "truncv16hiv16qi2"
[(set (subreg:V32QI (match_operand:V16QI 0 "register_operand") 0)
(vec_select:V32QI
(subreg:V32QI (match_operand:V16HI 1 "register_operand") 0)
(parallel [(const_int 0) (const_int 2)
(const_int 4) (const_int 6)
(const_int 8) (const_int 10)
(const_int 12) (const_int 14)
(const_int 16) (const_int 18)
(const_int 20) (const_int 22)
(const_int 24) (const_int 26)
(const_int 28) (const_int 30)
(const_int 0) (const_int 2)
(const_int 4) (const_int 6)
(const_int 8) (const_int 10)
(const_int 12) (const_int 14)
(const_int 16) (const_int 18)
(const_int 20) (const_int 22)
(const_int 24) (const_int 26)
(const_int 28) (const_int 30)
])))]
"TARGET_AVX2")
but that isn't recognized. Possibly because of the outer subreg, who
knows.
(define_insn "truncv16hiv16qi2"
[(set (match_operand:V16QI 0 "register_operand" "=x,v")
(truncate:V16QI
(match_operand:V16HI 1 "register_operand" "x,v")))]
"TARGET_AVX2"
"@
pshufb\t{%1, %0|%0, %1}
vpshufb\t{%1, %0|%0, %1}")
"works" but of course is wrong (somehow need the constant mask in a
register). The rest of the backend also doesn't know truncate of
vectors so representing as shuffles is probably better.
I also wonder how to macroize all this - probably via some
helpers in i386-expand.c I guess.
But I can also work with the pack/unpack tree codes for now.
[Bug d/91916] Maybe a dead code in socket.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91916 --- Comment #2 from Martin Liška --- @Iain: ping^2
[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190 --- Comment #4 from Martin Liška --- @Uros: Any update about this? Do you know about somebody who can help us with an answer to your question?
[Bug ipa/92372] [10 Regression] ICE in ipa_update_overall_fn_summary at gcc/ipa-fnsummary.c:3671 since r277780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92372 --- Comment #2 from Martin Liška --- @Honza?
[Bug lto/92599] ICE in speculative_call_info, at cgraph.c:1142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599 Martin Liška changed: What|Removed |Added Target Milestone|--- |10.0 --- Comment #2 from Martin Liška --- So we ICE at the end of cgraph_edge::speculative_call_info: (gdb) p ref $4 = (gdb) p e $5 = -> )> (gdb) p e2 $6 = -> )> As seen the edge is within idRenderModelStatic class. I bet the problem is the ODR warning message, the class is polymorphic in one TU, and normal class in another one.
[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695
--- Comment #2 from Toni Neubert ---
Copy paste error. The above example should be:
```
struct A {
constexpr virtual int get() = 0;
constexpr virtual int set(A *o) = 0;
};
struct B : A {
constexpr int get() override {
return 10;
}
constexpr int set(A *o) override {
a = o;
return 20;
}
A *a{};
};
constexpr auto addressof = [](A ) {
return
};
struct Foo {
B b[1];
A* curr_{addressof(b[0])};
constexpr int add() {
return curr_->set(addressof(b[0]));
}
};
constexpr int get() {
Foo f;
return f.add();
}
constexpr auto a = get();
int main() {
return a;
}
```
[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695
--- Comment #1 from Toni Neubert ---
Future more, the following example also fails. Could be the same root cause but
another error message appears:
accessing value of 'f.Foo::b[0].B::' through a 'B' glvalue in a
constant expression
Clang is just fine with it.
```
struct A {
constexpr virtual int get() = 0;
constexpr virtual int set(A *o) = 0;
};
struct B : A {
constexpr int get() override {
return 10;
}struct A {
constexpr virtual int get() = 0;
constexpr virtual int set(A *o) = 0;
};
struct B : A {
constexpr int get() override {
return 10;
}
constexpr int set(A *o) override {
a = o;
return 20;
}
A *a{};
};
constexpr auto addressof = [](A ) {
return
};
struct Foo {
B b[1];
A* curr_{addressof(b[0])};
constexpr int add() {
return curr_->set(addressof(b[0]));
}
};
constexpr int get() {
Foo f;
return f.add();
}
constexpr auto a = get();
int main() {
return a;
}
constexpr int set(A *o) override {
a = o;
return 20;
}
A *a{};
};
constexpr auto addressof = [](A ) {
return
};
struct Foo {
B b[1];
A* curr_{addressof(b[0])};
constexpr int add() {
return curr_->set(addressof(b[0]));
}
};
constexpr int get() {
Foo f;
return f.add();
}
constexpr auto a = get();
int main() {
return a;
}
```
See online here: https://gcc.godbolt.org/z/4ZwFAN
[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123 --- Comment #20 from Jakub Jelinek --- Created attachment 47377 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47377=edit gcc10-fnspec-test.patch Just for archival purposes, here is a short gcc plugin that allows testing "fn spec" attribute (on direct function calls only, not on indirect calls), by registering a fn_spec attribute and remapping it to "fn spec" when finish_decl is called.
[Bug target/92693] Inconsistency between __UINTPTR_TYPE__ and __UINT32_TYPE__ on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92693
--- Comment #4 from Jonathan Wakely ---
(In reply to Matthijs Kooijman from comment #3)
> Fair point, though I think that it is hard to define a proper overload set
> here. In my case, I'm defining functions to print various sizes of integers.
> Because the body of the function needs to know how big the type is, I'm
> using the
> uintxx_t types to define them. I could of course define the function for
> (unsigned) char, short, int, long, long long, but then I can't make any
> assumptions about the exact size of each (I could use sizeof and make a
> generic implementation, but I wanted to keep things simple and use a
> different implementation for each size).
void func(uint8_t);
void func(uint16_t);
void func(uint32_t);
void func(uint64_t);
template
std::enable_if_t::value> func(T t)
{
if (sizeof(T) == sizeof(uint8_t))
func((uint8_t)t);
else if (sizeof(T) == sizeof(uint16_t))
func((uint16_t)t);
else if (sizeof(T) == sizeof(uint32_t))
func((uint32_t)t);
else if (sizeof(T) == sizeof(uint64_t))
func((uint64_t)t);
}
[Bug ipa/92609] [10 Regression] ICE in warn_types_mismatch, at ipa-devirt.c:1000 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92609 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I've got a patch candidate for this.
[Bug libstdc++/92688] including introduce the name index to global namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92688 --- Comment #8 from SODA Noriyuki --- > Libstdc++ cannot define _XOPEN_SOURCE though, > because it could conflict with something the user defines. Yeah, it has similar problem with _GNU_SOURCE, _XOPEN_SOURCE is only closer to what it should be. > The correct fix is for glibc to expose the required names > by some other method (a "backdoor" just for libstdc++) > and not require any feature macros that users should be able to control. I understand. > I still plan to fix this, but it's not a top priority. I hope you'll have some spare time to do so in near future ;-) Thanks for taking you time to explain the issues.
[Bug rtl-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283 --- Comment #24 from Vladimir Makarov --- (In reply to Richard Biener from comment #23) > Vladimir, can you look into this LRA inheritance issue? Yes, I've started to work on this. I can not reproduce it on the current trunk. But yesterday, I've reproduced it on the revision mentioned in the title. Inheritance problems are usually hard to fix. So I can not say when I find a reason for the problem and solution for it. But I guess it will be fixed on the next week.
[Bug target/92693] Inconsistency between __UINTPTR_TYPE__ and __UINT32_TYPE__ on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92693 --- Comment #3 from Matthijs Kooijman --- > I don't see why you should expect that, there's nothing in the standards > suggesting it should be the case. This is true, current behaviour is standards-compliant AFAICS. However, I expect that because it would be consistent, and would make things behave with least surprise (at least for the usecase I suggested). > Changing it would be an ABI change, so seems like a bad idea. Good point. I did a bit more searching and found this Linux kernel patch. The commit message suggests that it might at some point have been consistent: https://patchwork.kernel.org/patch/2845139/ I assume that "bare metal GCC" would refer to the __xxx_TYPE__ macros, or at least whatever you get when you include . > N.B. you get exactly the same overload failure if you call func(1u). The > problem is your overload set, not the definition of uintptr_t. Fair point, though I think that it is hard to define a proper overload set here. In my case, I'm defining functions to print various sizes of integers. Because the body of the function needs to know how big the type is, I'm using the uintxx_t types to define them. I could of course define the function for (unsigned) char, short, int, long, long long, but then I can't make any assumptions about the exact size of each (I could use sizeof and make a generic implementation, but I wanted to keep things simple and use a different implementation for each size). I guess this might boil down to C/C++ being annoying when it comes to integer types, and not something GCC can really fix (though it *would* have been more convenient if this had been consistent from the start). Feel free to close if that seems appropriate.
[Bug target/92693] Inconsistency between __UINTPTR_TYPE__ and __UINT32_TYPE__ on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92693 --- Comment #2 from Jonathan Wakely --- N.B. you get exactly the same overload failure if you call func(1u). The problem is your overload set, not the definition of uintptr_t.
[Bug target/92693] Inconsistency between __UINTPTR_TYPE__ and __UINT32_TYPE__ on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92693 --- Comment #1 from Jonathan Wakely --- (In reply to Matthijs Kooijman from comment #0) > I would expect that, since both types are 32-bit long, they would actually > resolve to the same type. This would also make overload resolution work as > expected. Is there any reason for this inconsistency, or could it be fixed? I don't see why you should expect that, there's nothing in the standards suggesting it should be the case. Changing it would be an ABI change, so seems like a bad idea.
[Bug c++/92695] New: [10, 9] P1064R0 - virtual constexpr fails if object taken from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695
Bug ID: 92695
Summary: [10, 9] P1064R0 - virtual constexpr fails if object
taken from array
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lutztonineubert at gmail dot com
Target Milestone: ---
The following code fails with:
-> error: expression 'A::get' is not a constant expression
Compiled with `-std=c++2a` under GCC-9.2 and GCC-trunk. It works under
Clang-trunk.
```
struct A {
constexpr virtual int get() = 0;
};
struct B : A {
constexpr int get() override {
return 10;
}
};
struct Foo {
B b[1] = {};
constexpr A * get_a() {
// Seems to be the problem.
return &(b[0]);
}
};
constexpr int get() {
Foo f;
return f.get_a()->get();
}
constexpr auto a = get();
int main() {
return a;
}
```
The dereferencing of the array seems to be the problem.
See online here: https://gcc.godbolt.org/z/ZSXAfb
[Bug ipa/92476] [10 regression] SEGV in cgraph_edge_brings_value_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92476
--- Comment #4 from Martin Liška ---
And I have one more test-case reduced from rubygem-passenger:
$ cat kit.ii
namespace Passenger {
namespace Json {
class Value;
}
namespace ConfigKit {
class Translator;
}
namespace LoggingKit {
void initialize(const Json::Value &, const ConfigKit::Translator &) {}
} // namespace LoggingKit
} // namespace Passenger
$ cat hooks.ii
namespace Passenger {
namespace Json {
class Value {};
} // namespace Json
namespace ConfigKit {
class Translator {};
} // namespace ConfigKit
namespace LoggingKit {
void initialize(const Json::Value & = Json::Value(),
const ConfigKit::Translator & = ConfigKit::Translator());
void init_module() { initialize(); }
} // namespace LoggingKit
} // namespace Passenger
$ c++ -o kit.o -O2 -fPIC -flto=auto -fPIC -fvisibility=hidden -c kit.ii
$ c++ -o hooks.o -fPIC -flto=auto -fPIC -fvisibility=hidden -c hooks.ii
$ c++ -shared hooks.o -fPIC -o mod_passenger.so kit.o
during IPA pass: cp
lto1: internal compiler error: Segmentation fault
0xa15d2f crash_signal
../../gcc/toplev.c:328
0x7f096d32e14f ???
/usr/src/debug/glibc-2.30-1.2.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x5ca09a set_single_call_flag
../../gcc/ipa-cp.c:1170
0x670cd4 cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool, bool)
../../gcc/cgraph.c:2267
0x11f6a11 initialize_node_lattices
../../gcc/ipa-cp.c:1197
0x11f6a11 ipcp_propagate_stage
../../gcc/ipa-cp.c:3701
0x11fa8f4 ipcp_driver
../../gcc/ipa-cp.c:5560
0x11fa8f4 execute
../../gcc/ipa-cp.c:5653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/92690] [10 Regression] vector CTOR optimization performs invalid conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92690 --- Comment #2 from Richard Biener --- Author: rguenth Date: Wed Nov 27 12:16:54 2019 New Revision: 278764 URL: https://gcc.gnu.org/viewcvs?rev=278764=gcc=rev Log: 2019-11-27 Richard Biener PR tree-optimization/92690 * tree-ssa-forwprop.c (simplify_vector_constructor): Avoid converting elements not originally converted. * gcc.dg/torture/pr92690.c: New testcase. * gcc.dg/tree-ssa/forwprop-35.c: Adjust. Added: trunk/gcc/testsuite/gcc.dg/torture/pr92690.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-35.c trunk/gcc/tree-ssa-forwprop.c
[Bug tree-optimization/92222] [9 Regression] ice in useless_type_conversion_p, at gimple-expr.c:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #8 from Richard Biener --- Author: rguenth Date: Wed Nov 27 12:09:36 2019 New Revision: 278763 URL: https://gcc.gnu.org/viewcvs?rev=278763=gcc=rev Log: 2019-11-27 Richard Biener Backport from mainline 2019-10-25 Richard Biener PR tree-optimization/9 * tree-vect-slp.c (_slp_oprnd_info::first_pattern): Remove. (_slp_oprnd_info::second_pattern): Likewise. (_slp_oprnd_info::any_pattern): New. (vect_create_oprnd_info): Adjust. (vect_get_and_check_slp_defs): Compute whether any stmt is in a pattern. (vect_build_slp_tree_2): Avoid building up a node from scalars if any of the operand defs, not just the first, is in a pattern. * gcc.dg/torture/pr9.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr9.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug tree-optimization/92222] [9 Regression] ice in useless_type_conversion_p, at gimple-expr.c:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.2.1 Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug target/92694] New: Can't build powerpc-eabi cross compiler: : fatal error: internal error: builtin function ‘__builtin_ddedpd’ had an unexpected return type ‘DD’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92694 Bug ID: 92694 Summary: Can't build powerpc-eabi cross compiler: : fatal error: internal error: builtin function ‘__builtin_ddedpd’ had an unexpected return type ‘DD’ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: green at redhat dot com Target Milestone: --- I'm trying to build a powerpc-eabi cross compiler from git sources, and am getting the following: /home/green/BUG/build-gcc1/./gcc/xgcc -B/home/green/BUG/build-gcc1/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/home/green/git/gcc/gcc/testsuite/selftests : fatal error: internal error: builtin function ‘__builtin_ddedpd’ had an unexpected return type ‘DD’ compilation terminated. : fatal error: internal error: builtin function ‘__builtin_ddedpd’ had an unexpected return type ‘DD’ compilation terminated. make[2]: *** [/home/green/git/gcc/gcc/c/Make-lang.in:124: s-selftest-c] Error 1
[Bug target/92693] New: Inconsistency between __UINTPTR_TYPE__ and __UINT32_TYPE__ on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92693
Bug ID: 92693
Summary: Inconsistency between __UINTPTR_TYPE__ and
__UINT32_TYPE__ on ARM
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matthijs at stdin dot nl
Target Milestone: ---
Gcc defines a number of macros for types, which are used by stdint.h to define
the corresponding typedefs. In particular, I'm looking at uintptr_t. On ARM,
this is 32-bits and equals unsigned int:
#define __UINTPTR_TYPE__ unsigned int
In my code, I was running into problems trying to pass a uintptr_t to a
function that has overloads for uint8_t, uint16_t and uint32_t (ambigious
function call). Investigating, it turns out that uint32_t is defined as long
unsigned int:
#define __UINT32_TYPE__ long unsigned int
I would expect that, since both types are 32-bit long, they would actually
resolve to the same type. This would also make overload resolution work as
expected. Is there any reason for this inconsistency, or could it be fixed?
To test this, I installed the gcc-arm-none-eabi, version 15:7-2018-q2-6 from
Ubuntu Disco (same version should be in Debian testing):
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:7-2018-q2-6) 7.3.1 20180622 (release)
[ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ arm-none-eabi-gcc -dM -E -x c++ /dev/null |egrep '(UINTPTR_TYPE|UINT32_TYPE)'
#define __UINT32_TYPE__ long unsigned int
#define __UINTPTR_TYPE__ unsigned int
I see the same problem using gcc 8.2.1 shipped with the STM32 arduino core
(https://github.com/stm32duino/Arduino_Core_STM32).
To illustrate the original problem I was seeing, here's a small testcase:
$ cat foo.cpp
#include
void func(uint16_t);
void func(uint32_t);
int main() {
func((uintptr_t)nullptr);
static_assert(sizeof(uintptr_t) == sizeof(uint32_t), "Sizes not
equal");
}
$ arm-none-eabi-gcc -c foo.cpp
foo.cpp: In function 'int main()':
foo.cpp:7:25: error: call of overloaded 'func(uintptr_t)' is ambiguous
func((uintptr_t)nullptr);
^
foo.cpp:3:6: note: candidate: void func(uint16_t)
void func(uint16_t);
^~~~
foo.cpp:4:6: note: candidate: void func(uint32_t)
void func(uint32_t);
^~~~
[Bug tree-optimization/14799] [tree-ssa] convert a sequence of "if"s to a "switch" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14799 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0
