[Bug bootstrap/92927] New: Bootstrap failed with CXXFLAGS="-O0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92927 Bug ID: 92927 Summary: Bootstrap failed with CXXFLAGS="-O0" Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: wwwhhhyyy333 at gmail dot com Target Milestone: --- configure GCC with: --enable-languages=c,c++,fortran --enable-bootstrap CXXFLAGS="-O0" At stage3, it throws error: /usr/bin/ld: /home/hongyuw1/gcc/build_libstdcpp_regression/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(string-inst.o): in function `std::__cxx11::basic_string, std::allocator >::operator=(std::__cxx11::basic_string, std::allocator >&&)': /home/hongyuw1/gcc/build_libstdcpp_regression/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:716: undefined reference to `void std::__alloc_on_move >(std::allocator&, std::allocator&)' /usr/bin/ld: /home/hongyuw1/gcc/build_libstdcpp_regression/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(string-inst.o): in function `std::__cxx11::basic_string, std::allocator >::assign(std::__cxx11::basic_string, std::allocator > const&)': /home/hongyuw1/gcc/build_libstdcpp_regression/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1363: undefined reference to `void std::__alloc_on_copy >(std::allocator&, std::allocator const&)' /usr/bin/ld: /home/hongyuw1/gcc/build_libstdcpp_regression/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(string-inst.o): in function `__gnu_cxx::__alloc_traits, char>::_S_on_swap(std::allocator&, std::allocator&)': /home/hongyuw1/gcc/build_libstdcpp_regression/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/alloc_traits.h:101: undefined reference to `void std::__alloc_on_swap >(std::allocator&, std::allocator&)' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:2943: gcov] Error 1 It seems to happen after r277588.
[Bug c++/91165] [10 Regression] error: location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335 --- Comment #15 from Jason Merrill --- On 11/28/19 12:58 PM, jakub at gcc dot gnu.org wrote: > Now, the issues: > 1) (so far ignored); the standard says that classes where all virtual members > are immediate are still polymorphic, > but I guess for the ABI we don't want a vtable pointer there. So, I > think we want TYPE_POLYMORPHIC_P set on > those, but e.g. TYPE_CONTAINS_VPTR_P probably shouldn't be true for them; > do we want TYPE_REALLY_POLYMORPHIC_P or > similar for polymorphic types that contain at least one non-immediate > virtual function and thus need a vtable? We still need a vtable for typeinfo, so I think we don't need to worry about this. > 2) initially I thought I'd just always emit a direct call to the immediate > virtual method found by lookup and do the remapping of that during constexpr > call evaluation; unfortunately as the > v->S::bar () etc. calls show, we only want to do that if LOOKUP_NONVIRTUAL > wasn't set; unfortunately, when immediate > functions aren't in the binfo structures, DECL_VINDEX is error_mark_node and > so I think we need some hack how to > preserve the info that we are going to call a virtual consteval method; could > we e.g. abuse OBJ_TYPE_REF with > different arguments that would make it clear it is something different, or > new tree? We need to store the instance > on which it is called and the virtual consteval method originally chosen e.g. > to compare the type > 3) I'm afraid one can't use a lookup_member on the actual instance type, > because it could find all kinds of things, > static member functions, typedefs, data members etc. in derived classes, > where we actually are only interested in > in virtual methods. So, shall we use something like look_for_overrides > does, except with the fndecl from the > base rather than derived and of course don't do anything except return > the first found method (and ignore static member > functions rather than handling them)? Would it work to include them at the end of BINFO_VIRTUALS but omit them in build_vtbl_initializer? > 4) guess covariant returns need to be handled at the end too somehow Yep. Jason
[Bug c++/92150] Partial specializations of class templates with class NTTP fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92150 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri Dec 13 05:09:57 2019 New Revision: 279332 URL: https://gcc.gnu.org/viewcvs?rev=279332=gcc=rev Log: PR c++/92150 - partial specialization with class NTTP. Here unify was getting confused by the VIEW_CONVERT_EXPR we add in finish_id_expression_1 to make class NTTP const when they're used in an expression. Tested x86_64-pc-linux-gnu, applying to trunk. * pt.c (unify): Handle VIEW_CONVERT_EXPR. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/nontype-class24.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/pt.c
[Bug c++/92859] compiler treats enum type as an integer during overload resolution when a bit-field of this enum is considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92859 --- Comment #3 from Jason Merrill --- Author: jason Date: Fri Dec 13 05:10:06 2019 New Revision: 279334 URL: https://gcc.gnu.org/viewcvs?rev=279334=gcc=rev Log: PR c++/92859 - ADL and bit-field. We also need unlowered_expr_type when considering associated types for ADL. * name-lookup.c: Use unlowered_expr_type. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/overload/bit-field1.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/name-lookup.c
[Bug c++/92446] [C++20] template argument deduction fails for custom non-type parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92446 --- Comment #3 from Jason Merrill --- Author: jason Date: Fri Dec 13 05:10:02 2019 New Revision: 279333 URL: https://gcc.gnu.org/viewcvs?rev=279333=gcc=rev Log: PR c++/92446 - deduction of class NTTP. Another place we need to look through the VIEW_CONVERT_EXPR we add to make a use of a class NTTP have const type. * pt.c (deducible_expression): Look through VIEW_CONVERT_EXPR. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/nontype-class26.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/pt.c
[Bug c++/57082] brace initialization requires public destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57082
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Fri Dec 13 05:10:11 2019
New Revision: 279335
URL: https://gcc.gnu.org/viewcvs?rev=279335=gcc=rev
Log:
PR c++/57082 - new X{} and private destructor.
build_new_1 already passes tf_no_cleanup to build_value_init, but in this
testcase we end up calling build_value_init by way of
build_special_member_call, so we need to pass it to that function as well.
* init.c (build_new_1): Also pass tf_no_cleanup to
build_special_member_call.
Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/initlist-new2.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/init.c
[Bug c++/92496] spaceship operator without include produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92496 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/92496] spaceship operator without include produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92496 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri Dec 13 05:05:51 2019 New Revision: 279331 URL: https://gcc.gnu.org/viewcvs?rev=279331=gcc=rev Log: PR c++/92496 - ICE with <=> and no #include . * typeck.c (cp_build_binary_op): Handle error from spaceship_type. Added: trunk/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c
[Bug tree-optimization/86659] [9 regression] gnat.dg/sso/q[23].adb FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86659 --- Comment #8 from Andrew Pinski --- I have a C testcase which I will be adding by the end of the week.
[Bug c++/92926] New: Wrong code generated because of shared tree node in gimplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92926
Bug ID: 92926
Summary: Wrong code generated because of shared tree node in
gimplify
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Target Milestone: ---
Following code is reduced from cppcoro but is irrelevant to coroutine.
#include
#include
class ipv6_address
{
public:
constexpr ipv6_address(
std::uint16_t part0,
std::uint16_t part1,
std::uint16_t part2,
std::uint16_t part3,
std::uint16_t part4,
std::uint16_t part5,
std::uint16_t part6,
std::uint16_t part7);
static constexpr ipv6_address loopback();
std::string to_string() const;
private:
alignas(std::uint64_t) std::uint8_t m_bytes[16];
};
constexpr ipv6_address::ipv6_address(
std::uint16_t part0,
std::uint16_t part1,
std::uint16_t part2,
std::uint16_t part3,
std::uint16_t part4,
std::uint16_t part5,
std::uint16_t part6,
std::uint16_t part7)
: m_bytes{
static_cast(part0 >> 8),
static_cast(part0),
static_cast(part1 >> 8),
static_cast(part1),
static_cast(part2 >> 8),
static_cast(part2),
static_cast(part3 >> 8),
static_cast(part3),
static_cast(part4 >> 8),
static_cast(part4),
static_cast(part5 >> 8),
static_cast(part5),
static_cast(part6 >> 8),
static_cast(part6),
static_cast(part7 >> 8),
static_cast(part7) }
{}
constexpr ipv6_address ipv6_address::loopback()
{
return ipv6_address{ 0, 0, 0, 0, 0, 0, 0, 1 };
}
char hex_char(std::uint8_t value)
{
return value < 10 ?
static_cast('0' + value) :
static_cast('a' + value - 10);
}
std::string ipv6_address::to_string() const
{
std::uint32_t longestZeroRunStart = 0;
std::uint32_t longestZeroRunLength = 0;
for (std::uint32_t i = 0; i < 8; )
{
if (m_bytes[2 * i] == 0 && m_bytes[2 * i + 1] == 0)
{
const std::uint32_t zeroRunStart = i;
++i;
while (i < 8 && m_bytes[2 * i] == 0 && m_bytes[2 * i + 1] == 0)
{
++i;
}
std::uint32_t zeroRunLength = i - zeroRunStart;
if (zeroRunLength > longestZeroRunLength)
{
longestZeroRunLength = zeroRunLength;
longestZeroRunStart = zeroRunStart;
}
}
else
{
++i;
}
}
char buffer[40];
char* c = [0];
auto appendPart = [&](std::uint32_t index)
{
const std::uint8_t highByte = m_bytes[index * 2];
const std::uint8_t lowByte = m_bytes[index * 2 + 1];
if (highByte > 0 || lowByte > 15)
{
if (highByte > 0)
{
if (highByte > 15)
{
*c++ = hex_char(highByte >> 4);
}
*c++ = hex_char(highByte & 0xF);
}
*c++ = hex_char(lowByte >> 4);
}
*c++ = hex_char(lowByte & 0xF);
};
if (longestZeroRunLength >= 2)
{
for (std::uint32_t i = 0; i < longestZeroRunStart; ++i)
{
if (i > 0)
{
*c++ = ':';
}
appendPart(i);
}
*c++ = ':';
*c++ = ':';
for (std::uint32_t i = longestZeroRunStart + longestZeroRunLength; i < 8;
++i)
{
appendPart(i);
if (i < 7)
{
*c++ = ':';
}
}
}
else
{
appendPart(0);
for (std::uint32_t i = 1; i < 8; ++i)
{
*c++ = ':';
appendPart(i);
}
}
assert((c - [0]) <= sizeof(buffer));
return std::string{ [0], c };
}
std::string __attribute__((noinline)) foo ()
{
return ipv6_address::loopback().to_string();
}
ipv6_address __attribute__((noinline)) bar ()
{
return ipv6_address::loopback();
}
int main() {
std::string s = foo ();
ipv6_address a = bar ();
assert(a.to_string() == s);
return 0;
}
Compiling using following command line:
$ ./g++ -std=c++17 -m64 -O3 z.cc -o a.out
$ ./a.out
a.out: z.cc:168: int main(): Assertion `a.to_string() == s' failed.
Aborted
Root cause is ipv6_address::loopback as a constexpr function, what it returns
is folded into const ctor by C++ FE, also the const ctor is shared translation
unit wide by constexpr_call_table. As a result the ctor as well as its vector
elements are shared between foo and bar.
In gimplify, CONSTRUCTOR_ELTS is optimized and cleared, causing shared node
changed in the other function.
Will send a patch for discussion.
[Bug target/92904] varargs for __int128 is placed at an unaligned location and uses movdqa for the load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92904 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Dec 13 00:09:34 2019 New Revision: 279327 URL: https://gcc.gnu.org/viewcvs?rev=279327=gcc=rev Log: PR target/92904 * config/i386/i386.c (ix86_gimplify_va_arg): If need_intregs and not need_temp, decrease alignment of the read because the GPR save area only guarantees 8-byte alignment. * gcc.c-torture/execute/pr92904.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr92904.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/92925] New: RTl expansion throws away alignment info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92925
Bug ID: 92925
Summary: RTl expansion throws away alignment info
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Hi,
this testcase originally started as attempt to produce self contained
reproducer for ipa-cp bug. Problem is that RTL expansion is too limited and
refuses to produce aligned moves for me.
struct a {long a1; long a2;};
struct b {long b; struct a a[10];};
struct c {long c; struct b b;__int128 e;};
int l;
__attribute__ ((noinline))
static void
set(struct b *bptr)
{
for (int i=0;ia[i]=(struct a){};
}
test ()
{
struct c c;
set ();
}
Here ipa-cp propagates that BPTR is always aligned to 16 with misaligment 8.
This should let expansion to use movaps for the "bptr->a[i]=(struct a){};"
constructions but it does not.
set:
.LFB0:
.cfi_startproc
movll(%rip), %ecx
testl %ecx, %ecx
jle .L1
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L3:
movslq %eax, %rdx
pxor%xmm0, %xmm0
addl$2, %eax
salq$4, %rdx
movups %xmm0, 8(%rdi,%rdx)
cmpl%ecx, %eax
jl .L3
.L1:
Overall the loop codegen is quite bad.
[Bug bootstrap/92653] [10 Regression] PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92653 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jan Hubicka --- The underlying updating issues was fixed last week
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #27 from Jonathan Wakely --- Yes, we need to reimplement call_once to not use pthread_once at all, for any targets.
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #26 from Paul Adobe --- It may be interesting to note that we recently ended up tracking a change in glibc to making this a problem on x86_64 architectures. Apparently when they refactored pthread_once in glibc patch 2.17.288 it changed the problem from an arm/powerpc only problem to an all-architecture problem. (cent7.7 had recently updated to .292, which made this quite evident)
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #17 from Mikael Pettersson --- My though reading this is that most RICSs have problems synthesizing large literals, so putting a jump table in .text might increase the likelihood of its address being synthesizable with a PC + offset addressing mode. Putting it in .rodata would almost certainly require you to indirect through the GOT to address it. That said, if the user wants .text to be execute-only, then the jump table ought to land in .rodata.
[Bug fortran/92753] [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92753
--- Comment #5 from anlauf at gcc dot gnu.org ---
It appears that the simplification of the %len fails.
implicit none
type t
character :: c
end type t
type(t), parameter :: x = t('a')
integer, parameter :: l = x%c%len ! error
! integer, parameter :: l = x%c%kind ! no error
integer :: m = l
print *, m
end
gives:
pr92753-z2.f90:8:16:
8 | integer :: m = l
|1
Error: non-constant initialization expression at (1)
[Bug c++/92496] spaceship operator without include produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92496 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/92913] Add argument-mismatch check for INTERFACE for non-module procedures in the same file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92913 --- Comment #2 from Thomas Koenig --- Created attachment 47483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47483=edit concept patch for subroutine vs. function Here is a concept patch for subroutine vs. function. I have moved this past the interface checking because it is better that all the symbols have been added to the global table before looking at mismatches.
[Bug fortran/92753] [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92753
--- Comment #4 from anlauf at gcc dot gnu.org ---
Slightly reduced testcase:
implicit none
type t
character :: c
end type t
type(t), parameter :: x = t('a')
integer, parameter :: l = x%c%len ! ICE
! integer, parameter :: l = x%c%kind ! no ICE
print *, l
end
[Bug fortran/92753] [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92753
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
A minor variation of the example in comment#0 shows a slightly different ICE:
module m
type t
character(3) :: c
end type t
type(t), parameter :: x = t('abc')
end
program p
use m
print *, x%c%len
end
pr92753-z1.f90:9:0:
9 | print *, x%c%len
|
internal compiler error: Segmentation fault
0xd45e5f crash_signal
../../trunk/gcc/toplev.c:328
0x7871c0 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../trunk/gcc/fortran/trans-expr.c:8506
0x77d6ac gfc_conv_expr(gfc_se*, gfc_expr*)
../../trunk/gcc/fortran/trans-expr.c:8677
0x787525 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool)
../../trunk/gcc/fortran/trans-expr.c:8802
0x7b2457 gfc_trans_transfer(gfc_code*)
../../trunk/gcc/fortran/trans-io.c:2582
0x735c97 trans_code
../../trunk/gcc/fortran/trans.c:2084
0x7aef82 build_dt
../../trunk/gcc/fortran/trans-io.c:2026
0x735cb7 trans_code
../../trunk/gcc/fortran/trans.c:2056
0x76d14d gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6801
0x6e70a6 translate_all_program_units
../../trunk/gcc/fortran/parse.c:6302
0x6e70a6 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6541
0x7320af gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:210
[Bug fortran/92898] [9/10 Regression] ICE in gfc_check_is_contiguous, at fortran/check.c:7157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92898 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on trunk and 9-branch. Thanks for the report!
[Bug fortran/92898] [9/10 Regression] ICE in gfc_check_is_contiguous, at fortran/check.c:7157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92898 --- Comment #4 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Thu Dec 12 20:46:03 2019 New Revision: 279315 URL: https://gcc.gnu.org/viewcvs?rev=279315=gcc=rev Log: 2019-12-12 Harald Anlauf Backport from mainline PR fortran/92898 * check.c (gfc_check_is_contiguous): Simplify check to handle arbitrary NULL() argument. PR fortran/92898 * gfortran.dg/pr92898.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr92898.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/check.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/92898] [9/10 Regression] ICE in gfc_check_is_contiguous, at fortran/check.c:7157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92898 --- Comment #3 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Thu Dec 12 20:39:48 2019 New Revision: 279314 URL: https://gcc.gnu.org/viewcvs?rev=279314=gcc=rev Log: 2019-12-12 Harald Anlauf PR fortran/92898 * check.c (gfc_check_is_contiguous): Simplify check to handle arbitrary NULL() argument. PR fortran/92898 * gfortran.dg/pr92898.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr92898.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #16 from Andrew Pinski --- (In reply to Jean-Christophe Dubois from comment #15) > Am I missing something? YES. Most likely it will not be loaded in the instruction cache as it is larger than the cache line size.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #15 from Jean-Christophe Dubois --- Thanks for the feedback and the support. Now maybe this is not the good place to ask question but I am wondering: Most of today's processors have separate data and instruction cache. Isn't it sub optimal performance wise to load the instruction cache with jump tables (just data consuming precious cache resource) and then having to load these same jump tables again in the data cache to use them (jump tables might then be loaded twice and eat instruction cache for no reason). If there were only processors with unified cache this would not be an issue but this is not the most common case in today's processors. Am I missing something? Shouldn't most architecture put jump tables in rodata section. Thanks JC
[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||mliska at suse dot cz --- Comment #1 from Jan Hubicka --- This is caused by Martin's TOP_N_PROFILE work.
[Bug tree-optimization/92924] New: [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924 Bug ID: 92924 Summary: [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- During the train run, in firefox2019-release-9test/dom/bindings function ;; Function mozilla::dom::binding_detail::GenericGetter (_ZN7mozilla3dom14binding_detail13GenericGetterINS1_16NormalThisPolicyENS1_15ThrowExceptionsEEEbP9JSContextjPN2JS5ValueE, funcdef_no=39965, decl_uid=943222, cgraph_uid=24044, symbol_order=25045) calls function get_id most of time. With GCC 9 we get: Indirect call value:939751711 match:139135227 all:140993325. Indirect call -> direct call from other modulegetter_18=> 939751711 (will resolve only with LTO) With GCC 10 we get: Trying transformations on stmt ok_20 = getter_18 (cx_131(D), D.1007269, self_129, D.1007259); Indirect call counterall: 140957778, values: [2135000278:-1], [401302964:3804], [1203869319:12375], [429856732:6018]. So the profile omits completely get_id and we fail to inline. This has quite large performance impact of Firefox in general since it seems to affect DOM tree manipulation quite badly.
[Bug fortran/86416] [OMPVV SOLLVE] Defaultmap issues on OpenMP 4.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416 --- Comment #5 from Tobias Burnus --- (In reply to Tobias Burnus from comment #4) > I think the output by LTO is correct but not very helpful: > > lto1: fatal error: unsupported mode 'XF' (for long double) > lto1: fatal error: unsupported mode 'TF' (for __float128) > > I think when generating code for offloading, this must be more explicit like: > > nvptx-none does not support 80-bit floating-point numbers > nvptx-none does not support 128-bit floating-point numbers Seems as if 'lto1' does not know about the target for which it has been compiled. Otherwise, would a patch along the following lines make sense? --- a/gcc/lto-streamer-in.c +++ b/gcc/lto-streamer-in.c @@ -1700,7 +1700,18 @@ lto_input_mode_table (struct lto_file_decl_data } /* FALLTHRU */ default: - fatal_error (UNKNOWN_LOCATION, "unsupported mode %qs", mname); + /* Especially for offloading compilers, it helps to have a more +readable error message. See also target.def. */ + if (mname[0] == 'X' && mname[1] == 'F') + fatal_error (UNKNOWN_LOCATION, +"80-bit floating-point numbers unsupported (mode " +"%qs)", mname); + else if (mname[0] == 'T' && mname[1] == 'F') + fatal_error (UNKNOWN_LOCATION, +"128-bit floating-point numbers unsupported (mode " +"%qs)", mname); + else + fatal_error (UNKNOWN_LOCATION, "unsupported mode %qs", mname); break; } }
[Bug other/92870] new test case gcc.dg/vect/vect-shift-5.c fails starting with its introduction in r279114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92870 --- Comment #3 from sudi at gcc dot gnu.org --- Author: sudi Date: Thu Dec 12 18:01:18 2019 New Revision: 279310 URL: https://gcc.gnu.org/viewcvs?rev=279310=gcc=rev Log: [Committed, testsuite] Fix PR92870 With my recent commit, I added a test that is not passing on all targets. My change was valid for targets that have a vector/scalar shift/rotate optabs (optab that supports vector shifted by scalar). Since it does not seem to be easy to find out which targets would support it, I am limiting the test to the targets that I know pass. gcc/testsuite/ChangeLog 2019-12-12 Sudakshina Das PR testsuite/92870 * gcc.dg/vect/vect-shift-5.c: Add target to scan-tree-dump. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-shift-5.c
[Bug target/92923] __builtin_vec_xor() causes subregs to be used when not using V4SImode vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92923 --- Comment #2 from Peter Bergner --- Looking at rs6000-builtin.def, we have the same issue with __builtin_vec_and(), __builtin_vec_or(), etc., etc.
[Bug fortran/86416] [OMPVV SOLLVE] Defaultmap issues on OpenMP 4.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #4 from Tobias Burnus ---
Cross ref: See also https://github.com/SOLLVE/sollve_vv/issues/41
(In reply to Jose Manuel Monsalve Diaz from comment #0)
> The problems:
> 1. DOUBLE COMPLEX values produce a compiler LTO error:
The problem is that COMPLEX(kind=16) alias COMPLEX*32 is a REAL128 complex
floating-point number, which is supported on the host – but not on the offload
target (here: nvptx-none).
I think the output by LTO is correct but not very helpful:
lto1: fatal error: unsupported mode 'XF' (for long double)
lto1: fatal error: unsupported mode 'TF' (for __float128)
I think when generating code for offloading, this must be more explicit like:
nvptx-none does not support 80-bit floating-point numbers
nvptx-none does not support 128-bit floating-point numbers
Or something along those lines which actually helps the user to understand what
goes wrong.
Richard, Jakub: Thoughts?
C example – untested – which illustrates the issue and can be turned into a
test case, once LTO has a nicer error.
---
/* { dg-do link } */
/* { dg-require-effective-target large_long_double } */
/* { dg-require-effective-target offload_device } */
/* { dg-error "fatal error: unsupported mode 'XF'" */
#include /* For abort. */
long double foo (long double x)
{
#pragma omp target map(tofrom:x)
x *= 2.0;
return x;
}
int main
{
long double v = foo (10.0q) - 20.0q;
if (v > 1.0e-5 || v < -1.0e-5) abort();
return 0;
}
---
/* { dg-do link { target __float128 } } */
/* { dg-add-options __float128 } */
/* { dg-require-effective-target offload_device } */
/* { dg-error "fatal error: unsupported mode 'TF'" */
__float128 foo(__float128 y)
{
#pragma omp target map(tofrom: y)
y *= 4.0;
return y;
}
int main
{
__float128 v = foo (5.0L) - 20.0L;
if (v > 1.0e-5 || v < -1.0e-5) abort();
return 0;
}
---
(Assumes that for offload_device, neither data type is available; if it is, one
needs to exclude those offload-targets.)
> 2. CHARACTER default mapping not correct according to the specs.
See PR 92920.
[Bug target/92923] __builtin_vec_xor() causes subregs to be used when not using V4SImode vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92923
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-12
CC||wschmidt at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Bill Schmidt ---
Confirmed. The problem is bad overloading code for vec_xor, which accepts all
vector types but translates them all into V4SI mode instead of having
individual patterns for the different modes:
In rs6000-builtin.def:
BU_ALTIVEC_2 (VXOR, "vxor", CONST, xorv4si3)
There should be multiples of these for different vector modes, not just one for
all of them. In rs6000-c.c:
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V4SF, RS6000_BTI_V4SF, RS6000_BTI_V4SF, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V4SF, RS6000_BTI_V4SF, RS6000_BTI_bool_V4SI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V4SF, RS6000_BTI_bool_V4SI, RS6000_BTI_V4SF, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V2DF, RS6000_BTI_V2DF, RS6000_BTI_V2DF, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V2DF, RS6000_BTI_V2DF, RS6000_BTI_bool_V2DI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V2DF, RS6000_BTI_bool_V2DI, RS6000_BTI_V2DF, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V2DI, RS6000_BTI_V2DI, RS6000_BTI_V2DI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V2DI, RS6000_BTI_V2DI, RS6000_BTI_bool_V2DI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V2DI, RS6000_BTI_bool_V2DI, RS6000_BTI_V2DI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V2DI,
RS6000_BTI_unsigned_V2D\
I, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V2DI, RS6000_BTI_bool_V2DI,
0\
},
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V2DI, RS6000_BTI_bool_V2DI, RS6000_BTI_unsigned_V2DI,
0\
},
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_bool_V2DI, RS6000_BTI_bool_V2DI, RS6000_BTI_bool_V2DI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_bool_V4SI, RS6000_BTI_bool_V4SI, RS6000_BTI_bool_V4SI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V4SI, RS6000_BTI_bool_V4SI, RS6000_BTI_V4SI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V4SI, RS6000_BTI_V4SI, RS6000_BTI_bool_V4SI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V4SI, RS6000_BTI_V4SI, RS6000_BTI_V4SI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V4SI, RS6000_BTI_bool_V4SI, RS6000_BTI_unsigned_V4SI,
0\
},
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V4SI, RS6000_BTI_unsigned_V4SI, RS6000_BTI_bool_V4SI,
0\
},
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V4SI, RS6000_BTI_unsigned_V4SI,
RS6000_BTI_unsigned_V4S\
I, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_bool_V8HI, RS6000_BTI_bool_V8HI, RS6000_BTI_bool_V8HI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V8HI, RS6000_BTI_bool_V8HI, RS6000_BTI_V8HI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V8HI, RS6000_BTI_V8HI, RS6000_BTI_bool_V8HI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V8HI, RS6000_BTI_V8HI, RS6000_BTI_V8HI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V8HI, RS6000_BTI_bool_V8HI, RS6000_BTI_unsigned_V8HI,
0\
},
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V8HI, RS6000_BTI_unsigned_V8HI, RS6000_BTI_bool_V8HI,
0\
},
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V8HI, RS6000_BTI_unsigned_V8HI,
RS6000_BTI_unsigned_V8H\
I, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V16QI, RS6000_BTI_bool_V16QI, RS6000_BTI_V16QI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_bool_V16QI, RS6000_BTI_bool_V16QI, RS6000_BTI_bool_V16QI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V16QI, RS6000_BTI_V16QI, RS6000_BTI_bool_V16QI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_V16QI, RS6000_BTI_V16QI, RS6000_BTI_V16QI, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V16QI, RS6000_BTI_bool_V16QI,
RS6000_BTI_unsigned_V16QI\
, 0 },
{ ALTIVEC_BUILTIN_VEC_XOR, ALTIVEC_BUILTIN_VXOR,
RS6000_BTI_unsigned_V16QI, RS6000_BTI_unsigned_V16QI,
RS6000_BTI_bool_V16QI\
, 0 },
{
[Bug target/92923] New: __builtin_vec_xor() causes subregs to be used when not using V4SImode vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92923
Bug ID: 92923
Summary: __builtin_vec_xor() causes subregs to be used when not
using V4SImode vectors
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
The following shows a problem when expanding the __builtin_vec_xor() builtin
function. We seems to always use V4SImode rather than the vector integer mode
being used. That causes subregs to be used in the rtl passes, which is
hindering optimiations:
bergner@pike:~/gcc/BUGS$ cat bug.i
typedef __attribute__((altivec(vector__))) unsigned char vec_t;
vec_t
foo (vec_t x, vec_t y)
{
return __builtin_vec_xor (x, y);
}
vec_t
bar (vec_t x, vec_t y)
{
return x ^ y;
}
bergner@pike:~/gcc/BUGS$ gcc -S -O2 bug.i -fdump-tree-all
bergner@pike:~/gcc/BUGS$ cat bug.i.005t.gimple
foo (vec_t x, vec_t y)
{
vec_t D.2848;
_1 = VIEW_CONVERT_EXPR<__vector signed int>(x);
_2 = VIEW_CONVERT_EXPR<__vector signed int>(y);
_3 = __builtin_altivec_vxor (_1, _2);
D.2848 = VIEW_CONVERT_EXPR(_3);
return D.2848;
}
bar (vec_t x, vec_t y)
{
vec_t D.2850;
D.2850 = x ^ y;
return D.2850;
}
[Bug rtl-optimization/90275] [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275
--- Comment #4 from Jakub Jelinek ---
I think this is related to the *movsi_compare0 ARM define_ins which prevents
obvious cleanups, so we end up with:
(insn 97 90 98 24 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 131 [ d_lsm.22 ])
(const_int 0 [0])))
(set (reg:SI 135)
(reg:SI 131 [ d_lsm.22 ]))
]) "pr90275.c":18:20 248 {*movsi_compare0}
(expr_list:REG_DEAD (reg:SI 131 [ d_lsm.22 ])
(nil)))
// unrelated insn that doesn't touch SI 131 or SI 135, but consumes CC register
(insn 154 98 155 24 (set (reg:SI 131 [ d_lsm.22 ])
(reg:SI 135)) "pr90275.c":18:20 241 {*arm_movsi_insn}
(expr_list:REG_DEAD (reg:SI 135)
(nil)))
where CSE is unhappy about the pseudo being copied there and back.
[Bug rtl-optimization/90275] [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-12
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek ---
Hopefully less undefined testcase that still ICEs at -O3:
int a, b, c;
long long d;
typedef __UINTPTR_TYPE__ uintptr_t;
void
foo (void)
{
char f = c;
for (;;)
{
c = a = c ? 5 : 0;
if (f)
{
b = a;
f = d;
}
if ((d || b) >= ((uintptr_t) a > (uintptr_t) ))
(b ? 0 : f) || (d -= f);
}
}
[Bug fortran/92920] [OpenMP] Implicit mapping of character scalars (nonalloc/nonptr) – shall be firstprivate not tofrom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92920 --- Comment #2 from Tobias Burnus --- Created attachment 47482 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47482=edit Draft patch – does not handle firstprivate() This is a rather complete patch – but it currently fails if firstprivate gets an absent optional argument. Test case: 'ii' of sub2 of libgomp/testsuite/libgomp.fortran/optional-map.f90
[Bug inline-asm/92921] Feature request: Automatic transliteration of AT inline asm into Intel syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92921 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The pattern in inline asm is intentionally a black box, it can contain anything and can be used for all kinds of purposes. So, doing any kind of such transformations is a bad idea.
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Started with r253266.
[Bug c++/91165] [10 Regression] error: location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Slightly further reduced #c3:
template constexpr T bar (T c) { return c; }
template struct S {
T f;
U g;
constexpr S (T c, U h) : f(c), g(h) {}
};
template
constexpr S foo (T &, U h) { return S (c, bar (h)); }
struct C { void baz (int); void qux (); };
void C::baz (int a) { foo (a, ""); }
void C::qux () { foo (0, ""); }
Seems some TARGET_EXPR is not unshared during the constexpr evaluation.
[Bug target/92922] New: [10 regression] FAIL: gcc.target/aarch64/sve/acle/asm/ldnt1_u32.c -std=c90 -O1 -g -DTEST_FULL (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92922 Bug ID: 92922 Summary: [10 regression] FAIL: gcc.target/aarch64/sve/acle/asm/ldnt1_u32.c -std=c90 -O1 -g -DTEST_FULL (internal compiler error) Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target Milestone: --- Target: aarch64-*-* spawn -ignore SIGHUP /opt/gcc/gcc-20191212/Build/gcc/xgcc -B/opt/gcc/gcc-20191212/Build/gcc/ -mabi=ilp32 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -std=c90 -O1 -g -DTEST_FULL -march=armv8.2-a+sve -fno-ipa-icf -c -o ldnt1_u32.o /opt/gcc/gcc-20191212/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/ldnt1_u32.c during RTL pass: dse1 /opt/gcc/gcc-20191212/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/ldnt1_u32.c: In function 'ldnt1_vnum_u32_1': /opt/gcc/gcc-20191212/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/ldnt1_u32.c:95:1: internal compiler error: in plus_constant, at explow.c:102 0x8ab947 plus_constant(machine_mode, rtx_def*, poly_int<2u, long>, bool) ../../gcc/explow.c:102 0x14d225f check_mem_read_rtx ../../gcc/dse.c:2148 0x14d225f check_mem_read_use ../../gcc/dse.c:2316 0xc0ceef note_uses(rtx_def**, void (*)(rtx_def**, void*), void*) ../../gcc/rtlanal.c:2024 0x14d41e3 scan_insn ../../gcc/dse.c:2425 0x14d41e3 dse_step1 ../../gcc/dse.c:2690 0x14d41e3 rest_of_handle_dse ../../gcc/dse.c:3607 0x14d41e3 execute ../../gcc/dse.c:3668
[Bug fortran/92920] [OpenMP] Implicit mapping of character scalars (nonalloc/nonptr) – shall be firstprivate not tofrom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92920 --- Comment #1 from Tobias Burnus --- BTW: Stumbled over this when looking at the OpenMP 4.5 test suite at https://github.com/SOLLVE/sollve_vv/issues/41 and their 'defaultmap' test case.
[Bug target/92904] varargs for __int128 is placed at an unaligned location and uses movdqa for the load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92904 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-12-12 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Created attachment 47481 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47481=edit gcc10-pr92904.patch Untested fix.
[Bug inline-asm/92921] New: Feature request: Automatic transliteration of AT inline asm into Intel syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92921
Bug ID: 92921
Summary: Feature request: Automatic transliteration of AT
inline asm into Intel syntax
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: warp at iki dot fi
Target Milestone: ---
gcc defaults to using AT asm syntax for x86 targets, with Intel syntax being
an option (with -masm=intel). As a consequence, any inline asm expression is
expected to likewise use AT syntax by default, and provide the Intel syntax
as an alternative (using the "{...|...}" syntax). If only the AT syntax is
provided in the inline asm expression, then gcc will just blindly copy it as-is
into the output even if the output is in Intel syntax, thus resulting in
incorrect asm.
clang, however, is able to transliterate inline asm written in AT syntax into
Intel syntax, when -masm=intel is specified, and thus the inline asm expression
doesn't need to provide both.
It would be nice if gcc had this support as well, as it makes writing inline
asm significantly more convenient (especially when large amounts of it need to
be written).
(It would also be a nice-to-have feature if one would be able to specify in the
asm() statement which syntax it's using, so one could write in Intel syntax
even when the compiler is outputting in AT syntax.)
[Bug tree-optimization/92822] [10 Regression] vfma_laneq_f32 and vmul_laneq_f32 are broken on aarch64 after r278938
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92822
Wilco changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
||wilco at gcc dot gnu.org
Component|target |tree-optimization
--- Comment #4 from Wilco ---
(In reply to nsz from comment #2)
> e.g.
>
> #include
>
> float32x2_t
> foo (float32x2_t v0, float32x4_t v1)
> {
> return vmulx_laneq_f32 (v0, v1, 0);
> }
>
> used to get translated to
>
> foo:
> fmulx v0.2s, v0.2s, v1.s[0]
> ret
>
> now it is
>
> foo:
> adrpx0, .LC0
> ldr q2, [x0, #:lo12:.LC0]
> tbl v1.16b, {v1.16b}, v2.16b
> fmulx v0.2s, v0.2s, v1.2s
> ret
> .size foo, .-foo
> .section.rodata.cst16,"aM",@progbits,16
Yes the change inserts a VEC_PERM_EXPR with random values for the upper lanes
which becomes a TBL instruction. It happens when you extract a lane from a
128-bit vector and then dup it to a 64-bit vector. Optimized tree before:
foo (float32x2_t v0, float32x4_t v1)
{
float _4;
__Float32x2_t _5;
__Float32x2_t _6;
[local count: 1073741824]:
__builtin_aarch64_im_lane_boundsi (16, 4, 0);
_4 = BIT_FIELD_REF ;
_5 = {_4, _4};
_6 = __builtin_aarch64_fmulxv2sf (v0_2(D), _5); [tail call]
return _6;
}
And after r278938:
foo (float32x2_t v0, float32x4_t v1)
{
__Float32x2_t _4;
__Float32x2_t _7;
__Float32x4_t _8;
[local count: 1073741824]:
__builtin_aarch64_im_lane_boundsi (16, 4, 0);
_8 = VEC_PERM_EXPR ;
_7 = BIT_FIELD_REF <_8, 64, 0>;
_4 = __builtin_aarch64_fmulxv2sf (v0_2(D), _7); [tail call]
return _4;
}
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 91573, which changed state. Bug 91573 Summary: Vectorization failure for a loop to do multiply-add because SLP loads unnecessarily require permutation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91573 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/91573] Vectorization failure for a loop to do multiply-add because SLP loads unnecessarily require permutation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91573 avieira at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||avieira at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from avieira at gcc dot gnu.org --- This now vectorizes for aarch64 and x86_64 with avx2 and avx512. Closing this ticket.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 91573, which changed state. Bug 91573 Summary: Vectorization failure for a loop to do multiply-add because SLP loads unnecessarily require permutation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91573 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/92920] New: [OpenMP][OpenACC] Implicit mapping of character scalars (nonalloc/nonptr) – shall be firstprivate not tofrom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92920 Bug ID: 92920 Summary: [OpenMP][OpenACC] Implicit mapping of character scalars (nonalloc/nonptr) – shall be firstprivate not tofrom Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openacc, openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Related: PR 92568 and possibly PR 92568. Per OpenMP 4.5, just before 2.15.5.1 or OpenMP 5, 2.19.7, https://www.openmp.org/spec-html/5.0/openmpsu109.html#x142-6180002.19.7 Implicit mapping of scalar variables uses firstprivate, unless they have the (OpenMP 5:) allocatable or pointer attribute or (OpenMP 4.5 or 5:) the defaultmap clause says something different. Currently, gfortran handles character strings as non-scalar: character :: c c = 'a' !$omp target c = 'b' !$omp end target print *, c ! shows 'b' due to 'tofrom' mapping; instead of 'a' w/ firstprivate end OpenACC 2.7 has in "2.5.2. Kernels Construct": "A scalar variable referenced in the kernels construct that does not appear in a data clause for the construct or any enclosing data construct will be treated as if it appeared in a copy clause."
[Bug libgomp/92843] [OpenACC] Wrong/missing dynamic reference counting for structured 'REFCOUNT_INFINITY'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843 --- Comment #12 from jules at gcc dot gnu.org --- For an adaptation of the refcount checking code as alluded to above -- see PR92848.
[Bug libgomp/92848] [OpenACC] Memory leak for simple 'acc_create', 'acc_delete' sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92848 --- Comment #6 from jules at gcc dot gnu.org --- Created attachment 47479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47479=edit Regressions with rc checking enabled These are the OpenACC tests that regress with refcount checking enabled at present.
[Bug libgomp/92848] [OpenACC] Memory leak for simple 'acc_create', 'acc_delete' sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92848 jules at gcc dot gnu.org changed: What|Removed |Added Attachment #47451|0 |1 is obsolete|| --- Comment #7 from jules at gcc dot gnu.org --- Created attachment 47480 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47480=edit Rebased patch for PR92848 Here's a rebased version of Thomas's patch. Any merge errors are my own!
[Bug libgomp/92848] [OpenACC] Memory leak for simple 'acc_create', 'acc_delete' sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92848 --- Comment #5 from jules at gcc dot gnu.org --- Created attachment 47478 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47478=edit Refcount checking for current trunk Hi, This is a merge of the refcount checking patch to current trunk, with the name of the "virtual_refcount" field changed back to the current "dynamic_refcount". With RC_CHECKING macro defined, this flags consistency errors in a large number of OpenACC tests: how many of those are user-visible problems, I am not sure. In at least some cases, we certainly have "two wrongs making a right" in that the consistency errors do not result in a user-visible problem. An assumption here is that "dynamic_refcount" is supposed to mean the same thing as "virtual_refcount" does in the overhaul patch: those references that represent dynamic data lifetimes without having links in the interlinked splay tree/target_mem_desc structure. Or otherwise, the number which the static refcount should be decreased by on encountering a "finalize" operation for the data item in question. Anyway: I hope this is useful in evaluating the rest of the refcount overhaul patch.
[Bug rtl-optimization/90275] [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275 --- Comment #2 from David Binderman --- Nothing has happened on this for over a month. Who would be best placed to look deeper into this problem ?
[Bug c++/92919] New: invalid memory access in wide_str_to_charconst when running ucn2.C testcase (caught by hwasan)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92919 Bug ID: 92919 Summary: invalid memory access in wide_str_to_charconst when running ucn2.C testcase (caught by hwasan) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: matmal01 at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Target: aarch64-none-linux-gnu When running the ucn2.C testcase, hwasan catches an invalid access in the function `wide_str_to_charconst`. The problematic line is: const char16_t p = u'\U00110003'; It seems this is to do with the size of the constant, since the line below does not trigger this invalid access. const char16_t j = u'\U0001F914'; yet changing that constant to the below does. const char16_t j = u'\U0011F914'; HWASAN output is below. ==9608==ERROR: HWAddressSanitizer: tag-mismatch on address 0xefdf80bf at pc 0x00651270 READ of size 1 at 0xefdf80bf tags: 5f/79 (ptr/mem) in thread T0 #0 0x65126c in SigTrap<0> ../../../../gcc-pdtl/libsanitizer/hwasan/hwasan_checks.h:27 #1 0x65126c in CheckAddress<(__hwasan::ErrorAction)0, (__hwasan::AccessType)0, 0> ../../../../gcc-pdtl/libsanitizer/hwasan/hwasan_checks.h:88 #2 0x65126c in __hwasan_load1 ../../../../gcc-pdtl/libsanitizer/hwasan/hwasan.cpp:469 #3 0x2b143dc in wide_str_to_charconst ../../gcc-pdtl/libcpp/charset.c:1980 #4 0x2b143dc in cpp_interpret_charconst(cpp_reader*, cpp_token const*, unsigned int*, int*) ../../gcc-pdtl/libcpp/charset.c:2045 #5 0xb31a48 in lex_charconst ../../gcc-pdtl/gcc/c-family/c-lex.c:1368 #6 0xb35964 in c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) ../../gcc-pdtl/gcc/c-family/c-lex.c:617 #7 0x89c6bc in cp_lexer_get_preprocessor_token ../../gcc-pdtl/gcc/cp/parser.c:807 #8 0x943cc0 in cp_lexer_new_main ../../gcc-pdtl/gcc/cp/parser.c:654 #9 0x943cc0 in cp_parser_new ../../gcc-pdtl/gcc/cp/parser.c:3968 #10 0x943cc0 in c_parse_file() ../../gcc-pdtl/gcc/cp/parser.c:42963 #11 0xb50c90 in c_common_parse_file() ../../gcc-pdtl/gcc/c-family/c-opts.c:1185 #12 0x16a49fc in compile_file ../../gcc-pdtl/gcc/toplev.c:458 #13 0x6466bc in do_compile ../../gcc-pdtl/gcc/toplev.c:2280 #14 0x6466bc in toplev::main(int, char**) ../../gcc-pdtl/gcc/toplev.c:2419 #15 0x649468 in main ../../gcc-pdtl/gcc/main.c:39 #16 0x93dd689c in __libc_start_main (/lib/aarch64-linux-gnu/libc.so.6+0x1f89c) [0xefdf80a0,0xefdf80c0) is a small unallocated heap chunk; size: 32 offset: 31 0xefdf80bf is located 1 bytes to the left of 2-byte region [0xefdf80c0,0xefdf80c2) allocated here: #0 0x652bc0 in __sanitizer_realloc ../../../../gcc-pdtl/libsanitizer/hwasan/hwasan_interceptors.cpp:146 #1 0x2b95f40 in xrealloc ../../gcc-pdtl/libiberty/xmalloc.c:179 #2 0x2b122ec in cpp_interpret_string_1 ../../gcc-pdtl/libcpp/charset.c:1753 #3 0x2b14284 in cpp_interpret_string(cpp_reader*, cpp_string const*, unsigned long, cpp_string*, cpp_ttype) ../../gcc-pdtl/libcpp/charset.c:1784 #4 0x2b14284 in cpp_interpret_charconst(cpp_reader*, cpp_token const*, unsigned int*, int*) ../../gcc-pdtl/libcpp/charset.c:2036 #5 0xb31a48 in lex_charconst ../../gcc-pdtl/gcc/c-family/c-lex.c:1368 #6 0xb35964 in c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) ../../gcc-pdtl/gcc/c-family/c-lex.c:617 #7 0x89c6bc in cp_lexer_get_preprocessor_token ../../gcc-pdtl/gcc/cp/parser.c:807 #8 0x943cc0 in cp_lexer_new_main ../../gcc-pdtl/gcc/cp/parser.c:654 #9 0x943cc0 in cp_parser_new ../../gcc-pdtl/gcc/cp/parser.c:3968 #10 0x943cc0 in c_parse_file() ../../gcc-pdtl/gcc/cp/parser.c:42963 #11 0xb50c90 in c_common_parse_file() ../../gcc-pdtl/gcc/c-family/c-opts.c:1185 #12 0x16a49fc in compile_file ../../gcc-pdtl/gcc/toplev.c:458 #13 0x6466bc in do_compile ../../gcc-pdtl/gcc/toplev.c:2280 #14 0x6466bc in toplev::main(int, char**) ../../gcc-pdtl/gcc/toplev.c:2419 #15 0x649468 in main ../../gcc-pdtl/gcc/main.c:39 #16 0x93dd689c in __libc_start_main (/lib/aarch64-linux-gnu/libc.so.6+0x1f89c) #17 0x64cb24 (/home/ubuntu/working-directory/gcc-hwasan-install/libexec/gcc/aarch64-unknown-linux-gnu/10.0.0/cc1plus+0x64cb24) Thread: T0 0xeffe2000 stack: [0xe544a000,0xe944a000) sz: 67108864 tls: [0x9402,0x94020850) Memory tags around the buggy address (one tag corresponds to 16 bytes): 0d 00 09 00 09 00 e7 09 09 00 e2 0c 9a 0c 0a 4a e7 0c 0d 00 0d 00 05 00 0d 00 08 00 08 00 08 00 08 00 0b 00 0b 00 0b 00 0b 00 0e 00 0e 00 05 00 0e 00 08 00 08 00 09 00 08 00 0c 00 0c 00 09 00 0c 00 0c 00 0c 00 08 00 0c 00 0b 00 0b 00 07 00 0b 00 0a 00 0a 00 09
[Bug target/92904] varargs for __int128 is placed at an unaligned location and uses movdqa for the load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92904
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||matz at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
I've started by checking the argument passing against the psABI:
struct S { long long a, b; };
struct __attribute__((aligned (16))) T { long long a, b; };
void f1 (__int128);
void f2 (int, __int128);
void f3 (int, int, __int128);
void f4 (int, int, int, __int128);
void f5 (int, int, int, int, __int128);
void f6 (int, int, int, int, int, __int128);
void f7 (int, int, int, int, int, int, __int128);
void f8 (int, int, int, int, int, int, int, __int128);
void f9 (int, ...);
void f10 (struct S);
void f11 (int, struct S);
void f12 (int, int, struct S);
void f13 (int, int, int, struct S);
void f14 (int, int, int, int, struct S);
void f15 (int, int, int, int, int, struct S);
void f16 (int, int, int, int, int, int, struct S);
void f17 (int, int, int, int, int, int, int, struct S);
void f18 (struct T);
void f19 (int, struct T);
void f20 (int, int, struct T);
void f21 (int, int, int, struct T);
void f22 (int, int, int, int, struct T);
void f23 (int, int, int, int, int, struct T);
void f24 (int, int, int, int, int, int, struct T);
void f25 (int, int, int, int, int, int, int, struct T);
void
foo ()
{
__int128 i = -1;
struct S s = { -1, -1 };
struct T t = { -1, -1 };
f1 (-1);
f2 (0, -1);
f3 (0, 0, -1);
f4 (0, 0, 0, -1);
f5 (0, 0, 0, 0, -1);
f6 (0, 0, 0, 0, 0, -1);
f7 (0, 0, 0, 0, 0, 0, -1);
f8 (0, 0, 0, 0, 0, 0, 0, -1);
f9 (0, i);
f9 (0, 0, i);
f9 (0, 0, 0, i);
f9 (0, 0, 0, 0, i);
f9 (0, 0, 0, 0, 0, i);
f9 (0, 0, 0, 0, 0, 0, i);
f9 (0, 0, 0, 0, 0, 0, 0, i);
f10 (s);
f11 (0, s);
f12 (0, 0, s);
f13 (0, 0, 0, s);
f14 (0, 0, 0, 0, s);
f15 (0, 0, 0, 0, 0, s);
f16 (0, 0, 0, 0, 0, 0, s);
f17 (0, 0, 0, 0, 0, 0, 0, s);
f9 (0, s);
f9 (0, 0, s);
f9 (0, 0, 0, s);
f9 (0, 0, 0, 0, s);
f9 (0, 0, 0, 0, 0, s);
f9 (0, 0, 0, 0, 0, 0, s);
f9 (0, 0, 0, 0, 0, 0, 0, s);
f18 (t);
f19 (0, t);
f20 (0, 0, t);
f21 (0, 0, 0, t);
f22 (0, 0, 0, 0, t);
f23 (0, 0, 0, 0, 0, t);
f24 (0, 0, 0, 0, 0, 0, t);
f25 (0, 0, 0, 0, 0, 0, 0, t);
f9 (0, t);
f9 (0, 0, t);
f9 (0, 0, 0, t);
f9 (0, 0, 0, 0, t);
f9 (0, 0, 0, 0, 0, t);
f9 (0, 0, 0, 0, 0, 0, t);
f9 (0, 0, 0, 0, 0, 0, 0, t);
}
I believe GCC follows the psABI here:
"For classification purposes __int128 is treated as if it were implemented
as:
typedef struct {
long low, high;
} __int128;
with the exception that arguments of type __int128 that are stored in
memory must be aligned on a 16-byte boundary."
and __int128 is passed the same as the aligned(16) structure containing two
long/long long fields, in particular, if both halves fit in general purpose
registers, they are passed there, without any gaps, if only half fits into gpr
and the other would need to go onto stack, it is passed on stack, and when
passed on stack, it is passed aligned on 16-byte boundary.
So, I'd say the bug is in the x86_64 va_arg expansion that when reading the
__int128 (and maybe > 8 bytes aligned struct too) from the area of spilled gprs
it should use 8 byte alignment (i.e. lower than the type has), will keep
looking into that.
Also checked with clang and that one seems to ignore the psABI completely,
hapilly passing the __int128 partially in gpr (%r9) and on the stack (that is
the f6 call and f9 (0, 0, 0, 0, 0, i);), which violates the psABI:
"If there are no registers available for any eightbyte of an argument, the
whole
argument is passed on the stack."
or that the __int128 should be passed 16-byte aligned on the stack (that is the
f8 call and f9 (0, 0, 0, 0, 0, 0, 0, -1);), which violates the psABI:
"with the exception that arguments of type __int128 that are stored in
memory must be aligned on a 16-byte boundary."
Note, the passing of struct S and struct T seems to be correct in both
compilers.
[Bug other/92901] new test case c-c++-common/goacc/clause-locations.c in r279169 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92901 Thomas Schwinge changed: What|Removed |Added Keywords||diagnostic, openacc Target|powerpc64*-linux-gnu| CC||tschwinge at gcc dot gnu.org Host|powerpc64*-linux-gnu| Build|powerpc64*-linux-gnu| --- Comment #4 from Thomas Schwinge --- For C, we get: [...]/c-c++-common/goacc/clause-locations.c:12:53: warning: conflicting reduction operations for 'sum' 12 | #pragma acc loop reduction(-:diff) reduction(-:sum) | ^ For C++, we get: [...]/c-c++-common/goacc/clause-locations.c:12:56: warning: conflicting reduction operations for 'sum' 12 | #pragma acc loop reduction(-:diff) reduction(-:sum) |^~~ For Fortran, we get: [...]/gfortran.dg/goacc/clause-locations.f90:11:47: 11 | !$acc loop reduction(-:diff) reduction(-:sum) | ^ Warning: conflicting reduction operations for 'sum' These are all three slightly different. None of them actually points to the "reduction operation". Certainly not a priority to fix or at least unify this, but still noting this here, in case anyone ever feels like improving that.
[Bug c++/92918] [8/9/10 Regression] Does not do name lookup when using from base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918 Jonathan Wakely changed: What|Removed |Added CC||nathan at gcc dot gnu.org Known to work||7.5.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89831 Target Milestone|--- |8.4 Summary|Does not do name lookup |[8/9/10 Regression] Does |when using from base class |not do name lookup when ||using from base class Known to fail||10.0, 8.3.0, 9.2.0 --- Comment #2 from Jonathan Wakely --- This regressed with r255605 [PR C++/15272] lookups with ambiguating dependent base https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00766.html PR c++/15272 * pt.c (tsubst_baselink): Don't repeat the lookup for non-dependent baselinks. PR c++/15272 * g++.dg/template/pr71826.C: Adjust for 15272 fix.
[Bug c++/92918] Does not do name lookup when using from base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-12
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Reduced:
struct Base03
{
static void impl();
};
struct ThisDoesNotCompileOnGCC : Base03
{
using Base03::impl;
static int impl(char const *);
template
auto f(const T ) const
-> decltype(impl(t))
{
return impl(t);
}
};
ThisDoesNotCompileOnGCC t;
int i = t.f("42");
92918.cc:19:40: error: no matching function for call to
‘ThisDoesNotCompileOnGCC::f(const char [3])’
19 | int i = ThisDoesNotCompileOnGCC::f("42");
|^
92918.cc:12:17: note: candidate: ‘template static decltype
(Base03::impl(t)) ThisDoesNotCompileOnGCC::f(const T&)’
12 | static auto f(const T )
| ^
92918.cc:12:17: note: template argument deduction/substitution failed:
92918.cc: In substitution of ‘template static decltype
(Base03::impl(t)) ThisDoesNotCompileOnGCC::f(const T&) [with T = char [3]]’:
92918.cc:19:40: required from here
92918.cc:13:21: error: no matching function for call to
‘ThisDoesNotCompileOnGCC::impl(const char [3])’
13 | -> decltype(impl(t))
| ^~~
92918.cc:3:17: note: candidate: ‘static void Base03::impl()’
3 | static void impl();
| ^~~~
92918.cc:3:17: note: candidate expects 0 arguments, 1 provided
[Bug target/92846] [ARC] gloating point compares not generating Invalid Operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92846 --- Comment #3 from claziss at gcc dot gnu.org --- Author: claziss Date: Thu Dec 12 08:42:21 2019 New Revision: 279274 URL: https://gcc.gnu.org/viewcvs?rev=279274=gcc=rev Log: [ARC] generate signaling FDCMPF for hard float comparisons PR 92846: ARC gcc generates FDCMP instructions which raises Invalid operation for signaling NaN only. This causes glibc iseqsig() primitives to fail (in the current ongoing glibc port to ARC) So break up the hard float compares into tw categories and for unordered compares generate the FDCMPF instructions which raised exception for either NaNs. With this fix testsuite/gcc.dg/torture/pr52451.c passes for ARC. Also no regressions for the glibc math testsuite, only 6 additional passes for test*iseqsig gcc/ -xx-xx Vineet Gupta * config/arc/arc-modes.def (CC_FPUE): New Mode CC_FPUE which helps codegen generate exceptions even for quiet NaN. * config/arc/arc.c (arc_init_reg_tables): Handle New CC_FPUE mode. (get_arc_condition_code): Likewise. (arc_select_cc_mode): LT, LE, GT, GE to use the New CC_FPUE mode. * config/arc/arc.h (REVERSE_CONDITION): Handle New CC_FPUE mode. * config/arc/predicates.md (proper_comparison_operator): Likewise. * config/arc/fpu.md (cmpsf_fpu_trap): New Pattern for CC_FPUE. (cmpdf_fpu_trap): Likewise. Signed-off-by: Vineet Gupta Modified: trunk/gcc/ChangeLog trunk/gcc/config/arc/arc-modes.def trunk/gcc/config/arc/arc.c trunk/gcc/config/arc/arc.h trunk/gcc/config/arc/fpu.md trunk/gcc/config/arc/predicates.md
[Bug fortran/92568] OpenMP 5 - implicit mapping of scalar with TARGET/ALLOCATABLE/POINTER attribute: shall be 'tofrom' mapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92568 --- Comment #1 from Tobias Burnus --- (In reply to Tobias Burnus from comment #0) > In OpenMP 4.5 (2.19.7) That should be: OpenMP 4.5, 2.15.5
