[Bug target/95737] PPC: Unnecessary extsw after negative less than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737 --- Comment #10 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:a174dc1a7f2bf0a71475ff633b130a60c0c3ff4a commit r13-582-ga174dc1a7f2bf0a71475ff633b130a60c0c3ff4a Author: Haochen Gui Date: Wed May 11 09:19:52 2022 +0800 This patch adds a combine pattern for "CA minus one". The SImode "CA minus one" can be converted to DImode as CA only has two values (0 or 1). gcc/ PR target/95737 * config/rs6000/rs6000.md (*subfsi3_carry_in_xx_64): New. gcc/testsuite/ PR target/95737 * gcc.target/powerpc/pr95737.c: New.
[Bug ipa/105639] New: [13 Regression] ICE in propagate_controlled_uses, at ipa-prop.cc:4195
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105639
Bug ID: 105639
Summary: [13 Regression] ICE in propagate_controlled_uses, at
ipa-prop.cc:4195
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
gcc 13.0.0 20220515 snapshot (g:18547874ee205d830acb31f1e3c1c89fc7725c14) ICEs
when compiling the following testcase w/ -O1:
void typedef (*cb) (void);
static void
bar (cb *fp)
{
(*fp) ();
}
void
foo (void)
{
bar (foo);
}
% gcc-13.0.0 -O1 -w -c wxhs0bau.c
during IPA pass: inline
wxhs0bau.c:13:1: internal compiler error: in propagate_controlled_uses, at
ipa-prop.cc:4195
13 | }
| ^
0x707ff4 propagate_controlled_uses
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/ipa-prop.cc:4195
0x707ff4 ipa_propagate_indirect_call_infos(cgraph_edge*, vec*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/ipa-prop.cc:4278
0xcbfe74 inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/ipa-inline-transform.cc:508
0x1d74b74 inline_to_all_callers_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/ipa-inline.cc:2473
0x1d74b74 inline_to_all_callers
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/ipa-inline.cc:2498
0x1d783fa cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/cgraph.h:3411
0x1d783fa ipa_inline
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/ipa-inline.cc:2823
0x1d783fa execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/ipa-inline.cc:3153
[Bug target/104375] [x86] Failure to recognize bzhi pattern when shr is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104375 --- Comment #3 from Hongtao.liu --- Fixed in GCC13.
[Bug target/104375] [x86] Failure to recognize bzhi pattern when shr is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104375
--- Comment #2 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:102237c9f2f2667eb73cb5473bd3a9a97296a414
commit r13-581-g102237c9f2f2667eb73cb5473bd3a9a97296a414
Author: liuhongt
Date: Thu Apr 28 15:30:06 2022 +0800
recognize bzhi pattern when there's zero_extendsidi.
backend has
16550(define_insn "*bmi2_bzhi_3_2"
16551 [(set (match_operand:SWI48 0 "register_operand" "=r")
16552(and:SWI48
16553 (plus:SWI48
16554(ashift:SWI48 (const_int 1)
16555 (match_operand:QI 2 "register_operand" "r"))
16556(const_int -1))
16557 (match_operand:SWI48 1 "nonimmediate_operand" "rm")))
16558 (clobber (reg:CC FLAGS_REG))]
16559 "TARGET_BMI2"
16560 "bzhi\t{%2, %1, %0|%0, %1, %2}"
16561 [(set_attr "type" "bitmanip")
16562 (set_attr "prefix" "vex")
16563 (set_attr "mode" "")])
But there's extra zero_extend in pattern match.
424Failed to match this instruction:
425(parallel [
426(set (reg:DI 90)
427(zero_extend:DI (and:SI (plus:SI (ashift:SI (const_int 1
[0x1])
428(subreg:QI (reg:SI 98) 0))
429(const_int -1 [0x]))
430(subreg:SI (reg:DI 95) 0
431(clobber (reg:CC 17 flags))
432])
Add new define_insn for it.
gcc/ChangeLog:
PR target/104375
* config/i386/i386.md (*bmi2_bzhi_zero_extendsidi_4): New
define_insn.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr104375.c: New test.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #18 from Jerry DeLisle --- (In reply to harper from comment #17) > On comparing that with ifort's result I think that the only remaining bug > is that if decimal='comma' then '.' is neither a decimal symbol nor a > separator (see f2018 13.6). Making this easier for others to see. With gfortran I see with the 8th sub-case: i= 8 input(i) = "2.5;" with decimal=point x(:) =2.5 666.0 ios=5010 with decimal=comma x(:) =2.5 666.0 ios=-1 i= 12 input(i) = "2.5 " with decimal=point x(:) =2.5 666.0 ios=-1 with decimal=comma x(:) =2.5 666.0 ios=-1 In these cases the decimal=comma should have never seen 2.5 With ifort: i= 8 input(i) = "2.5;" with decimal=point x(:) = 2.5000 5. ios=5010 with decimal=comma x(:) = 2.5000 666.00 ios= -1 I don't think ifort has the decimal=point part right, as if it backed up and read the digit 5 a second time. Regardless, getting closer here. I will work on the gfortran comma issue.
[Bug target/104610] memcmp () == 0 can be optimized better for avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104610 --- Comment #18 from Hongtao.liu --- Fixed in GCC13.
[Bug target/104610] memcmp () == 0 can be optimized better for avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104610 --- Comment #17 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:850a13d754497faae91afabc6958780f1d63a574 commit r13-580-g850a13d754497faae91afabc6958780f1d63a574 Author: liuhongt Date: Tue Mar 1 13:41:52 2022 +0800 Expand __builtin_memcmp_eq with ptest for OImode. gcc/ChangeLog: PR target/104610 * config/i386/i386-expand.cc (ix86_expand_branch): Use ptest for QImode when code is EQ or NE. * config/i386/i386.md (cbranchoi4): New expander. gcc/testsuite/ChangeLog: * gcc.target/i386/pr104610.c: New test.
[Bug c++/105637] [12/13 Regression] Wrong overload selected in base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105637 Rob Lefebvre changed: What|Removed |Added CC||john.robert.lefebvre@gmail. ||com --- Comment #2 from Rob Lefebvre --- This came from my project via a stack overflow post. Thanks to Ted for submitting it. FYI, this is from an older version of the Teigha DXF libraries, now called Drawings I think, https://www.opendesign.com/products/drawings.
[Bug target/105556] RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105556 --- Comment #3 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:c6e36f05fbb081abb068958d8900ad34b303a70b commit r13-579-gc6e36f05fbb081abb068958d8900ad34b303a70b Author: Peter Bergner Date: Tue May 17 21:09:29 2022 -0500 rs6000: Prefer assigning the MMA vector operands to altivec registers [PR105556] When optimizing the DGEMM kernel in OpenBLAS to use MMA, the MMA code uses all 8 accumulators, which overlap all vs0-vs31 vector registers. Current trunk assigns one of the normal vector inputs to one of the MMA instructions, which forces us to spill one of the accumulators to memory, leading to poor performance. The solution here is to replace the "wa" constraints for the vector input operands in the MMA instruction patterns with "v,?wa" so that we prefer using the altivec registers vs32-vs63 over the vs0-vs31 registers. 2022-05-17 Peter Bergner Segher Boessenkool gcc/ PR target/105556 * config/rs6000/mma.md (mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_): Replace "wa" constraints with "v,?wa". Update other operands accordingly.
[Bug middle-end/105638] New: Redundant stores aren't removed by DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105638
Bug ID: 105638
Summary: Redundant stores aren't removed by DSE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
For
$ cat foo.cpp
#include
#include
#include
class FastBoard {
public:
typedef std::pair movescore_t;
typedef std::tr1::array scoredlist_t;
protected:
std::vector m_critical;
int m_boardsize;
};
class FastState {
public:
FastBoard board;
int movenum;
protected:
FastBoard::scoredlist_t scoredmoves;
};
class KoState : public FastState {
private:
std::vector ko_hash_history;
std::vector hash_history;
};
class GameState : public KoState {
public:
void foo ();
private:
std::vector game_history;
};
void GameState::foo() {
game_history.resize(movenum);
}
$ g++ -O2 -march=skylake foo.cpp -S
generates:
...
movl$280, %edx
xorl%esi, %esi
callmemset
movq%rax, %rcx
vpxor %xmm0, %xmm0, %xmm0
addq$280, %rcx
vmovdqu %xmm0, 36(%rax)
vmovdqu %xmm0, 52(%rax)
vmovdqu %xmm0, 68(%rax)
vmovdqu %xmm0, 84(%rax)
vmovdqu %xmm0, 100(%rax)
vmovdqu %xmm0, 116(%rax)
vmovdqu %xmm0, 132(%rax)
vmovdqu %xmm0, 148(%rax)
vmovdqu %xmm0, 164(%rax)
vmovdqu %xmm0, 180(%rax)
vmovdqu %xmm0, 196(%rax)
vmovdqu %xmm0, 212(%rax)
...
Here memset has cleared 280 bytes starting from RAX. There is no need to
clear these bytes again. The optimized tree dump shows:
[local count: 444773291]:
# __cur_154 = PHI <__cur_42(14), _6(13)>
# __n_155 = PHI <__n_41(14), __n_20(D)(13)>
*__cur_154 = {};
MEM[(int * *)__cur_154] = 0B;
MEM[(int * *)__cur_154 + 8B] = 0B;
MEM[(int * *)__cur_154 + 16B] = 0B;
MEM[(struct array *)__cur_154 + 36B]._M_instance = {};
MEM [(long unsigned int * *)__cur_154 + 232B] =
{ 0, 0, 0, 0 };
MEM[(long unsigned int * *)__cur_154 + 264B] = 0B;
MEM[(long unsigned int * *)__cur_154 + 272B] = 0B;
Some of them are removed by RTL DSE. But vector stores aren't. Should
SSA DSE remove them?
[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 --- Comment #8 from Steve Kargl --- On Tue, May 17, 2022 at 07:56:18PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 > > --- Comment #7 from anlauf at gcc dot gnu.org --- > (In reply to Steve Kargl from comment #6) > > > I quoted the F2018 standard constraint. > > > > > > C708 An entity declared with the CLASS keyword shall be a dummy > > > argument or have the ALLOCATABLE or POINTER attribute. > > > > > > class(t), parameter :: y > > > > > > would seem to be missing all of the three listed attributes. > > You're right here. > > > I'll also add > > > > 7.3.2.3 CLASS type specifier > > > > The CLASS type specifier is used to declare polymorphic entities. > > A polymorphic entity is a data entity that is able to be of differing > > dynamic types during program execution. > > > > Does is make sense to given a named constant the polymorphic property? > > Well, I could imagine named constants that do not have a type (e.g. when > using CLASS(*)), as well as named constants that refer to an extensible > type. The F2023 draft even has CLASSOF. Where will this finally lead... > > I think I should ask the Intel people why their compiler accepts > > program p > type t > integer :: i = 1 > end type t > type(t), parameter :: a = t() ! Legal > class(t), parameter :: b = t() ! Likely not > class(*), parameter :: c = t() ! ... > class(*), parameter :: d = 1 ! ... > end > None of these are dummy arguments. None of these have the ALLOCATABLE attribute. None of these have the POINTER attribute. These all violate C708. For 4.2 Conformance, 2 A processor conforms to this document if: (3) it contains the capability to detect and report the use within a submitted program unit of a form or relationship that is not permitted by the numbered syntax rules or constraints, including the deleted features described in Annex B; Furthermore, the PARAMETER attribute conflicts with a dummy argument, ALLOCATABLE attribute, and POINTER attribute. At least, gfortran believes there is a conflict. subroutine foo0(x) class(*), parameter :: x end subroutine foo0 subroutine foo1() type t integer :: i = 1 end type t class(t), parameter, allocatable :: a end subroutine foo1 subroutine foo2() type t integer :: i = 1 end type t class(t), parameter, pointer :: a end subroutine foo2 % gfortran11 -c a.f90 a.f90:2:26: 2 | class(*), parameter :: x | 1 Error: PARAMETER attribute conflicts with DUMMY attribute at (1) a.f90:9:22: 9 |class(t), parameter, allocatable :: a | 1 Error: PARAMETER attribute conflicts with ALLOCATABLE attribute at (1) a.f90:16:31: 16 |class(t), parameter, pointer :: a | 1 Error: PARAMETER attribute conflicts with POINTER attribute at (1)
[Bug c++/105622] [13 Regression] ICE in cxx_eval_store_expression with [[no_unique_address]] since r13-160-g967cdbe6629653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105622 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/102307] [10/11/12/13 Regression] internal compiler error: in reshape_init_r since r10-6388-ge98ebda074bf8fc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102307 --- Comment #8 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2b0c8377729a3c62a0589713574ab939aaab commit r13-576-g2b0c8377729a3c62a0589713574ab939aaab Author: Jason Merrill Date: Tue Apr 26 11:15:04 2022 -0400 c++: constexpr ref to array of array [PR102307] The problem here is that first check_initializer calls build_aggr_init_full_exprs, which does overload resolution, but then in the case of failed constexpr throws away the result and does it again in build_functional_cast. But in the first overload resolution, reshape_init_array_1 decided to reuse the inner CONSTRUCTORs because tf_error is set, so we know we're committed. But the second pass gets confused by the CONSTRUCTORs with non-init-list types. Fixed by avoiding a second pass: instead, pass the call from build_aggr_init to build_cplus_new, which will turn it into a TARGET_EXPR. I don't bother to change the object argument because it will be replaced later in simplify_aggr_init_expr. PR c++/102307 gcc/cp/ChangeLog: * decl.cc (check_initializer): Use build_cplus_new in case of constexpr failure. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-array2.C: New test.
[Bug analyzer/105190] False positive from -Wanalyzer-malloc-leak with symbolic writes to structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105190 David Malcolm changed: What|Removed |Added Last reconfirmed||2022-05-17 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Reproducer is in gcc.dg/analyzer/symbolic-9.c
[Bug testsuite/99685] gcc.target/powerpc/divkc3-1.c and mulkc3-1.c fail for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99685 pthaugen at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from pthaugen at gcc dot gnu.org --- Fixed.
[Bug c++/105637] [12/13 Regression] Wrong overload selected in base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105637 Patrick Palka changed: What|Removed |Added Last reconfirmed||2022-05-17 Summary|[12 Regression] Wrong |[12/13 Regression] Wrong |overload selected in base |overload selected in base |class |class Target Milestone|--- |12.2 Known to work||11.3.0 Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Known to fail||12.1.0, 13.0 Keywords||rejects-valid Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Patrick Palka --- Started with r12-6075-g2decd2cabe5a4f.
[Bug testsuite/99685] gcc.target/powerpc/divkc3-1.c and mulkc3-1.c fail for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99685 --- Comment #1 from CVS Commits --- The master branch has been updated by Pat Haugen : https://gcc.gnu.org/g:2ee68beee709e48fce85b8892ff9985acc6a91a8 commit r13-574-g2ee68beee709e48fce85b8892ff9985acc6a91a8 Author: Pat Haugen Date: Tue May 17 15:53:24 2022 -0500 Fix register count when not splitting Complex IEEE 128-bit args. For ABI_V4, we do not split complex args. This created a problem because even though an arg would be passed in two VSX regs, we were only advancing the function arg counter by one VSX register. Fixed with this patch. PR target/99685 gcc/ * config/rs6000/rs6000-call.cc (rs6000_function_arg_advance_1): Bump register count when not splitting IEEE 128-bit Complex.
[Bug c++/105115] `demangle_const` causes infinite recursion and stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105115 --- Comment #2 from ronghua at iu dot edu --- The simplified PoC: $ echo _RYAbB2_ | ./binutils/cxxfilt Segmentation fault Root Cause Analysis: 1. In `rust_demangle_callback`, "_R" at beginning causes `rdm.version == 0`[1][2], so `demangle_path` in the else-branch is called[3] with `rdm.sym == "YAbB2_"`, with `rdm.next` field initialized to 0. 2. Next char 'Y' causes `demangle_type` to be called[4] in a switch-case branch, with `rdm.next == 1`. 3. Next char 'A' causes `demangle_type` to be called first[5] to consume char 'b', then `demangle_const` is called[6] with `rdm.next == 3`. 4. Next char 'B' is consumed[7], and "2_" is parsed as `integer_62`[8] to be value 3, and this vlaue is assigned to `rdm.next`, then `demangle_const` is called recursively[9]. However, currently the situation is `rdm.next == 3` again, which is exactly same as last call to `demangle_const`, and this causes infinite recursion. [1] https://github.com/bminor/binutils-gdb/blob/626d0e40e55c35a4f143b70def498734e8ed3c2a/libiberty/rust-demangle.c#L1356 [2] https://github.com/bminor/binutils-gdb/blob/626d0e40e55c35a4f143b70def498734e8ed3c2a/libiberty/rust-demangle.c#L1362 [3] https://github.com/bminor/binutils-gdb/blob/626d0e40e55c35a4f143b70def498734e8ed3c2a/libiberty/rust-demangle.c#L1453 [4] https://github.com/bminor/binutils-gdb/blob/626d0e40e55c35a4f143b70def498734e8ed3c2a/libiberty/rust-demangle.c#L759 [5] https://github.com/bminor/binutils-gdb/blob/626d0e40e55c35a4f143b70def498734e8ed3c2a/libiberty/rust-demangle.c#L934 [6] https://github.com/bminor/binutils-gdb/blob/626d0e40e55c35a4f143b70def498734e8ed3c2a/libiberty/rust-demangle.c#L938 [7] https://github.com/bminor/binutils-gdb/blob/626d0e40e55c35a4f143b70def498734e8ed3c2a/libiberty/rust-demangle.c#L1151 [8] https://github.com/bminor/binutils-gdb/blob/626d0e40e55c35a4f143b70def498734e8ed3c2a/libiberty/rust-demangle.c#L1153 [9] https://github.com/bminor/binutils-gdb/blob/626d0e40e55c35a4f143b70def498734e8ed3c2a/libiberty/rust-demangle.c#L1158 Possible Fix: The infinite recursion check added in this [commit](https://github.com/bminor/binutils-gdb/commit/f10f8617a302f45dae721eae0cd659911f03d864) should also be applied to `demangle_const`
[Bug c++/105637] New: [11 Regression] Wrong overload selected in base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105637
Bug ID: 105637
Summary: [11 Regression] Wrong overload selected in base class
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ted at lyncon dot se
Target Milestone: ---
This compiles fine in 11.3 but selects the non-const `BaseClass` overload in
12.1:
```
struct BaseClass {
// Commenting out this non-const function out will fix the compilation:
int baseDevice() { return 1; }
int baseDevice() const { return 2; }
};
template
struct DerivedClass : BaseClass {};
template
struct TopClass : DerivedClass {
public:
virtual int failsToCompile() const {
// This should choose to call the const function, but it tries to call
// the non-const version.
return BaseClass::baseDevice(); // error!
//return this->baseDevice(); // works
//return DerivedClass::baseDevice(); // works
}
};
int main() {
TopClass x;
}
```
[Bug c/105131] Warning for mismatched declaration/definition with enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105131 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #6) > > I quoted the F2018 standard constraint. > > > > C708 An entity declared with the CLASS keyword shall be a dummy > > argument or have the ALLOCATABLE or POINTER attribute. > > > > class(t), parameter :: y > > > > would seem to be missing all of the three listed attributes. You're right here. > I'll also add > > 7.3.2.3 CLASS type specifier > > The CLASS type specifier is used to declare polymorphic entities. > A polymorphic entity is a data entity that is able to be of differing > dynamic types during program execution. > > Does is make sense to given a named constant the polymorphic property? Well, I could imagine named constants that do not have a type (e.g. when using CLASS(*)), as well as named constants that refer to an extensible type. The F2023 draft even has CLASSOF. Where will this finally lead... I think I should ask the Intel people why their compiler accepts program p type t integer :: i = 1 end type t type(t), parameter :: a = t() ! Legal class(t), parameter :: b = t() ! Likely not class(*), parameter :: c = t() ! ... class(*), parameter :: d = 1 ! ... end
[Bug fortran/105633] ICE in find_array_section, at fortran/expr.cc:1582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105633
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Priority|P3 |P4
Last reconfirmed||2022-05-17
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index be94c18c836..eb1afb62e06 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1552,6 +1552,12 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
lower = ref->u.ar.as->lower[d];
upper = ref->u.ar.as->upper[d];
+ if (!lower || !upper)
+ {
+ t = false;
+ goto cleanup;
+ }
+
if (ref->u.ar.dimen_type[d] == DIMEN_VECTOR) /* Vector subscript. */
{
gfc_constructor *ci;
[Bug c++/105634] [9/10/11/12/13 Regression] ICE: Floating point exception in maybe_warn_class_memaccess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105634 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Fix: --- a/gcc/cp/call.cc +++ b/gcc/cp/call.cc @@ -10329,6 +10329,8 @@ maybe_warn_class_memaccess (location_t loc, tree fndecl, /* Finally, warn on partial copies. */ unsigned HOST_WIDE_INT typesize = tree_to_uhwi (TYPE_SIZE_UNIT (desttype)); + if (typesize == 0) + break; if (unsigned HOST_WIDE_INT partial = tree_to_uhwi (sz) % typesize) warned = warning_at (loc, OPT_Wclass_memaccess, (typesize - partial > 1
[Bug c++/105634] [9/10/11/12/13 Regression] ICE: Floating point exception in maybe_warn_class_memaccess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105634 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |9.5 CC||mpolacek at gcc dot gnu.org Summary|ICE: Floating point |[9/10/11/12/13 Regression] |exception in|ICE: Floating point |maybe_warn_class_memaccess |exception in ||maybe_warn_class_memaccess Priority|P3 |P5 Keywords||error-recovery Last reconfirmed||2022-05-17 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r249234: commit c3684b7b86da9b6b01f6fb274227fc6401df053e Author: Martin Sebor Date: Fri Jun 16 03:48:59 2017 + PR c++/80560 - warn on undefined memory operations involving non-trivial types
[Bug c/105636] New: ICE in gen_ctf_array_type, at dwarf2ctf.cc:379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105636
Bug ID: 105636
Summary: ICE in gen_ctf_array_type, at dwarf2ctf.cc:379
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
With file ./gcc/testsuite/gcc.dg/gnu99-const-expr-4.c
and option -gctf or -gbtf, at -O0 :
$ gcc-13-20220515 -c gnu99-const-expr-4.c -gctf
gnu99-const-expr-4.c:29:1: internal compiler error: in gen_ctf_array_type, at
dwarf2ctf.cc:379
29 | static int (*a7)[] = (__typeof__((int (*)[n])sa + m++))sa; /* {
dg-error "constant" } */
| ^~
0x852783 gen_ctf_array_type
../../gcc/dwarf2ctf.cc:379
0x852783 gen_ctf_type
../../gcc/dwarf2ctf.cc:881
0x852ddd ctf_do_die(die_struct*)
../../gcc/dwarf2ctf.cc:973
0x85691b ctf_debug_do_cu
../../gcc/dwarf2out.cc:32877
0x8a2461 dwarf2out_early_finish
../../gcc/dwarf2out.cc:33006
0x80cbff symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2525
[Bug c/105635] New: [12/13 Regression] ICE in gimple_parm_array_size, at pointer-query.cc:592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105635
Bug ID: 105635
Summary: [12/13 Regression] ICE in gimple_parm_array_size, at
pointer-query.cc:592
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220109 and 20220116 :
$ cat z1.c
void f (int, int[*]);
f (int x, int y)
{
return (x >= 0) != (y < 0);
}
$ gcc-13-20220515 -c z1.c -Wall
z1.c:2:1: warning: return type defaults to 'int' [-Wimplicit-int]
2 | f (int x, int y)
| ^
z1.c:2:1: warning: conflicting types for 'f'
z1.c:1:6: note: previous declaration of 'f' with type 'void(int, int *)'
1 | void f (int, int[*]);
| ^
z1.c: In function 'f':
z1.c:4:19: warning: 'return' with a value, in function returning void
[-Wreturn-type]
4 | return (x >= 0) != (y < 0);
| ~^~
z1.c:2:1: note: declared here
2 | f (int x, int y)
| ^
during GIMPLE pass: waccess
z1.c:5:1: internal compiler error: Segmentation fault
5 | }
| ^
0xc23a6f crash_signal
../../gcc/toplev.cc:322
0xb5ba8b gimple_parm_array_size
../../gcc/pointer-query.cc:592
0xb5ba8b handle_ssa_name
../../gcc/pointer-query.cc:2087
0xb5d3ec compute_objsize_r
../../gcc/pointer-query.cc:2322
0xb6047a compute_objsize(tree_node*, gimple*, int, access_ref*, pointer_query*)
../../gcc/pointer-query.cc:2356
0xb60625 pointer_query::get_ref(tree_node*, gimple*, access_ref*, int)
../../gcc/pointer-query.cc:1506
0x9624a9 check_dangling_stores
../../gcc/gimple-ssa-warn-access.cc:4573
0x962350 check_dangling_stores
../../gcc/gimple-ssa-warn-access.cc:4605
0x962350 check_dangling_stores
../../gcc/gimple-ssa-warn-access.cc:4605
0x9690a4 check_dangling_stores
../../gcc/gimple-ssa-warn-access.cc:4617
0x9690a4 execute
../../gcc/gimple-ssa-warn-access.cc:4748
[Bug c++/105634] New: ICE: Floating point exception in maybe_warn_class_memaccess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105634
Bug ID: 105634
Summary: ICE: Floating point exception in
maybe_warn_class_memaccess
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r8 :
$ cat z1.cc
struct s
{
struct {} a[] = 1.0;
void f (char *c)
{
s s;
__builtin_memcpy (, c, sizeof(s));
}
};
$ g++-13-20220515 -c z1.cc -Wall
z1.cc:3:13: error: flexible array member 's::a' in an otherwise empty 'struct
s'
3 | struct {} a[] = 1.0;
| ^
z1.cc:3:13: error: initializer for flexible array member 's::
s::a []'
z1.cc: In member function 'void s::f(char*)':
z1.cc:7:22: internal compiler error: Floating point exception
7 | __builtin_memcpy (, c, sizeof(s));
| ~^~~
0x10da4cf crash_signal
../../gcc/toplev.cc:322
0x736147 maybe_warn_class_memaccess
../../gcc/cp/call.cc:10332
0x736147 build_over_call
../../gcc/cp/call.cc:9880
0x736a87 build_new_function_call(tree_node*, vec**, int)
../../gcc/cp/call.cc:4847
0x9ecc5e finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.cc:2895
0x91b288 cp_parser_postfix_expression
../../gcc/cp/parser.cc:7888
0x932a91 cp_parser_unary_expression
../../gcc/cp/parser.cc:9037
0x90017f cp_parser_cast_expression
../../gcc/cp/parser.cc:9941
0x900a41 cp_parser_binary_expression
../../gcc/cp/parser.cc:10043
0x901470 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10347
0x90315c cp_parser_expression
../../gcc/cp/parser.cc:10517
0x906597 cp_parser_expression_statement
../../gcc/cp/parser.cc:12734
0x916ab4 cp_parser_statement
../../gcc/cp/parser.cc:12526
0x917c94 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12883
0x917d77 cp_parser_compound_statement
../../gcc/cp/parser.cc:12835
0x93ea00 cp_parser_function_body
../../gcc/cp/parser.cc:25186
0x93ea00 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25237
0x93f07a cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31369
0x93f430 cp_parser_late_parsing_for_member
../../gcc/cp/parser.cc:32335
0x911802 cp_parser_class_specifier_1
../../gcc/cp/parser.cc:26305
[Bug fortran/105633] New: ICE in find_array_section, at fortran/expr.cc:1582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105633 Bug ID: 105633 Summary: ICE in find_array_section, at fortran/expr.cc:1582 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : (follow-up of pr105230) $ cat z1.f90 program p integer, parameter :: a(:) = [1,2] print *, [a([1,2])] end $ cat z2.f90 program p integer, parameter :: a(:) = [1,2,2] print *, reshape([1,2,3,4], a([3,2])) end $ gfortran-13-20220515 -c z1.f90 z1.f90:2:29: 2 |integer, parameter :: a(:) = [1,2] | 1 Error: Parameter array 'a' at (1) cannot be automatic or of deferred shape f951: internal compiler error: Segmentation fault 0xe7b33f crash_signal ../../gcc/toplev.cc:322 0x73877d find_array_section ../../gcc/fortran/expr.cc:1582 0x739f0a simplify_const_ref ../../gcc/fortran/expr.cc:1934 0x73aa3e gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.cc:2325 0x73acab simplify_parameter_variable ../../gcc/fortran/expr.cc:2154 0x73a9d5 gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.cc:2292 0x701228 expand_constructor ../../gcc/fortran/array.cc:1827 0x703517 gfc_array_size(gfc_expr*, __mpz_struct (*) [1]) ../../gcc/fortran/array.cc:2677 0x7a61df expression_shape ../../gcc/fortran/resolve.cc:5519 0x7a61df gfc_expression_rank(gfc_expr*) ../../gcc/fortran/resolve.cc:5593 0x7a7aaf gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7223 0x7afb9c gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7154 0x7afb9c gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11966 0x7ae62f gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:10965 0x7ae988 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11956 0x7b1717 resolve_codes ../../gcc/fortran/resolve.cc:17602 0x7b17de gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17637 0x799664 resolve_all_program_units ../../gcc/fortran/parse.cc:6604 0x799664 gfc_parse_file() ../../gcc/fortran/parse.cc:6860 0x7e7eef gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug ada/105507] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507 --- Comment #1 from Christoph Reiter --- I've bisected it now: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=76f9c7f44fffb0b03266730b137313fe79f1c99e 76f9c7f44fffb0b03266730b137313fe79f1c99e is the first bad commit commit 76f9c7f44fffb0b03266730b137313fe79f1c99e Author: Bob Duff Date: Wed Feb 3 05:31:16 2021 -0500 [Ada] Variable-sized node types 167 files changed, 18305 insertions(+), 43812 deletions(-)
[Bug c++/105115] `demangle_const` causes infinite recursion and stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105115 --- Comment #1 from ronghua at iu dot edu --- Hello, It's already more than one month since my post, and the bug still exists at latest commit (e.i. e84412c6a3c3eed1a4eca5fe18f329bfa7efea40), so I would like to know why it is still `UNCONFIRMED`. Thanks.
[Bug c++/98662] [9/10/11/12/13 Regression] checking ICE in friend_accessible_p since r227023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98662 Patrick Palka changed: What|Removed |Added Summary|checking ICE in |[9/10/11/12/13 Regression] |friend_accessible_p since |checking ICE in |r227023 |friend_accessible_p since ||r227023 Target Milestone|--- |9.5 Known to fail||10.3.0, 11.2.0, 12.0, 9.4.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66957 Known to work||5.5.0 --- Comment #3 from Patrick Palka --- Thus marking as a regression.
[Bug analyzer/102471] RFE: add support to analyzer testsuite for running SAMATE/SARD tests (e.g. Juliet Test Suite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471 --- Comment #5 from David Malcolm --- Another source of possible benchmarks: https://gitlab.com/sosy-lab/benchmarking/sv-benchmarks >From SV-COMP: https://sv-comp.sosy-lab.org/ This embeds the Juliet testsuite, but also many other tests.
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 --- Comment #9 from joseph at codesourcery dot com --- N2963 is up for discussion in WG14 tomorrow, but there are still significant issues with the wording to resolve.
[Bug c++/105631] GCC internal compiler error: Segmentation fault when trying to compile Qt 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105631 --- Comment #3 from Marek Polacek --- (In reply to Ioan Angelo Mîțiu from comment #2) > Yeah, they are part of QT-package. > I'll try to assemble a minimum project/config for reproducing it but won't > be so trivial. I think that's a lot of work, and it still wouldn't help us. Just try to put -save-temps into CFLAGS, the .ii file then should be in /tmp.
[Bug preprocessor/105632] New: Canadian Cross build failure - error: attempt to use poisoned "malloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105632 Bug ID: 105632 Summary: Canadian Cross build failure - error: attempt to use poisoned "malloc" Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: lancethepants at gmail dot com Target Milestone: --- I'm having an issue where creating a "Canadian Cross" toolchain is giving me error: attempt to use poisoned "malloc" build x86_64 host armv7 target mipsel libc uclibc-ng I don't know if this is all "Canadian Cross" builds or perhaps just uclibc related. The patch I use to fix this for myself is here. https://github.com/lancethepants/gcc/commit/84eef8a8760740c6483c7236b28e2a2e22609104 I add "#define INCLUDE_MEMORY" so system.h will define it although it was necessary to put it before #include "gcc-plugin.h" as well. Here is the full error I get. In file included from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/sysroot/usr/include/sched.h:34, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/sysroot/usr/include/pthread.h:24, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/arm-tomatoware-linux-uclibcgnueabi/bits/gthr-default.h:35, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/arm-tomatoware-linux-uclibcgnueabi/bits/gthr.h:148, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/ext/atomicity.h:35, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/bits/shared_ptr_base.h:61, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/bits/shared_ptr.h:53, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/memory:77, from ../../gcc/libcc1/deleter.hh:23, from ../../gcc/libcc1/rpc.hh:25, from ../../gcc/libcc1/libcc1plugin.cc:67: /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/sysroot/usr/include/bits/sched.h:210:46: error: attempt to use poisoned "malloc" 210 | # define __sched_cpualloc(cnt) ((cpu_set_t *)malloc(__CPU_ALLOC_SIZE(cnt))) | ^ In file included from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/sysroot/usr/include/sched.h:34, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/sysroot/usr/include/pthread.h:24, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/arm-tomatoware-linux-uclibcgnueabi/bits/gthr-default.h:35, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/arm-tomatoware-linux-uclibcgnueabi/bits/gthr.h:148, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/ext/atomicity.h:35, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/bits/shared_ptr_base.h:61, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/bits/shared_ptr.h:53, from /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/include/c++/12.1.0/memory:77, from ../../gcc/libcc1/deleter.hh:23, from ../../gcc/libcc1/marshall-cp.hh:25, from ../../gcc/libcc1/libcp1plugin.cc:69: /opt/tomatoware/arm-soft-mmc/arm-tomatoware-linux-uclibcgnueabi/sysroot/usr/include/bits/sched.h:210:46: error: attempt to use poisoned "malloc" 210 | # define __sched_cpualloc(cnt) ((cpu_set_t *)malloc(__CPU_ALLOC_SIZE(cnt)))
[Bug fortran/104649] ICE in gfc_match_formal_arglist, at fortran/decl.cc:6733 since r6-1958-g4668d6f9c00d4767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104649
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #2 from kargl at gcc dot gnu.org ---
Null pointer dereference.
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index bd586e75008..8e2cd511c4d 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -6730,12 +6730,20 @@ ok:
|| (p->next == NULL && q->next != NULL))
arg_count_mismatch = true;
else if ((p->sym == NULL && q->sym == NULL)
- || strcmp (p->sym->name, q->sym->name) == 0)
+ || (p->sym && q->sym
+ && strcmp (p->sym->name, q->sym->name) == 0))
continue;
else
- gfc_error_now ("Mismatch in MODULE PROCEDURE formal "
- "argument names (%s/%s) at %C",
- p->sym->name, q->sym->name);
+ {
+ if (q->sym)
+ gfc_error_now ("Mismatch in MODULE PROCEDURE formal "
+ "argument names (%qs/%qs) at %C",
+ p->sym->name, q->sym->name);
+ else
+ gfc_error_now ("Mismatch in MODULE PROCEDURE formal argument "
+ "name, %qs, and alternate return at %C",
+ p->sym->name);
+ }
}
if (arg_count_mismatch)
[Bug c++/105169] Compiling C++ code with -fpatchable-function-entry=16,14 results in references to discarded sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105169 --- Comment #13 from CVS Commits --- The trunk branch has been updated by Giuliano Belinassi : https://gcc.gnu.org/g:7a3f38a966a52893fb5bae301a1a3d56961358fb commit r13-566-g7a3f38a966a52893fb5bae301a1a3d56961358fb Author: Giuliano Belinassi Date: Fri May 6 23:37:52 2022 -0300 PR105169 Fix references to discarded sections When -fpatchable-function-entry= is enabled, certain C++ codes fails to link because of generated references to discarded sections in __patchable_function_entry section. This commit fixes this problem by puting those references in a COMDAT section. 2022-05-06 Giuliano Belinassi gcc/ChangeLog PR c++/105169 * targhooks.cc (default_print_patchable_function_entry_1): Handle COMDAT case. * varasm.cc (switch_to_comdat_section): New (handle_vtv_comdat_section): Call switch_to_comdat_section. * varasm.h: Declare switch_to_comdat_section. gcc/testsuite/ChangeLog 2022-05-06 Giuliano Belinassi PR c++/105169 * g++.dg/modules/pr105169.h: New file. * g++.dg/modules/pr105169_a.C: New test. * g++.dg/modules/pr105169_b.C: New file.
[Bug c++/105631] GCC internal compiler error: Segmentation fault when trying to compile Qt 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105631 --- Comment #2 from Ioan Angelo Mîțiu --- Yeah, they are part of QT-package. I'll try to assemble a minimum project/config for reproducing it but won't be so trivial.
[Bug c++/105631] GCC internal compiler error: Segmentation fault when trying to compile Qt 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105631 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-05-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Marek Polacek --- I don't have those headers. Please provide a preprocessed source file (use -save-temps, upload the .ii file), thanks.
[Bug tree-optimization/105458] [12/13 Regression] ICE in set_relation, at value-relation.cc:609 since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105458 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:6101a276c34b94f692206739d98aa7faf2e7b2ad commit r13-564-g6101a276c34b94f692206739d98aa7faf2e7b2ad Author: Andrew MacLeod Date: Mon May 16 21:39:30 2022 -0400 Check for equivalence after merging relations. When registering a relation, we need to merge with any existing relation before checking if it was an equivalence... otherwise it was not being handled properly. gcc/ PR tree-optimization/105458 * value-relation.cc (path_oracle::register_relation): Merge, then check for equivalence. gcc/testsuite/ * gcc.dg/pr105458.c: New.
[Bug target/105624] [13 Regression] ICE in final_scan_insn_1, at final.cc:2861 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105624 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Uroš Bizjak --- Fixed by revert.
[Bug c++/105631] New: GCC internal compiler error: Segmentation fault when trying to compile Qt 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105631 Bug ID: 105631 Summary: GCC internal compiler error: Segmentation fault when trying to compile Qt 6.3 Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ioan.mitiu at zimperium dot com Target Milestone: --- Got following error when tried to compile sources after a migration from Qt 5.12.12 -> Qt 6.3: == /opt/qt/qt-6.3.0/include/QtCore/qfuture_impl.h:137:34: internal compiler error: Segmentation fault 137 | std::is_class_v | ^~ 0xe4c988 internal_error(char const*, ...) ???:0 0x9ecbcd class_decl_loc_t::add(cp_parser*, unsigned int, tag_types, tree_node*, bool, bool) ???:0 0x14e7873 c_parse_file() ???:0 0x14c9d9e c_common_parse_file() ???:0 = In order to reproduce it is needed only to have following includes: #include #include together with a member variable like: QFutureWatcher> targetsResultWatcher;
[Bug target/105624] [13 Regression] ICE in final_scan_insn_1, at final.cc:2861 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105624 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:61a6923e8917b6efcf349515a00a485dfd5b42e4 commit r13-563-g61a6923e8917b6efcf349515a00a485dfd5b42e4 Author: Uros Bizjak Date: Tue May 17 17:22:26 2022 +0200 i386: Fix ICE in final_scan_insn_1 [PR105624] Apparently const_int_operand and other const*_operand predicates do need constraints. Revert the offending patch that caused ICE. 2022-05-17 Uroš Bizjak gcc/ChangeLog: PR target/105624 Revert: * config/i386/i386.md: Remove constraints when used with const_int_operand, const0_operand, const_1_operand, constm1_operand, const8_operand, const128_operand, const248_operand, const123_operand, const2367_operand, const1248_operand, const359_operand, const_4_or_8_to_11_operand, const48_operand, const_0_to_1_operand, const_0_to_3_operand, const_0_to_4_operand, const_0_to_5_operand, const_0_to_7_operand, const_0_to_15_operand, const_0_to_31_operand, const_0_to_63_operand, const_0_to_127_operand, const_0_to_255_operand, const_0_to_255_mul_8_operand, const_1_to_31_operand, const_1_to_63_operand, const_2_to_3_operand, const_4_to_5_operand, const_4_to_7_operand, const_6_to_7_operand, const_8_to_9_operand, const_8_to_11_operand, const_8_to_15_operand, const_10_to_11_operand, const_12_to_13_operand, const_12_to_15_operand, const_14_to_15_operand, const_16_to_19_operand, const_16_to_31_operand, const_20_to_23_operand, const_24_to_27_operand and const_28_to_31_operand. * config/i386/mmx.md: Ditto. * config/i386/sse.md: Ditto. * config/i386/subst.md: Ditto. * config/i386/sync.md: Ditto. gcc/testsuite/ChangeLog: PR target/105624 * gcc.target/i386/pr105624.c: New test.
[Bug debug/105630] New: [10/11/12/13 Regression] '-fcompare-debug' failure w/ -O1 -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105630
Bug ID: 105630
Summary: [10/11/12/13 Regression] '-fcompare-debug' failure w/
-O1 -ftree-parallelize-loops=2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc 13.0.0 20220515 snapshot (g:18547874ee205d830acb31f1e3c1c89fc7725c14) fails
-fcompare-debug check when compiling the following testcase w/ -O1
-ftree-parallelize-loops=2:
int m;
static int n;
void
foo (void)
{
int *arr[] = { , , };
int unused = n;
m = 0;
}
void
bar (int *arr, int i)
{
while (i < 1)
arr[i++] = 1;
}
aarch64-linux-gnu-gcc-13.0.0 -O1 -fcompare-debug -ftree-parallelize-loops=2 -c
fjosrfpk.c
aarch64-linux-gnu-gcc-13.0.0: error: fjosrfpk.c: '-fcompare-debug' failure
--- fjosrfpk.c.gkd
+++ fjosrfpk.gk.c.gkd
@@ -360,7 +360,7 @@
1: int i;
2: signed int D.;
-;; Function bar._loopfn.0 (bar._loopfn.0, funcdef_no=2, cgraph_uid=3,
symbol_order=5)
+;; Function bar._loopfn.0 (bar._loopfn.0, funcdef_no=2, cgraph_uid=3,
symbol_order=6)
(note # 0 0 NOTE_INSN_DELETED)
(note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
It was originally reported in PR105415 comment 8.
[Bug middle-end/105629] New: [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105629 Bug ID: 105629 Summary: [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org Target Milestone: --- Created attachment 52987 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52987=edit pr94589-2.C.252t.optimized The test g++.dg/opt/pr94589-2.C is last known passing for cris-elf with r13-172-g1e2334302d6ad5. For r13-211-g0c7bce0ac184c0 it failed, and has failed since then, including r13-555-g1815462a6e53: testrun output: FAIL: g++.dg/opt/pr94589-2.C -std=gnu++20 scan-tree-dump-times optimized "[ij]_[0-9]+\\(D\\) (?:<|<=|==|!=|>|>=) [ij]_[0-9]+\\(D\\)" 12 FAIL: g++.dg/opt/pr94589-2.C -std=gnu++20 scan-tree-dump-times optimized "i_[0-9]+\\(D\\) (?:<|<=|==|!=|>|>=) 5\\.0" 12 In g++.log: PASS: g++.dg/opt/pr94589-2.C -std=gnu++20 (test for excess errors) g++.dg/opt/pr94589-2.C -std=gnu++20 : pattern found 14 times FAIL: g++.dg/opt/pr94589-2.C -std=gnu++20 scan-tree-dump-times optimized "[ij]_[0-9]+\\(D\\) (?:<|<=|==|!=|>|>=) [ij]_[0-9]+\\(D\\)" 12 g++.dg/opt/pr94589-2.C -std=gnu++20 : pattern found 14 times FAIL: g++.dg/opt/pr94589-2.C -std=gnu++20 scan-tree-dump-times optimized "i_[0-9]+\\(D\\) (?:<|<=|==|!=|>|>=) 5\\.0" 12 See attachment for contents of pr94589-2.C.252t.optimized at r13-555-g1815462a6e53. The test appears to fail in the same way according to gcc-testresults@, for m68k-unknown-linux-gnu (posts https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761149.html and https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761602.html) and s390x-ibm-linux-gnu (posts https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761118.html and https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761552.html).
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #22 from Jeff Muizelaar --- GCC doesn't support clang's xyzw vector attributes, so it still not easy to build the clang path in GCC
[Bug tree-optimization/105585] [12/13 Regression] Spurious stringop-overflow warning with since r12-4725-g88b504b7a8c5affb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105585 Martin Sebor changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from Martin Sebor --- The warning is caused by the if statement: if p is null, accessing the p->a member is undefined. It triggers because the GCC optimizer splits the code into two branches: one with a nonnull p and another with a null p. The second one triggers the warning. If p can be null then moving the increment to the body of the if statement avoids the undefined behavior (and the warning). If p cannot be null then making the if statement unconditional also avoids the warning.
[Bug target/105602] [OpenMP][gcn] — Support multiple arch in gcc/config/gcn/t-omp-device? Add 'amdgcn' (additionally to/instead of 'amd')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105602 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tobias Burnus --- FIXED – by now supporting both 'amdgcn' besides 'gcn'. Side the permitted values are now also documented in https://gcc.gnu.org/onlinedocs/libgomp/ via/since commit r13-558-g61fe7b7d463f2f6bbeb175c345a68b844b396d56
[Bug target/105602] [OpenMP][gcn] — Support multiple arch in gcc/config/gcn/t-omp-device? Add 'amdgcn' (additionally to/instead of 'amd')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105602 --- Comment #1 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:ebe5dace8c318b38f42cfe1d148e90dcdfadb31e commit r13-557-gebe5dace8c318b38f42cfe1d148e90dcdfadb31e Author: Tobias Burnus Date: Tue May 17 15:48:40 2022 +0200 gcn/t-omp-device: Add 'amdgcn' as 'arch' [PR105602] Improve cross-compiler handling. gcc/ChangeLog: PR target/105602 * config/gcn/t-omp-device (arch): Add 'amdgcn' besides existing 'gcn'. * config/gcn/gcn.cc (gcn_omp_device_kind_arch_isa): Likewise.
[Bug c++/105626] -Wformat should accept u8"" strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek ---
Possible fix:
--- a/gcc/c-family/c-format.cc
+++ b/gcc/c-family/c-format.cc
@@ -1742,7 +1742,8 @@ check_format_arg (void *ctx, tree format_tree,
}
tree underlying_type
= TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (format_tree)));
- if (underlying_type != char_type_node)
+ if (underlying_type != char_type_node
+ && !(flag_char8_t && underlying_type == char8_type_node))
{
if (underlying_type == char16_type_node
|| underlying_type == char32_type_node
[Bug c/105628] False positive with -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105628
--- Comment #1 from Andrew Pinski ---
The warning is correct but it should not be done.
Simpele testcase:
struct s{ int f; };
int g(struct s t){
return (t.f? : 0)? 1 : 0;
}
The problem is gcc did some optimizations before the warning and pushed the
implicit != 0 into each arm of the ?; operator
[Bug c/105628] New: False positive with -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105628 Bug ID: 105628 Summary: False positive with -Waddress Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jochen447 at concept dot de Target Milestone: --- Created attachment 52986 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52986=edit minified example program to show the false positive Option -Wall also enables -Waddress, which causes a lot of false positives like shown in my attached example problem (minimized and anonymized real world example): waddress.c: In function ‘comp_has_ExtraPtr’: waddress.c:44:29: warning: the comparison will always evaluate as ‘true’ for the pointer operand in ‘(struct Extra **)>pin + 4’ must not be NULL [-Waddress] 44 | return ExtraPtrOf(comp) ? 1 : 0; | ^ It only seems to be emitted when using the ?-operator. # gcc -v ... gcc version 12.1.1 20220507 (Red Hat 12.1.1-1) (GCC) # uname -a Linux fedora 5.17.6-300.fc36.x86_64 #1 SMP PREEMPT Mon May 9 15:47:11 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[Bug debug/105415] [9/10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415 --- Comment #9 from Jakub Jelinek --- Sure, that must be a different problem.
[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614 Martin Liška changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #6 from Martin Liška --- The GCC divergence comes from https://github.com/gcc-mirror/gcc/commit/9f943b2446f2d0a345bbf9b4be3d3a4316372270
[Bug debug/105627] New: -fcompare-debug failure at -Og for powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105627
Bug ID: 105627
Summary: -fcompare-debug failure at -Og for
powerpc64le-unknown-linux-gnu
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: powerpc64le-unknown-linux-gnu
Created attachment 52985
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52985=edit
reduced testcase
Compiler output:
$ powerpc64le-unknown-linux-gnu-gcc -Og -fcompare-debug testcase.c -save-temps
testcase.c: In function 'foo':
testcase.c:10:1: warning: GCC vector returned by reference: non-standard ABI
extension with no compatibility guarantee [-Wpsabi]
10 | {
| ^
$ diff -u *gkd
--- a-testcase.c.gkd2022-05-17 14:16:43.376878594 +0200
+++ a-testcase.gk.c.gkd 2022-05-17 14:16:43.433544950 +0200
@@ -93,25 +93,8 @@
(expr_list:REG_EQUAL (symbol_ref/u:DI ("*.LC0") [flags 0x82])
(nil)))
(insn # 0 0 (set (reg:V16QI 69 5 [194])
-(vec_select:V16QI (mem/u/c:V16QI (reg/f:DI 6 6 [193]) [ S16 A128])
-(parallel [
-(const_int 8 [0x8])
-(const_int 9 [0x9])
-(const_int 10 [0xa])
-(const_int 11 [0xb])
-(const_int 12 [0xc])
-(const_int 13 [0xd])
-(const_int 14 [0xe])
-(const_int 15 [0xf])
-(const_int 0 [0])
-(const_int 1 [0x1])
-(const_int 2 [0x2])
-(const_int 3 [0x3])
-(const_int 4 [0x4])
-(const_int 5 [0x5])
-(const_int 6 [0x6])
-(const_int 7 [0x7])
-]))) "testcase.c":11:5# {*vsx_lxvd2x16_le_V16QI}
+(mem/u/c:V16QI (and:DI (reg/f:DI 6 6 [193])
+(const_int -16 [0xfff0])) [ S16 A128]))
"testcase.c":11:5# {vsx_movv16qi_64bit}
(expr_list:REG_DEAD (reg/f:DI 6 6 [193])
(nil)))
(insn # 0 0 (set (reg:V16QI 69 5 [orig:164 _56 ] [164])
@@ -1062,26 +1045,9 @@
...
$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-555-20220517114234-g1815462a6e5-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/13.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-555-20220517114234-g1815462a6e5-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220517 (experimental) (GCC)
[Bug c++/105626] New: -Wformat should accept u8"" strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
Bug ID: 105626
Summary: -Wformat should accept u8"" strings
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
The discussion about this topic on gcc@
(https://gcc.gnu.org/pipermail/gcc/2022-May/238673.html) ended with the
conclusion that gcc should not disregard the cast in code like this:
#include
int main()
{
printf((const char*) u8"test %d\n", 1);
return 0;
}
With -Wformat this code produces with gcc 12:
t.cc: In function ‘int main()’:
t.cc:5:24: warning: format string is not an array of type ‘char’ [-Wformat=]
5 | printf((const char*) u8"test %d\n", 1);
|^
Since
a) there are no I/O functions for u8 strings in C++20
b) using u8 strings is necessary in reliable code
c) it is safe to perform the analysis -Wformat does on u8 strings
I suggest that u8 strings are allowed when testing for -Wformat.
[Bug ipa/105625] Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 --- Comment #6 from Martin Liška --- Good, I can prepare a GCC patch once the binutils support is there.
[Bug debug/105415] [9/10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415
Arseny Solokha changed:
What|Removed |Added
Summary|[9/10/11/12 Regression] |[9/10/11/12/13 Regression]
|'-fcompare-debug' failure |'-fcompare-debug' failure
|w/ -O2 |w/ -O2
|-ftree-parallelize-loops=2 |-ftree-parallelize-loops=2
|since |since
|r7-4900-g59ec925b1199f9 |r7-4900-g59ec925b1199f9
--- Comment #8 from Arseny Solokha ---
I still get a similar failure w/ gcc 13.0.0 20220515 snapshot:
@@ -360,7 +360,7 @@
1: int i;
2: signed int D.;
-;; Function bar._loopfn.0 (bar._loopfn.0, funcdef_no=2, cgraph_uid=3,
symbol_order=5)
+;; Function bar._loopfn.0 (bar._loopfn.0, funcdef_no=2, cgraph_uid=3,
symbol_order=6)
(note # 0 0 NOTE_INSN_DELETED)
(note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
upon the following change to the original testcase:
@@ -4,13 +4,10 @@ static int n;
void
foo (void)
{
- int s = 0;
+ int *arr[] = { , , };
+ int unused = n;
- while (m < 1)
-{
- s += n;
- ++m;
-}
+ m = 0;
}
void
Do you want me to open a separate PR for that?
[Bug target/105624] [13 Regression] ICE in final_scan_insn_1, at final.cc:2861 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105624 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-05-17 --- Comment #2 from Uroš Bizjak --- I'll revert the offending patch.
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #21 from Arseny Solokha --- I believe this PR needs some reassessment now, given __builtin_shufflevector has been finally implemented.
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 105621, which changed state. Bug 105621 Summary: [13 Regression] Wrong code with -O3 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105621 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug target/105613] [13 Regression] wrong code with unsigned V1TI comparison since r13-458-gd75d4293dcc029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105613 Martin Liška changed: What|Removed |Added CC||vsevolod.livinskiy at gmail dot co ||m --- Comment #8 from Martin Liška --- *** Bug 105621 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/105621] [13 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105621 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 105613 ***
[Bug ipa/105600] ICE with LTO when building Mumble from git on arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105600 --- Comment #3 from Alex Coplan --- Alternatively a Dockerfile to build the Gentoo environment needed to reproduce the issue might help.
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #8 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to nick87720z from comment #0)
> > Unlike C++, where type is specified as "enum class type ..."
>
> That's not how C++ does it, the correct syntax is:
>
> enum foo_type : int { foo, bar, baz };
clang supports this as an extension in C:
$ clang -Weverything enum.c
warning: include location '/usr/local/include' is unsafe for cross-compilation
[-Wpoison-system-directories]
enum.c:1:6: warning: enumeration types with a fixed underlying type are a Clang
extension [-Wfixed-enum-extension]
enum : int { a }; int main(void) { return 0; }
^
2 warnings generated.
vs. with gcc:
$ /usr/local/bin/gcc enum.c
enum.c:1:6: error: expected '{' before ':' token
1 | enum : int { a }; int main(void) { return 0; }
| ^
[Bug target/105624] [13 Regression] ICE in final_scan_insn_1, at final.cc:2861 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105624 --- Comment #1 from Uroš Bizjak --- Ho-hum - this was my patch that removed constraint from const_int predicates. We are talking about: (define_insn_and_split "*anddi_1_btr" [(set (match_operand:DI 0 "nonimmediate_operand" "=rm") (and:DI (match_operand:DI 1 "nonimmediate_operand" "%0") (match_operand:DI 2 "const_int_operand"))) (clobber (reg:CC FLAGS_REG))] Apparently, the assumption that const_int predicates do not need cosntraints does not hold.
[Bug ipa/105600] ICE with LTO when building Mumble from git on arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105600 Alex Coplan changed: What|Removed |Added CC||acoplan at gcc dot gnu.org --- Comment #2 from Alex Coplan --- Hi Sam, can you reproduce this in (e.g.) an AArch64 Ubuntu environment? This might make it easier for others to attempt to reproduce, as I suspect not many have access to an AArch64 Gentoo environment.
[Bug target/105613] [13 Regression] wrong code with unsigned V1TI comparison since r13-458-gd75d4293dcc029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105613 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug target/105613] [13 Regression] wrong code with unsigned V1TI comparison since r13-458-gd75d4293dcc029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105613 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:254cbf72661b932eb039220fccef9a2546ab8f4e commit r13-552-g254cbf72661b932eb039220fccef9a2546ab8f4e Author: Jakub Jelinek Date: Tue May 17 12:10:30 2022 +0200 i386: Fix up V2DI and V1TI inequality comparisons [PR105613] The recent r13-458 change to introduce vec_cmpeqv1tiv1ti and add TARGET_SSE2 support to vec_cmpeqv2div2di works nicely for equality comparisons, but as the testcase shows doesn't work for inequality comparisons. For EQ if we perform comparison with twice as many half-sized elemenets, the result should be ~0 when both halves are ~0 only (both halves need to be equal for the whole to be equal), otherwise 0, so AND is the correct operation for it. But for NE, the result should be ~0 when either of the halves is ~0 (if either half is not equal, the whole is not equal) and so the right operation for NE is IOR, not AND. 2022-05-17 Jakub Jelinek PR target/105613 * config/i386/sse.md (vec_cmpeqv2div2di, vec_cmpeqv1tiv1ti): Use andv4si3 only for EQ, for NE use iorv4si3 instead. * gcc.c-torture/execute/pr105613.c: New test.
[Bug target/105617] [12/13 Regression] Slp is maybe too aggressive in some/many cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617 --- Comment #12 from Michael_S --- On related note... One of the historical good features of gcc relatively to other popular compilers was absence of auto-vectorization at -O2. When did you decide to change it and why?
[Bug target/105617] [12/13 Regression] Slp is maybe too aggressive in some/many cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #11 from Michael_S ---
(In reply to Richard Biener from comment #10)
> (In reply to Hongtao.liu from comment #9)
> > (In reply to Hongtao.liu from comment #8)
> > > (In reply to Hongtao.liu from comment #7)
> > > > Hmm, we have specific code to add scalar->vector(vmovq) cost to vector
> > > > construct, but it seems not to work here, guess it's because ,and
> > > > thought
> > > > it was load not scalar？
> > > Yes, true for as gimple_assign_load_p
> > >
> > >
> > > (gdb) p debug_gimple_stmt (def)
> > > 72# VUSE <.MEM_46>
> > > 73r0.0_20 = r0;
> > It's a load from stack, and finally eliminated in rtl dse1, but here the
> > vectorizer doesn't know.
>
> Yes, it's difficult for the SLP vectorizer to guess whether rN will come
> from memory or not. Some friendlier middle-end representation for
> add-with-carry might be nice - the x86 backend could for example fold
> __builtin_ia32_addcarryx_u64 to use a _Complex unsinged long long for the
> return, ferrying the carry in __imag. Alternatively we could devise
> some special GIMPLE_ASM kind ferrying RTL and not assembly so the
> backend could fold it directly to RTL on GIMPLE with asm constraints
> doing the plumbing ... (we'd need some match-scratch and RTL expansion
> would still need to allocate the actual pseudos).
>
>[local count: 1073741824]:
> _1 = *srcB_17(D);
> _2 = *srcA_18(D);
> _30 = __builtin_ia32_addcarryx_u64 (0, _2, _1, );
> _3 = MEM[(const uint64_t *)srcB_17(D) + 8B];
> _4 = MEM[(const uint64_t *)srcA_18(D) + 8B];
> _5 = (int) _30;
> _29 = __builtin_ia32_addcarryx_u64 (_5, _4, _3, );
> _6 = MEM[(const uint64_t *)srcB_17(D) + 16B];
> _7 = MEM[(const uint64_t *)srcA_18(D) + 16B];
> _8 = (int) _29;
> _28 = __builtin_ia32_addcarryx_u64 (_8, _7, _6, );
> _9 = MEM[(const uint64_t *)srcB_17(D) + 24B];
> _10 = MEM[(const uint64_t *)srcA_18(D) + 24B];
> _11 = (int) _28;
> __builtin_ia32_addcarryx_u64 (_11, _10, _9, );
> r0.0_12 = r0;
> r1.1_13 = r1;
> _36 = {r0.0_12, r1.1_13};
> r2.2_14 = r2;
> r3.3_15 = r3;
> _37 = {r2.2_14, r3.3_15};
> vectp.9_35 = dst_19(D);
> MEM [(uint64_t *)vectp.9_35] = _36;
> vectp.9_39 = vectp.9_35 + 16;
> MEM [(uint64_t *)vectp.9_39] = _37;
>
> so for the situation at hand I don't see any reasonable way out that
> doesn't have the chance of regressing things in other places (like
> treat loads from non-indexed auto variables specially or so). The
> only real solution is to find a GIMPLE representation for
> __builtin_ia32_addcarryx_u64 that doesn't force the alternate output
> to memory.
How about simple heuristic: "Never auto-vectorize integer code unless in inner
loop"?
It would be optimal >80% of time and even in cases where it's sub-optimal the
impact is likely single-digit per cents. On the other hand, the impact of
mistake in the opposit direction (i.e. over-vectorization) is often quite
large.
[Bug rtl-optimization/105459] [12/13 Regression] ICE: Segmentation fault (in record_operand_costs) since r12-3721-g63c6446f77b9001d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459 --- Comment #7 from Kewen Lin --- I wonder if it's fine to move init_function_start downward after execute_all_ipa_transforms call? the testing is ongoing. --- a/gcc/cgraphunit.cc +++ b/gcc/cgraphunit.cc @@ -1817,7 +1817,6 @@ cgraph_node::expand (void) gcc_assert (DECL_STRUCT_FUNCTION (decl)); push_cfun (DECL_STRUCT_FUNCTION (decl)); - init_function_start (decl); gimple_register_cfg_hooks (); @@ -1827,6 +1826,8 @@ cgraph_node::expand (void) if (ipa_transforms_to_apply.exists ()) execute_all_ipa_transforms (false); + init_function_start (decl); + /* Perform all tree transforms and optimizations. */
[Bug rtl-optimization/105459] [12/13 Regression] ICE: Segmentation fault (in record_operand_costs) since r12-3721-g63c6446f77b9001d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
Kewen Lin changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Kewen Lin ---
The r12-3721 makes it get the exact fp_expression info and more optimization
chance then exposes this issue.
Some diff from a.wpa.085i.inline between the good and bad:
-IPA function summary for bar/2 inlinable
+IPA function summary for bar/2 inlinable fp_expression
+Copying FP flags from bar/2 to foo/3
...
+Copying FP flags from foo/3 to main/5
...
-IPA function summary for main/5 inlinable
+IPA function summary for main/5 inlinable fp_expression
When we are expand node for function main, we create the target global for its
target option node, later init_function_start -> initialize_rtl ->
backend_init_target -> ira_init -> ira_init_costs initialize the init_cost.
Then it comes to handle ipa_transforms like:
if (ipa_transforms_to_apply.exists ())
execute_all_ipa_transforms (false);
try to call input_function for callees. In this case, function quux share the
same target option node with main, when switching back to main, it hits the
condition in
else if (flag_unsafe_math_optimizations
!= TREE_TARGET_OPTION (new_tree)->x_ix86_unsafe_math_optimizations
|| (flag_excess_precision
!= TREE_TARGET_OPTION (new_tree)->x_ix86_excess_precision))
{
cl_target_option_restore (_options, _options_set,
TREE_TARGET_OPTION (new_tree));
ix86_excess_precision = flag_excess_precision;
ix86_unsafe_math_optimizations = flag_unsafe_math_optimizations;
DECL_FUNCTION_SPECIFIC_TARGET (fndecl) = new_tree
= build_target_option_node (_options, _options_set);
if (TREE_TARGET_GLOBALS (new_tree))
restore_target_globals (TREE_TARGET_GLOBALS (new_tree));
else if (new_tree == target_option_default_node)
restore_target_globals (_target_globals);
else
TREE_TARGET_GLOBALS (new_tree) = save_target_globals_default_opts ();
}
it calls save_target_globals_default_opts for new target globals. Note that the
previous ira_int in target global has been initialized by backend_init_target,
while this new created target global doesn't, it's associated to the target
node newly created for main. There is no other places to initialize ira_int, so
it gets ICE during ira pass.
[Bug tree-optimization/105618] [11/12 Regression] Missed loop body simplification by -O3 (trunk v.s. 10.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105618 Richard Biener changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] Missed |Missed loop body|loop body simplification by |simplification by -O3 |-O3 (trunk v.s. 10.3) |(trunk v.s. 10.3) | Known to work||13.0 --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/105618] [11/12/13 Regression] Missed loop body simplification by -O3 (trunk v.s. 10.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105618 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ebce0e9bd8d714a8607ae24331a3d842b0d11859 commit r13-550-gebce0e9bd8d714a8607ae24331a3d842b0d11859 Author: Richard Biener Date: Tue May 17 09:45:02 2022 +0200 tree-optimization/105618 - restore load sinking The PR97330 fix caused some missed sinking of loads out of loops the following patch re-instantiates. 2022-05-17 Richard Biener PR tree-optimization/105618 * tree-ssa-sink.cc (statement_sink_location): For virtual PHI uses ignore those defining the used virtual operand. * gcc.dg/tree-ssa/ssa-sink-19.c: New testcase.
[Bug tree-optimization/105618] [11/12/13 Regression] Missed loop body simplification by -O3 (trunk v.s. 10.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105618 Richard Biener changed: What|Removed |Added Keywords|needs-bisection | --- Comment #4 from Richard Biener --- I'm testing a patch.
[Bug tree-optimization/105618] [11/12/13 Regression] Missed loop body simplification by -O3 (trunk v.s. 10.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105618
--- Comment #3 from Richard Biener ---
There was quite some massaging in handling of PHI uses, notably we now have
/* For PHI nodes the block we know sth about is the incoming
block
with the use. */
if (gimple_code (use_stmt) == GIMPLE_PHI)
{
/* In case the PHI node post-dominates the current insert
location we can disregard it. But make sure it is not
dominating it as well as can happen in a CFG cycle. */
if (commondom != bb
&& !dominated_by_p (CDI_DOMINATORS, commondom, bb)
&& dominated_by_p (CDI_POST_DOMINATORS, commondom, bb)
/* If the blocks are possibly within the same irreducible
cycle the above check breaks down. */
&& !((bb->flags & commondom->flags & BB_IRREDUCIBLE_LOOP)
&& bb->loop_father == commondom->loop_father)
&& !((commondom->flags & BB_IRREDUCIBLE_LOOP)
&& flow_loop_nested_p (commondom->loop_father,
bb->loop_father))
&& !((bb->flags & BB_IRREDUCIBLE_LOOP)
&& flow_loop_nested_p (bb->loop_father,
commondom->loop_father)))
continue;
and already the first !dominated_by_p (CDI_DOMINATORS, commondom, bb) check
makes us not consider the sink opportunity. That was introduced as part
of the fix for PR97330.
[Bug target/105624] [13 Regression] ICE in final_scan_insn_1, at final.cc:2861 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105624 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c++/105622] [13 Regression] ICE in cxx_eval_store_expression with [[no_unique_address]] since r13-160-g967cdbe6629653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105622 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/105621] [13 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105621 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |13.0
[Bug testsuite/105620] [13 regression] g++.dg/tsan/pr88018.C fails after r13-456-geccbd7fcee5bbf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105620 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/105618] [11/12/13 Regression] Missed loop body simplification by -O3 (trunk v.s. 10.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105618 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Summary|Missed loop body|[11/12/13 Regression] |simplification by -O3 |Missed loop body |(trunk v.s. 10.3) |simplification by -O3 ||(trunk v.s. 10.3) Target Milestone|--- |11.4 Last reconfirmed||2022-05-17 Keywords||missed-optimization, ||needs-bisection Known to fail||11.3.1, 12.1.1 Ever confirmed|0 |1 Known to work||10.3.1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Confirmed. GCC 10 manages to sink the load from e out of the loop while GCC 12 fails to do that.
[Bug target/105617] [12/13 Regression] Slp is maybe too aggressive in some/many cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-05-17
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #10 from Richard Biener ---
(In reply to Hongtao.liu from comment #9)
> (In reply to Hongtao.liu from comment #8)
> > (In reply to Hongtao.liu from comment #7)
> > > Hmm, we have specific code to add scalar->vector(vmovq) cost to vector
> > > construct, but it seems not to work here, guess it's because ,and
> > > thought
> > > it was load not scalar？
> > Yes, true for as gimple_assign_load_p
> >
> >
> > (gdb) p debug_gimple_stmt (def)
> > 72# VUSE <.MEM_46>
> > 73r0.0_20 = r0;
> It's a load from stack, and finally eliminated in rtl dse1, but here the
> vectorizer doesn't know.
Yes, it's difficult for the SLP vectorizer to guess whether rN will come
from memory or not. Some friendlier middle-end representation for
add-with-carry might be nice - the x86 backend could for example fold
__builtin_ia32_addcarryx_u64 to use a _Complex unsinged long long for the
return, ferrying the carry in __imag. Alternatively we could devise
some special GIMPLE_ASM kind ferrying RTL and not assembly so the
backend could fold it directly to RTL on GIMPLE with asm constraints
doing the plumbing ... (we'd need some match-scratch and RTL expansion
would still need to allocate the actual pseudos).
[local count: 1073741824]:
_1 = *srcB_17(D);
_2 = *srcA_18(D);
_30 = __builtin_ia32_addcarryx_u64 (0, _2, _1, );
_3 = MEM[(const uint64_t *)srcB_17(D) + 8B];
_4 = MEM[(const uint64_t *)srcA_18(D) + 8B];
_5 = (int) _30;
_29 = __builtin_ia32_addcarryx_u64 (_5, _4, _3, );
_6 = MEM[(const uint64_t *)srcB_17(D) + 16B];
_7 = MEM[(const uint64_t *)srcA_18(D) + 16B];
_8 = (int) _29;
_28 = __builtin_ia32_addcarryx_u64 (_8, _7, _6, );
_9 = MEM[(const uint64_t *)srcB_17(D) + 24B];
_10 = MEM[(const uint64_t *)srcA_18(D) + 24B];
_11 = (int) _28;
__builtin_ia32_addcarryx_u64 (_11, _10, _9, );
r0.0_12 = r0;
r1.1_13 = r1;
_36 = {r0.0_12, r1.1_13};
r2.2_14 = r2;
r3.3_15 = r3;
_37 = {r2.2_14, r3.3_15};
vectp.9_35 = dst_19(D);
MEM [(uint64_t *)vectp.9_35] = _36;
vectp.9_39 = vectp.9_35 + 16;
MEM [(uint64_t *)vectp.9_39] = _37;
so for the situation at hand I don't see any reasonable way out that
doesn't have the chance of regressing things in other places (like
treat loads from non-indexed auto variables specially or so). The
only real solution is to find a GIMPLE representation for
__builtin_ia32_addcarryx_u64 that doesn't force the alternate output
to memory.
[Bug c++/105615] Partial ordering of constraints with empty parameter mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105615 --- Comment #2 from Pilar Latiesa --- (In reply to Patrick Palka from comment #1) > Constraint subsumption is specified in terms of the normal form. When the > concept C is made independent of the template parameter, the normal forms of > C and C are the same, so the constraint (C && C) no longer > strictly subsumes C, hence the second overload is no longer considered > more specialized than the first. So I believe GCC (and Clang and MSVC) are > correct to diagnose the call as ambiguous. I see. Thanks for the explanation Patrick. By the way, neither Clang nor MSVC handle the dependent case correctly.
