[Bug target/99781] [11 Regression] ICE in partial_subreg_p, at rtl.h:3144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781 --- Comment #2 from Arseny Solokha --- (In reply to Jakub Jelinek from comment #1) > ICEs since r8-6032-g43cacb12fc859b671464b63668794158974b2a34 when SVE > support has been added, so doesn't look like a regression to me, as before > that it would not accept that option: > invalid feature modifier in ‘-march=armv8-a+sve’ I can remove the regression marker, but I cannot change the PR priority.
[Bug target/99807] New: ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:3727
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99807 Bug ID: 99807 Summary: ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:3727 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: aarch64-linux-gnu gfortran-11.0.1-alpha20210328 snapshot (g:499fa254ae8c9752d8c2cf3130b13ffddfd83546) ICEs when compiling the following testcase w/ -march=armv8.3-a -O1 -ftree-slp-vectorize: subroutine cppco(ap, z) implicit none complex :: ap(*), z(*) z(1) = z(1) + z(2) * (ap(1)) return end subroutine cppco % aarch64-linux-gnu-gfortran-11.0.1 -march=armv8.3-a -O1 -ftree-slp-vectorize -c xrd4htvk.f90 during GIMPLE pass: slp xrd4htvk.f90:1:16: 1 | subroutine cppco(ap, z) |^ internal compiler error: in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:3727 0x7c41bf vect_slp_analyze_node_operations_1 /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:3727 0x7c41bf vect_slp_analyze_node_operations /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:3933 0x123510b vect_slp_analyze_node_operations /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:3913 0x123510b vect_slp_analyze_node_operations /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:3913 0x1237972 vect_slp_analyze_operations(vec_info*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:4120 0x123b01d vect_slp_analyze_bb_1 /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:4899 0x123b01d vect_slp_region /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:4945 0x123b01d vect_slp_bbs /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:5095 0x123ce3c vect_slp_function(function*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:5181 0x12437fa execute /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vectorizer.c:1450
[Bug c++/99806] New: ICE in tsubst_copy of gcc-trunk and tree_code_size of gcc-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99806
Bug ID: 99806
Summary: ICE in tsubst_copy of gcc-trunk and tree_code_size of
gcc-10
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/s687ePeGG
template concept C = requires (T a) { a.f(0); };
struct S { void f(auto) noexcept(); };
static_assert(C);
gcc-trunk:
:2:17: internal compiler error: in tsubst_copy, at cp/pt.c:17247
2 | struct S { void f(auto) noexcept(); };
| ^
gcc-10:
:2:17: internal compiler error: in tree_code_size, at tree.c:910
2 | struct S { void f(auto) noexcept(); };
|
[Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416 --- Comment #16 from Glen Joseph Fernandes --- > should a wording defect be raised against std::to_address(Ptr), to state that > pointer_traits being well-formed is actually a prerequisite? That's not an omission in the specification of to_address. The function is intended for pointers, and specified in terms of checking for a pointer_traits member, and this means pointer_traits must be well-formed. Adding an additional text to the specification saying this explicitly is unlikely to help anyone. The real change that users of iterators[1] would want is to make pointer_traits SFINAE friendly. [1] Users of pointers don't care much, since all the pointer types people are using with to_address(p) already have a well-formed pointer_traits.
[Bug c++/99805] New: filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
Bug ID: 99805
Summary: filesystem::path::parent_path got a wrong path
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drfeng08 at gmail dot com
Target Milestone: ---
[work@centos7 ~]$ uname -a
Linux centos7 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux
[work@centos7 ~]$ g++ --version
g++ (GCC) 10.2.1 20200804 (Red Hat 10.2.1-2)
Copyright (C) 2020 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.
[work@centos7 ~]$ which g++
/opt/rh/devtoolset-10/root/usr/bin/g++
[work@centos7 ~]$ cat ans8.cpp
#include
#include
#include
std::string get_path() {
static std::string path = "/ssd1/opt/stdpain/workspace";
return path;
}
int main() {
std::filesystem::path path(get_path());
std::filesystem::path path2 = path.parent_path();
std::cout << path << std::endl;
std::cout << path2 << std::endl;
}
output:
/ssd1/opt/stdpain/workspace
/ssd1/opt/stdpain/workspace
expect:
/ssd1/opt/stdpain/workspace
/ssd1/opt/stdpain/
[Bug target/96770] -mpure-code produces suboptimal code for relocations with small offset for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770 --- Comment #4 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:46720db72cadfb85501e102d94e06683300a2327 commit r11-7881-g46720db72cadfb85501e102d94e06683300a2327 Author: Christophe Lyon Date: Sun Mar 28 18:59:06 2021 + testsuite/arm: Improve scan-assembler in pr96770.c I'm seeing random scan-assembler-times failures in pr96770.c when LTO is used. I suspect this is because the \\+4 string matches the LTO sections, sometimes. This small patch avoids the issue, by matching arr\\+4 instead of \\+4. 2021-03-28 Christophe Lyon gcc/testsuite/ PR target/96770 * gcc.target/arm/pure-code/pr96770.c: Improve scan-assembler-times.
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602 --- Comment #35 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:297363774e6a5dca2f46a85ab086f1d9e59431ac commit r11-7880-g297363774e6a5dca2f46a85ab086f1d9e59431ac Author: Paul Thomas Date: Sun Mar 28 16:48:27 2021 +0100 Fortran: Fix problem with runtime pointer check [PR99602]. 2021-03-28 Paul Thomas gcc/fortran/ChangeLog PR fortran/99602 * trans-expr.c (gfc_conv_procedure_call): Use the _data attrs for class expressions and detect proc pointer evaluations by the non-null actual argument list. gcc/testsuite/ChangeLog PR fortran/99602 * gfortran.dg/pr99602.f90: New test. * gfortran.dg/pr99602a.f90: New test. * gfortran.dg/pr99602b.f90: New test. * gfortran.dg/pr99602c.f90: New test. * gfortran.dg/pr99602d.f90: New test.
[Bug c++/99804] New: cannot convert bit field enum to its own type in a template member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99804
Bug ID: 99804
Summary: cannot convert bit field enum to its own type in a
template member function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: phonyuc at outlook dot com
Target Milestone: ---
struct S {
enum E { A, B } e : 1; // line 2
void f1(decltype(e)) {} // line 3
template void f2() { f1(e); } // line 4
};
// -- end-of-code --
gcc (version 10.2 and earlier) won't compile this structure.
Compilation will success if any one of the following changes is made:
1. (in line 2) the member is not in enumeration type
2. (in line 2) the member is not in bit field
3. (in line 2) the width is the same as the underlying type
4. (in line 3) f1 is not a member function of S
5. (in line 4) f2 is not a member function of S
6. (in line 4) f2 is not a template function
7. (in line 4) call with a static enum value: f1(E::A)
8. (in line 4) cast the variable into its own type: f1((decltype(e))e)
The context looks similar to bug 92859 but the behaviour is different.
// -- compiler output --
$ g++ -c bit-enum-template.cc
a.cc: In member function 'void S::f2()':
a.cc:4:40: error: cannot convert 'unsigned char:1' to 'S::E'
4 | template void f2() { f1(e); } // line 4
|^
||
|unsigned char:1
a.cc:3:13: note: initializing argument 1 of 'void S::f1(S::E)'
3 | void f1(decltype(e)) {} // line 3
| ^~~~
[Bug c++/99803] New: internal compiler error: in make_typename_type, at cp/decl.c:4057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99803
Bug ID: 99803
Summary: internal compiler error: in make_typename_type, at
cp/decl.c:4057
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/4Yfnfzdhe
struct A { A(auto); };
A(unsigned) -> A:: template A;
[Bug ada/99802] New: [11 regression] Assignment of aggregate done component-by-component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802 Bug ID: 99802 Summary: [11 regression] Assignment of aggregate done component-by-component Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Created attachment 50481 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50481=edit Demonstrator, with output assembler In arm-eabi-gcc version 11.0.1 20210303 (experimental) (GCC), assigning an aggregate to a memory-mapped register is performed by assigning the components of the aggregate one-by-one to the register rather than as a whole word. The same bug is present in the x86_64-apple-darwin compiler. In compiler releases up to & including 10, this was done using a whole-word assignment. with ATSAM3X8E; use ATSAM3X8E; with ATSAM3X8E.PMC; use ATSAM3X8E.PMC; procedure Clock is begin PMC_Periph.CKGR_MOR := (KEY => 16#37#, MOSCXTEN => 1, -- main crystal oscillator enable MOSCRCEN => 1, -- main on-chip rc osc. enable MOSCXTST => 8, -- startup time others => <>); end Clock; The register is a component of a record: type PMC_Peripheral is record ... CKGR_MOR : aliased CKGR_MOR_Register; pragma Volatile_Full_Access (CKGR_MOR); ... end record with Volatile; with object as so: PMC_Periph : aliased PMC_Peripheral with Import, Address => PMC_Base; and the write respects the Volatile_Full_Access *as it writes each component separately to the register*! This fails, in this case, because the PMC hardware requires each write to this register to be accompanied by a valid value of the KEY field. The attached aggregate_assignment.zip contains Ada source, and the 10.1.0 and 11.0.1 versions of the arm-eabi cortex-m3 assembler output by -S. I've tried compiling the source in aggregate_assignment.zip with the x86_64-apple-darwin compiler, and the same bug seems to be present. NOTE, this bug is also present in GNAT CE 2020.
[Bug c++/99801] New: Address sanitizer false positive with pointer to member function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99801 Bug ID: 99801 Summary: Address sanitizer false positive with pointer to member function. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fsb4000 at yandex dot ru Target Milestone: --- Hi. Problematic piece of code: https://gcc.godbolt.org/z/s8x3KqaMb If we change `auto` to `void (Curses_table::*)()` then it works: https://gcc.godbolt.org/z/bezacsTPa clang works in both cases: https://gcc.godbolt.org/z/1e719Maa6 https://gcc.godbolt.org/z/8eqWzGzaW
[Bug fortran/98201] CSQRT function gives bad resuts at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #20 from Dominique d'Humieres --- > I think it can be closed. Thus closing.
[Bug fortran/98201] CSQRT function gives bad resuts at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201 --- Comment #19 from dpozar at ecs dot umass.edu --- I think it can be closed. never found out why this occurred, but I reloaded gfortran from another source and it worked after that. thanks, dave From: dominiq at lps dot ens.fr Sent: Sunday, March 28, 2021 8:38 AM To: David Pozar Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201 --- Comment #18 from Dominique d'Humieres --- Could this PR be closed or moved to target component? -- You are receiving this mail because: You reported the bug.
[Bug fortran/98201] CSQRT function gives bad resuts at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201 --- Comment #18 from Dominique d'Humieres --- Could this PR be closed or moved to target component?
[Bug fortran/95998] gfc_typename use of static memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95998 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from Dominique d'Humieres --- The off by one problem has been fixed by r11-7873, closing.
[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #6)
> In the reduced test cases (in comment #3 and comment #4) d is a global
> variable so it's value is zero. c is assigned in the first iteration of the
> loop (when e is zero) and used in subsequent iterations when it has a
> defined value, so the warning .seems like a clear false postive to me. (I
> didn't look at the big test case.)
Oh, yes! Sorry, my comment didn't make sense. Even simpler:
int a, d;
void f (void)
{
int c;
for (int e = 0; e < 64; e += 6)
{
if (e == 0)
c = d;
else
a += c;
}
}
[Bug c/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > (In reply to Martin Uecker from comment #3) > > The C standard says (6.3.2.1p2) > > J.2 Undefined behavior > > — The value of an object with automatic storage duration is used while it is > indeterminate (6.2.4, 6.7.9, 6.8). 6.9p10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. Is that enough?
[Bug c/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 --- Comment #4 from Andrew Pinski --- (In reply to Martin Uecker from comment #3) > The C standard says (6.3.2.1p2) J.2 Undefined behavior — The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.9, 6.8).
[Bug c/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 --- Comment #3 from Martin Uecker --- The C standard says (6.3.2.1p2) "... If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined."
