[Bug middle-end/105604] [10/11/12/13 Regression] ICE: in tree_to_shwi with vla in struct and sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105604 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-05-16 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Started with r10-4571-g937a86b49e4ed8ef.
[Bug preprocessor/105608] [11/12/13 Regression] ICE: in linemap_add, at libcpp/line-map.cc:502 on ovito-3.7.1 since r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 Martin Liška changed: What|Removed |Added Summary|[13 Regression] ICE: in |[11/12/13 Regression] ICE: |linemap_add, at |in linemap_add, at |libcpp/line-map.cc:502 on |libcpp/line-map.cc:502 on |ovito-3.7.1 |ovito-3.7.1 since ||r11-338-g2a0225e47868fbfc Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org Last reconfirmed||2022-05-16 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- With checking compiler, it started with r11-338-g2a0225e47868fbfc.
[Bug c++/105593] [12/13 Regression] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Keywords||diagnostic, needs-bisection
Target Milestone|--- |12.2
Status|WAITING |NEW
Target|X86_64 |x86_64-*-*
Summary|avx512 math function raises |[12/13 Regression] avx512
|uninitialized variable |math function raises
|warning |uninitialized variable
||warning
Component|target |c++
--- Comment #4 from Richard Biener ---
Confirmed. We possibly lose the Wno-uninitialized annotation/suppression of
the variable (during inlining?) somewhere.
Simpler testcase:
extern inline __attribute__((__gnu_inline__,__always_inline__))
int foo ()
{
int r = r;
return r;
}
void bar (int);
void baz()
{
int u = foo ();
bar (u);
}
fails to hide the -Wuninitialized with the C++ frontend, works correct with the
C frontend and on the GCC 11 branch.
[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||marxin at gcc dot gnu.org Summary|[13 Regression] wrong code |[13 Regression] wrong code |with unsigned V1TI |with unsigned V1TI |comparison |comparison since ||r13-458-gd75d4293dcc029 --- Comment #2 from Martin Liška --- Started with r13-458-gd75d4293dcc029.
[Bug tree-optimization/105596] Loop counter widened to 128-bit unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105596 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-05-16 Known to fail||12.1.0, 4.8.5, 7.5.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target||x86_64-*-* --- Comment #2 from Richard Biener --- Confirmed - it's IVOPTs deciding the promotion is beneficial. It costs both the original and the final IV set the same and then (likely) breaks the tie on less IVs being used. One would need to carefully look at where the cost estimates are off. With -fno-ivopts we get .L3: movl%ecx, %esi movq%rdx, %r8 addl$1, %ecx imulq %rsi, %r8 mulq%rsi addq%r8, %rdx cmpl%edi, %ecx jb .L3
[Bug preprocessor/105608] [11/12/13 Regression] ICE: in linemap_add, at libcpp/line-map.cc:502 on ovito-3.7.1 since r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.4
[Bug middle-end/105604] [10/11/12/13 Regression] ICE: in tree_to_shwi with vla in struct and sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105604 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- Not only that.
[Bug preprocessor/105608] [11/12/13 Regression] ICE: in linemap_add, at libcpp/line-map.cc:502 on ovito-3.7.1 since r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[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 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[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|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- We want to use andv4si3 only for EQ, for NE we want to use iorv4si3 instead, for both expanders.
[Bug c++/105610] warn about cv qualifiers ignored for a base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105610 --- Comment #1 from Jonathan Wakely --- I don't see any benefit to this warning. What harm does the example code do? Has anybody ever been confused about the semantics, and expected the cv-qualifiers to have an effect? If this language feature doesn't lead to confusion or mistaken code, why should there be a warning?
[Bug c++/104652] It's impossible to declare non-first target function as a friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104652
--- Comment #2 from Vorfeed Canal ---
Thanks for showing a workaround:
class Foo {
public:
explicit Foo(int f) : x(f) {}
[[gnu::target("default")]] friend inline Foo bar(Foo& foo) {
return Foo(foo.x);
}
[[gnu::target("sse4.2")]] friend inline Foo bar(Foo& foo) {
return Foo(foo.x * 2);
}
private:
int x;
};
It works perfectly with Clang, ICC and GCC 11, but GCC 12 breaks it:
https://godbolt.org/z/fxb5ecea8
Is it possible to unbreak it? Because now it's a regression.
[Bug c++/105491] [10/11/12 Regression] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491 Martin Liška changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] Usage |Usage of __constinit with |of __constinit with |-std=c++11 does is rejected |-std=c++11 does is rejected Known to work||13.0 --- Comment #9 from Martin Liška --- Fixed on master.
[Bug tree-optimization/105598] [11 Regression] Flag -O2 causes code to misbehave
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105598 --- Comment #2 from Richard Biener --- r12-3918-g5b8b1522e04adc20980f396571be1929a32d148a is an optimization improvement. When backporting the change the failure goes away but it re-appears with -fdisable-tree-fre1 and can be mitigated with -fno-ipa-cp. -fdisable-tree-fre1 doesn't re-introduce the issue on trunk. Can you bisect what fixed this with -fdisable-tree-fre1?
[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 #4 from Jakub Jelinek --- Created attachment 52983 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52983&action=edit gcc13-pr105613.patch Untested fix.
[Bug sanitizer/105614] New: mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614 Bug ID: 105614 Summary: mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: judge.packham at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Building for mips64-unknown-linux-gnu with libsanitizer enabled the following static_assert is triggered. [ALL ]In file included from /home/ctng/crosstool-ng/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:21: [ERROR] /home/ctng/crosstool-ng/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed [ALL ] 75 | COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct stat)); [ALL ] |~~^~ [ALL ] /home/ctng/crosstool-ng/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:332:44: note: in definition of macro 'COMPILER_CHECK' [ALL ] 332 | #define COMPILER_CHECK(pred) static_assert(pred, "") [ALL ] |^~~~ [ERROR]make[5]: *** [Makefile:615: sanitizer_platform_limits_linux.lo] Error 1 [ERROR]make[5]: *** Waiting for unfinished jobs Looking at the libsanitizer code I see #elif defined(__mips__) const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID ? FIRST_32_SECOND_64(104, 128) : FIRST_32_SECOND_64(144, 216); const unsigned struct_kernel_stat64_sz = 104; But from the Linux kernel's arch/mips/include/uapi/asm/stat.h I make the size of struct stat 104 for the _MIPS_SIM_ABI64 case. The 144 seems to line up with the _MIPS_SIM_NABI32/_MIPS_SIM_ABI32 case. Where did libsanitizer get 216 from?
[Bug tree-optimization/105598] [11 Regression] Flag -O2 causes code to misbehave
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105598 --- Comment #3 from Jakub Jelinek --- With -O2 -fdisable-tree-fre1 it started with the same revision, but went away with r12-5104-gb406bb901f7e98f7c6d66a240c2eb64b7cd7e615 instead.
[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 #5 from Roger Sayle --- Firstly sorry for the inconvenience. Yep, Jakub's analysis is correct we/I need iorv4si for NE. My thinko, X==Y is X.h==Y.h && X.l==Y.l, but X!=Y is X.h!=Y.h || X.l!=Y.l, sorry. Many thanks to Jakub for assigning this to himself so quickly.
[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 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-16 --- Comment #1 from Martin Liška --- > > Where did libsanitizer get 216 from? It's in the upstream since the beginning: https://reviews.llvm.org/D4208 Please create an upstream bug for it.
[Bug tree-optimization/105598] [11 Regression] Flag -O2 causes code to misbehave
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105598 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- I'm going to backport this rev.
[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 --- Comment #2 from Chris Packham --- Created attachment 52984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52984&action=edit Set struct_kernel_stat_sz
[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 --- Comment #3 from Chris Packham --- It looks like upstream has moved to FIRST_32_SECOND_64(160, 216) somewhere along the line. According to my reading of the linux source code this is wrong for both bitnesses now.
[Bug c++/105615] New: Partial ordering of constraints with empty parameter mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105615
Bug ID: 105615
Summary: Partial ordering of constraints with empty parameter
mapping
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pilarlatiesa at gmail dot com
Target Milestone: ---
The following testcase is accepted by GCC 10 and newer versions:
```
template
constexpr bool b = true;
template
concept C = b;
template
class foo
{
public:
void bar() const requires C {}
void bar() const requires (C && C) {}
};
int main()
{
foo x;
x.bar();
return 0;
}
```
However, if we make the concept independent of the template parameter, it fails
to compile:
```
template
concept C = true;
template
class foo
{
public:
void bar() const requires C {}
void bar() const requires (C && C) {}
};
int main()
{
foo x;
x.bar();
return 0;
}
```
[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 --- Comment #4 from Martin Liška --- Please make the review request to upstream first: https://reviews.llvm.org/
[Bug c++/105610] warn about cv qualifiers ignored for a base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105610 --- Comment #2 from fsb4000 at yandex dot ru --- >Has anybody ever been confused about the semantics, and expected the >cv-qualifiers to have an effect? Yes. I saw a question on one forum why constness is not taken into account when inheriting and whether there is a compiler bug.
[Bug tree-optimization/105598] [11 Regression] Flag -O2 causes code to misbehave
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105598 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to fail||11.3.0 Known to work||11.3.1, 12.1.0 Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug rtl-optimization/105577] [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 --- Comment #13 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ef7b8976b9143aa78dd9cf5cfdaa02552d6e18a0 commit r13-506-gef7b8976b9143aa78dd9cf5cfdaa02552d6e18a0 Author: Richard Biener Date: Mon May 16 12:07:31 2022 +0200 rtl-optimization/105577 - testcase for the PR 2022-05-16 Richard Biener PR rtl-optimization/105577 * g++.dg/torture/pr105577.C: New testcase.
[Bug c++/2022] Internal compiler error when c function has same name as mangled C++ name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2022 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ef7b8976b9143aa78dd9cf5cfdaa02552d6e18a0 commit r13-506-gef7b8976b9143aa78dd9cf5cfdaa02552d6e18a0 Author: Richard Biener Date: Mon May 16 12:07:31 2022 +0200 rtl-optimization/105577 - testcase for the PR 2022-05-16 Richard Biener PR rtl-optimization/105577 * g++.dg/torture/pr105577.C: New testcase.
[Bug libstdc++/105616] New: Using regex_replace throws "maybe-uninitialized" warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105616
Bug ID: 105616
Summary: Using regex_replace throws "maybe-uninitialized"
warnings
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: christian.morales.vega at gmail dot com
Target Milestone: ---
As can be seen in https://godbolt.org/z/qK976bqzf
Building
#include
#include
#include
#include
int main()
{
std::string text = "Quick brown fox";
std::regex vowel_re("a|e|i|o|u");
// write the results to an output iterator
std::regex_replace(std::ostreambuf_iterator(std::cout),
text.begin(), text.end(), vowel_re, "*");
// construct a string holding the results
std::cout << '\n' << std::regex_replace(text, vowel_re, "[$&]") << '\n';
}
(taken from https://en.cppreference.com/w/cpp/regex/regex_replace)
with "-fsanitize=address -O1 -Wmaybe-uninitialized" creates a long list of
warnings
In file included from
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/regex:48,
from :3:
In constructor 'std::function<_Res(_ArgTypes
...)>::function(std::function<_Res(_ArgTypes ...)>&&) [with _Res = bool;
_ArgTypes = {char}]',
inlined from
'std::__detail::_State<_Char_type>::_State(std::__detail::_State<_Char_type>&&)
[with _Char_type = char]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:149:4,
inlined from 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:290:24:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:405:42:
warning: '*(std::function*)((char*)&__tmp +
offsetof(std::__detail::_StateT,
std::__detail::_State::.std::__detail::_State_base::)).std::function::_M_invoker'
may be used uninitialized [-Wmaybe-uninitialized]
405 | : _Function_base(), _M_invoker(__x._M_invoker)
| ^~
In file included from
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/regex:63:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h: In
member function 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits]':
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:287:17:
note: '__tmp' declared here
287 | _StateT __tmp(_S_opcode_subexpr_end);
| ^
In member function 'bool std::_Function_base::_M_empty() const',
inlined from 'std::function<_Res(_ArgTypes ...)>::operator bool() const
[with _Res = bool; _ArgTypes = {char}]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:574:25,
inlined from 'std::function<_Res(_ArgTypes
...)>::function(std::function<_Res(_ArgTypes ...)>&&) [with _Res = bool;
_ArgTypes = {char}]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:407:6,
inlined from
'std::__detail::_State<_Char_type>::_State(std::__detail::_State<_Char_type>&&)
[with _Char_type = char]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:149:4,
inlined from 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:290:24:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:247:37:
warning: '*(const std::_Function_base*)((char*)&__tmp +
offsetof(std::__detail::_StateT,
std::__detail::_State::.std::__detail::_State_base::)).std::_Function_base::_M_manager'
may be used uninitialized [-Wmaybe-uninitialized]
247 | bool _M_empty() const { return !_M_manager; }
| ^~
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h: In
member function 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits]':
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:287:17:
note: '__tmp' declared here
287 | _StateT __tmp(_S_opcode_subexpr_end);
| ^
In constructor 'std::function<_Res(_ArgTypes
...)>::function(std::function<_Res(_ArgTypes ...)>&&) [with _Res = bool;
_ArgTypes = {char}]',
inlined from
'std::__detail::_State<_Char_type>::_State(std::__detail::_State<_Char_type>&&)
[with _Char_type = char]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:149:4,
inlined from 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_begi
[Bug libstdc++/105616] Using regex_replace throws "maybe-uninitialized" warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105616 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Dup of PR105562 ?
[Bug target/105617] New: Regression in code generation for _addcarry_u64()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
Bug ID: 105617
Summary: Regression in code generation for _addcarry_u64()
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: already5chosen at yahoo dot com
Target Milestone: ---
It took many years until gcc caught up with MSVC and LLVM/clang in generation
of code for chains of Intel's _addcarry_u64() intrinsic calls. But your
finally managed to do it in gcc11.
Unfortunately, the luck didn't last for long.
void add4i(uint64_t dst[4], const uint64_t srcA[4], const uint64_t srcB[4])
{
unsigned char c;
unsigned long long r0; c = _addcarry_u64(0, srcA[0], srcB[0], &r0);
unsigned long long r1; c = _addcarry_u64(c, srcA[1], srcB[1], &r1);
unsigned long long r2; c = _addcarry_u64(c, srcA[2], srcB[2], &r2);
unsigned long long r3; c = _addcarry_u64(c, srcA[3], srcB[3], &r3);
dst[0] = r0;
dst[1] = r1;
dst[2] = r2;
dst[3] = r3;
}
gcc 11.1 -O2
add4i:
movq(%rdx), %rax
addq(%rsi), %rax
movq8(%rsi), %rcx
movq%rax, %r8
adcq8(%rdx), %rcx
movq16(%rsi), %rax
adcq16(%rdx), %rax
movq24(%rdx), %rdx
adcq24(%rsi), %rdx
movq%r8, (%rdi)
movq%rcx, 8(%rdi)
movq%rax, 16(%rdi)
movq%rdx, 24(%rdi)
ret
gcc 12.1 -O2
add4i:
movq(%rdx), %rax
movq8(%rsi), %rcx
addq(%rsi), %rax
movq16(%rsi), %r8
adcq8(%rdx), %rcx
adcq16(%rdx), %r8
movq%rax, %xmm1
movq24(%rdx), %rdx
adcq24(%rsi), %rdx
movq%r8, %xmm0
movq%rcx, %xmm3
movq%rdx, %xmm2
punpcklqdq %xmm3, %xmm1
punpcklqdq %xmm2, %xmm0
movups %xmm1, (%rdi)
movups %xmm0, 16(%rdi)
ret
What ... ?!
BTW, gcc 12.1 -O1 is still o.k.
[Bug target/105617] [12/13 regressi] Slp is maybe too aggressive in some/many cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617 Andrew Pinski changed: What|Removed |Added Summary|Regression in code |[12/13 regressi] Slp is |generation for |maybe too aggressive in |_addcarry_u64() |some/many cases Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- This is just the vectorizer still being too aggressive right before a return. It is a cost model issue and it might not really be an issue in the final code just microbenchmarks.
[Bug target/105617] [12/13 regressi] Slp is maybe too aggressive in some/many cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.2 --- Comment #2 from Andrew Pinski --- My bet llvm has a similar issue sometimes too.
[Bug target/105617] [12/13 regressi] Slp is maybe too aggressive in some/many cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617 --- Comment #3 from Richard Biener --- We are vectorizing the store it dst[] now at -O2 since that appears profitable: t.c:10:10: note: Cost model analysis: r0.0_12 1 times scalar_store costs 12 in body r1.1_13 1 times scalar_store costs 12 in body r2.2_14 1 times scalar_store costs 12 in body r3.3_15 1 times scalar_store costs 12 in body r0.0_12 2 times unaligned_store (misalign -1) costs 24 in body node 0x4b2b1e0 1 times vec_construct costs 4 in prologue node 0x4b2b1e0 1 times vec_construct costs 4 in prologue t.c:10:10: note: Cost model analysis for part in loop 0: Vector cost: 32 Scalar cost: 48 t.c:10:10: note: Basic block will be vectorized using SLP
[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 #4 from Michael_S --- (In reply to Andrew Pinski from comment #1) > This is just the vectorizer still being too aggressive right before a return. > It is a cost model issue and it might not really be an issue in the final > code just microbenchmarks. BTW, Andrew, in one of the older related threads you made a very wise comment: "Maybe even generic builtins/internal functions for this case even as clang has __builtin_addc, etc." IMHO, that is not only necessary, but long overdue.
[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 #5 from Michael_S --- (In reply to Richard Biener from comment #3) > We are vectorizing the store it dst[] now at -O2 since that appears > profitable: > > t.c:10:10: note: Cost model analysis: > r0.0_12 1 times scalar_store costs 12 in body > r1.1_13 1 times scalar_store costs 12 in body > r2.2_14 1 times scalar_store costs 12 in body > r3.3_15 1 times scalar_store costs 12 in body > r0.0_12 2 times unaligned_store (misalign -1) costs 24 in body > node 0x4b2b1e0 1 times vec_construct costs 4 in prologue > node 0x4b2b1e0 1 times vec_construct costs 4 in prologue > t.c:10:10: note: Cost model analysis for part in loop 0: > Vector cost: 32 > Scalar cost: 48 > t.c:10:10: note: Basic block will be vectorized using SLP That makes no sense. 4 scalar-to-vector moves + 2 vector shuffles + 2 vector stores are ALOT more costly than 4 scalar stores. Even more so considering that scalar store go to adjacent addresses so, on good CPUs, they are likely combined at the level of store queue, so a cache subsystem sees fewer operations. Either your cost model is broken or there are bugs in summation. I'd guess, somehow compiler thinks that moves have zero cost. But scalar-to-vector moves are certainly not of zero cost. Even scalar-to-scalar or vector-to-vector moves that are hoisted at renamer does not have a zero cost, because quite often renamer itself constitutes the narrowest performance bottleneck. But those moves... I don't think that they are hoisted by renamer. Also, it's likely that compiler thinks that scalar store costs the same as vector store. That's also generally incorrect, esp. when you don't know your target CPU and don't know whether stores are aligned or not, like in this case.
[Bug tree-optimization/105618] New: Missed loop body simplification by -O3 (trunk v.s. 10.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105618
Bug ID: 105618
Summary: Missed loop body simplification by -O3 (trunk v.s.
10.3)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
For the following code, gcc truck -O3 fails to optimize away the loop body,
while gcc10.3 can. You can see from the assembly code that gcc10.3 figured out
that the variable c would be a constant after the loop while gcc-trunk didn't.
$cat a.c
static int b=4;
int c;
int main() {
int e[5] = {1,1,1,1,1};
for (; b >= 0; b--) {
c = e[b];
}
return 0;
}
$
$gcc-trunk -O3 -S -o trunk.s a.c
$gcc-10-3 -O3 -S -o 10-3.s a.c
$wc trunk.s 10-3.s
66 147 1005 trunk.s
52 106 698 10-3.s
118 253 1703 total
$
$cat 10-3.s
main:
.LFB0:
.cfi_startproc
endbr64
movlb(%rip), %eax
testl %eax, %eax
js .L2
movl$1, c(%rip)
movl$-1, b(%rip)
.L2:
xorl%eax, %eax
ret
$
$cat trunk.s
main:
.LFB0:
.cfi_startproc
movdqa .LC0(%rip), %xmm0
movlb(%rip), %eax
movl$1, -24(%rsp)
movaps %xmm0, -40(%rsp)
testl %eax, %eax
js .L2
movslq %eax, %rdx
leal-1(%rax), %ecx
movl-40(%rsp,%rdx,4), %edx
je .L3
leal-2(%rax), %edx
cmpl$1, %eax
je .L10
leal-3(%rax), %ecx
cmpl$2, %eax
je .L6
leal-4(%rax), %edx
cmpl$3, %eax
je .L10
.L6:
movslq %edx, %rdx
movl-40(%rsp,%rdx,4), %edx
.L3:
movl%edx, c(%rip)
movl$-1, b(%rip)
.L2:
xorl%eax, %eax
ret
.L10:
movslq %ecx, %rcx
movl-40(%rsp,%rcx,4), %edx
jmp .L3
$
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Sebastian Pop : https://gcc.gnu.org/g:407adcb310df7c85387a02f9b0d5f1df770258e9 commit r9-10184-g407adcb310df7c85387a02f9b0d5f1df770258e9 Author: Sebastian Pop Date: Mon Apr 18 15:13:20 2022 + [AArch64] add barriers to ool __sync builtins 2022-05-13 Sebastian Pop gcc/ PR target/105162 * config/aarch64/aarch64-protos.h (atomic_ool_names): Increase dimension of str array. * config/aarch64/aarch64.c (aarch64_atomic_ool_func): Call memmodel_from_int and handle MEMMODEL_SYNC_*. (DEF0): Add __aarch64_*_sync functions. gcc/testsuite/ PR target/105162 * gcc.target/aarch64/sync-comp-swap-ool.c: New. * gcc.target/aarch64/sync-op-acquire-ool.c: New. * gcc.target/aarch64/sync-op-full-ool.c: New. * gcc.target/aarch64/target_attr_20.c: Update check. * gcc.target/aarch64/target_attr_21.c: Same. libgcc/ PR target/105162 * config/aarch64/lse.S: Define BARRIER and handle memory MODEL 5. * config/aarch64/t-lse: Add a 5th memory model for _sync functions.
[Bug tree-optimization/105618] Missed loop body simplification by -O3 (trunk v.s. 10.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105618 --- Comment #1 from Andrew Pinski --- If b was not static and this was not main, there could be undefined behavior. Gcc does not take into account the function being main though.
[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 #6 from Michael_S --- (In reply to Michael_S from comment #5) > > Even scalar-to-scalar or vector-to-vector moves that are hoisted at renamer > does not have a zero cost, because quite often renamer itself constitutes > the narrowest performance bottleneck. But those moves... I don't think that > they are hoisted by renamer. I took a look at several Intel and AMD Optimization Reference Manuals and instruction tables. None of existing x86 microarchitectures, either old or new, eliminates scalar-to-SIMD moves at renamer. Which is sort of obvious for new microarchitectures (Bulldozer or later for AMD, Sandy Bridge or later for Intel), because on these microarchitectures scalar and SIMD registers live in separate physical register files. As to older microarchitectures, they, may be, had them in the common physical storage area, but they simply were not sufficiently smart to eliminate the moves. So, these moves have non-zero latency. On some of the cores, including some of the newest, the latency is even higher than one clock. And the throughput tends to be rather low, most typically, one scalar-to-SIMD move per clock. For comparison, scalar-to-scalar and SIMD-to-SIMD moves can be executed (or eliminated at renamer) at rates of 2, 3 or even 4 per clock.
[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Rolf Eike Beer changed:
What|Removed |Added
CC||e...@sf-mail.de
--- Comment #23 from Rolf Eike Beer ---
Using gcc12 from 4943b75e9f06f0b64ed541430bb7fbccf55fc552.
$ cat rea.c
#include
char *
compact_buffer(char *inbuf, size_t oldlen, size_t k)
{
char *foo;
#ifdef WARN
char **buf = &foo;
#endif
foo = realloc(inbuf, k);
if (foo == NULL) {
#if defined(WARN) && defined(WARN2)
foo = inbuf;
return inbuf;
#else
return inbuf;
#endif
}
return foo;
}
$ gcc-12.0.1 -c -Wuse-after-free=3 -Irepos/Qsmtp/include rea.c
$ gcc-12.0.1 -c -DWARN -Wuse-after-free=2 -Irepos/Qsmtp/include rea.c
rea.c: In function 'compact_buffer':
rea.c:17:24: warning: pointer 'inbuf' may be used after 'realloc'
[-Wuse-after-free]
17 | return inbuf;
|^
rea.c:11:15: note: call to 'realloc' here
11 | foo = realloc(inbuf, k);
| ^
$ gcc-12.0.1 -c -DWARN -DWARN2 -Wuse-after-free=2 -Irepos/Qsmtp/include rea.c
rea.c: In function 'compact_buffer':
rea.c:15:24: warning: pointer 'inbuf' may be used after 'realloc'
[-Wuse-after-free]
15 | return inbuf;
|^
rea.c:11:15: note: call to 'realloc' here
11 | foo = realloc(inbuf, k);
| ^
rea.c:14:21: warning: pointer 'inbuf' may be used after 'realloc'
[-Wuse-after-free]
14 | foo = inbuf;
| ^~~
rea.c:11:15: note: call to 'realloc' here
11 | foo = realloc(inbuf, k);
| ^
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 Piotr Kubaj changed: What|Removed |Added CC||pkubaj at anongoth dot pl --- Comment #16 from Piotr Kubaj --- This issue has been fixed in FreeBSD's main branch on powerpc* in https://cgit.freebsd.org/src/commit/?id=448c505c33cc334193590f3844406d6a74f26e2a Similar fix could be done for other affected architectures.
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Sebastian Pop : https://gcc.gnu.org/g:90a0a5315375fd53baf677e60f0fc996fe2d70b2 commit r10-10745-g90a0a5315375fd53baf677e60f0fc996fe2d70b2 Author: Sebastian Pop Date: Mon Apr 18 15:13:20 2022 + add barriers to ool __sync builtins 2022-05-13 Sebastian Pop gcc/ PR target/105162 * config/aarch64/aarch64-protos.h (atomic_ool_names): Increase dimension of str array. * config/aarch64/aarch64.c (aarch64_atomic_ool_func): Call memmodel_from_int and handle MEMMODEL_SYNC_*. (DEF0): Add __aarch64_*_sync functions. gcc/testsuite/ PR target/105162 * gcc.target/aarch64/sync-comp-swap-ool.c: New. * gcc.target/aarch64/sync-op-acquire-ool.c: New. * gcc.target/aarch64/sync-op-full-ool.c: New. * gcc.target/aarch64/target_attr_20.c: Update check. * gcc.target/aarch64/target_attr_21.c: Same. libgcc/ PR target/105162 * config/aarch64/lse.S: Define BARRIER and handle memory MODEL 5. * config/aarch64/t-lse: Add a 5th memory model for _sync functions.
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Sebastian Pop : https://gcc.gnu.org/g:9ef808fb4373c8d8479539cb19ae00b1bcec87ea commit r11-10005-g9ef808fb4373c8d8479539cb19ae00b1bcec87ea Author: Sebastian Pop Date: Mon Apr 18 15:13:20 2022 + [AArch64] add barriers to ool __sync builtins 2022-05-13 Sebastian Pop gcc/ PR target/105162 * config/aarch64/aarch64-protos.h (atomic_ool_names): Increase dimension of str array. * config/aarch64/aarch64.c (aarch64_atomic_ool_func): Call memmodel_from_int and handle MEMMODEL_SYNC_*. (DEF0): Add __aarch64_*_sync functions. gcc/testsuite/ PR target/105162 * gcc.target/aarch64/sync-comp-swap-ool.c: New. * gcc.target/aarch64/sync-op-acquire-ool.c: New. * gcc.target/aarch64/sync-op-full-ool.c: New. * gcc.target/aarch64/target_attr_20.c: Update check. * gcc.target/aarch64/target_attr_21.c: Same. libgcc/ PR target/105162 * config/aarch64/lse.S: Define BARRIER and handle memory MODEL 5. * config/aarch64/t-lse: Add a 5th memory model for _sync functions.
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Sebastian Pop : https://gcc.gnu.org/g:5251647c84489af05baa38e4dd103cf359f77b75 commit r12-8389-g5251647c84489af05baa38e4dd103cf359f77b75 Author: Sebastian Pop Date: Mon Apr 18 15:13:20 2022 + [AArch64] add barriers to ool __sync builtins 2022-05-13 Sebastian Pop gcc/ PR target/105162 * config/aarch64/aarch64-protos.h (atomic_ool_names): Increase dimension of str array. * config/aarch64/aarch64.cc (aarch64_atomic_ool_func): Call memmodel_from_int and handle MEMMODEL_SYNC_*. (DEF0): Add __aarch64_*_sync functions. gcc/testsuite/ PR target/105162 * gcc.target/aarch64/sync-comp-swap-ool.c: New. * gcc.target/aarch64/sync-op-acquire-ool.c: New. * gcc.target/aarch64/sync-op-full-ool.c: New. * gcc.target/aarch64/target_attr_20.c: Update check. * gcc.target/aarch64/target_attr_21.c: Same. libgcc/ PR target/105162 * config/aarch64/lse.S: Define BARRIER and handle memory MODEL 5. * config/aarch64/t-lse: Add a 5th memory model for _sync functions.
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 Sebastian Pop changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #14 from Sebastian Pop --- Fixed.
[Bug c++/105619] New: Wrong "used in its own initializer" with class prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105619
Bug ID: 105619
Summary: Wrong "used in its own initializer" with class prvalue
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
struct A {
const A *p = this;
};
constexpr A
bar (A)
{
return {};
}
constexpr A a = bar (A{});
constexpr auto *p = a.p; // #1
#1 is rejected with 'a' used in its own initializer:
$ ./cc1plus -quiet bug.C
bug.C:12:21: error: the value of ‘a’ is not usable in a constant expression
12 | constexpr auto *p = a.p; // #1
| ^
bug.C:11:13: note: ‘a’ used in its own initializer
11 | constexpr A a = bar (A{});
| ^
but 'a' is not actually used in the initializer?
[Bug c++/105553] [11/12/13 Regression] [DR1640] Deduction when attempting to create an array with an element type that is an abstract class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105553 Jason Merrill changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12/13 Regression] |Deduction when attempting |[DR1640] Deduction when |to create an array with an |attempting to create an |element type that is an |array with an element type |abstract class |that is an abstract class Resolution|--- |INVALID CC||jason at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jason Merrill --- That wording was removed by wg21.link/p0929r2 to address wg21.link/cwg1640 , which is about this exact pattern.
[Bug c++/105553] [11/12/13 Regression] [DR1640] Deduction when attempting to create an array with an element type that is an abstract class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105553 --- Comment #2 from Jason Merrill --- I implemented P0929R2 in r11-5036.
[Bug c++/105619] Wrong "used in its own initializer" with class prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105619 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-05-16 --- Comment #1 from Jason Merrill --- That does look like it ought to work.
[Bug testsuite/105620] New: [13 regression] g++.dg/tsan/pr88018.C fails after r13-456-geccbd7fcee5bbf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105620 Bug ID: 105620 Summary: [13 regression] g++.dg/tsan/pr88018.C fails after r13-456-geccbd7fcee5bbf Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:eccbd7fcee5bbfc47731e8de83c44eee2e3dcc4b, r13-456-geccbd7fcee5bbf make -k check-gcc RUNTESTFLAGS="tsan.exp=g++.dg/tsan/pr88018.C" FAIL: g++.dg/tsan/pr88018.C -O0 (test for excess errors) # of unexpected failures1 # of unsupported tests 1 commit eccbd7fcee5bbfc47731e8de83c44eee2e3dcc4b (HEAD, refs/bisect/bad) Author: Paul A. Clarke Date: Mon Feb 21 12:14:01 2022 -0600 rs6000: Move g++.dg powerpc PR tests to g++.target This test was previously passing in r13-455-g1fe04c497d5a16. I am not sure what in r13-456-geccbd7fcee5bbf changed as this test is not mentioned.
[Bug tree-optimization/105621] New: [13 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105621
Bug ID: 105621
Summary: [13 Regression] Wrong code with -O3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskiy at gmail dot com
Target Milestone: ---
Link to the Compiler Explorer: https://godbolt.org/z/jscK4bTP6
Reproducer:
#include
unsigned short a = (unsigned short)31272;
int b = -1902905271;
unsigned int c = 1618489477U;
bool d = (bool)0;
void test(unsigned short a, int b, unsigned c) __attribute__((noipa));
void test(unsigned short a, int b, unsigned c) {
for (int i = 2; i < 24; i += 3)
d = b ? a ? c : 208660901731118 : 0;
}
int main() {
test(a, b, c);
printf("%d\n", (int)d);
if (d != 1)
__builtin_abort();
}
Error:
>$ g++ -O2 driver.cpp && ./a.out
1
>$ g++ -O3 driver.cpp && ./a.out
0
Aborted (core dumped)
GCC version 13.0.0 20220516 (69c4b5c519f0df37e4903992644cc29682721bc1)
[Bug c++/105622] New: ICE in cxx_eval_store_expression with [[no_unique_address]] and empty data members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105622
Bug ID: 105622
Summary: ICE in cxx_eval_store_expression with
[[no_unique_address]] and empty data members
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
struct empty {
empty() = default;
constexpr empty(int) { }
};
struct container {
empty __begin_ = {};
[[no_unique_address]] empty __size_ = 0;
};
constexpr bool test() {
container s;
return true;
}
static_assert(test());
testcase.ii: In function ‘constexpr bool test()’:
testcase.ii:12:13: in ‘constexpr’ expansion of ‘s.container::container()’
testcase.ii:12:13: internal compiler error: in cxx_eval_store_expression, at
cp/constexpr.cc:5927
12 | container s;
| ^
0x6a0ca0 cxx_eval_store_expression
/home/patrick/gcc/gcc/cp/constexpr.cc:5927
0x96c254 cxx_eval_constant_expression
/home/patrick/gcc/gcc/cp/constexpr.cc:6847
0x96c4d6 cxx_eval_constant_expression
/home/patrick/gcc/gcc/cp/constexpr.cc:7236
0x96c717 cxx_eval_constant_expression
/home/patrick/gcc/gcc/cp/constexpr.cc:7048
[Bug c++/105622] [13 Regression] ICE in cxx_eval_store_expression with [[no_unique_address]] and empty data members since r13-160-g967cdbe6629653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105622 Patrick Palka changed: What|Removed |Added Known to fail||13.0 CC||jason at gcc dot gnu.org Known to work||12.1.0 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Ever confirmed|0 |1 Summary|ICE in |[13 Regression] ICE in |cxx_eval_store_expression |cxx_eval_store_expression |with [[no_unique_address]] |with [[no_unique_address]] |and empty data members |and empty data members ||since ||r13-160-g967cdbe6629653 Target Milestone|--- |13.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105245 Last reconfirmed||2022-05-16 --- Comment #1 from Patrick Palka --- Started with r13-160-g967cdbe6629653.
[Bug fortran/104849] ICE in find_array_section, at fortran/expr.cc:1616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104849 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:50c73234630d51e7d66986710afd1af23851002b commit r11-10006-g50c73234630d51e7d66986710afd1af23851002b Author: Harald Anlauf Date: Wed Mar 9 21:58:26 2022 +0100 Fortran: improve error recovery on invalid array section gcc/fortran/ChangeLog: PR fortran/104849 * expr.c (find_array_section): Avoid NULL pointer dereference on invalid array section. gcc/testsuite/ChangeLog: PR fortran/104849 * gfortran.dg/pr104849.f90: New test. (cherry picked from commit 22015e77d3e45306077396b9de8a8a28bb67fb20)
[Bug fortran/105230] [9/10/11/12/13 Regression] ICE in find_array_section, at fortran/expr.cc:1634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105230 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:34c60e5e776d29ae6eb9e2e94af1c67666ec1caa commit r11-10007-g34c60e5e776d29ae6eb9e2e94af1c67666ec1caa Author: Harald Anlauf Date: Tue May 10 23:41:57 2022 +0200 Fortran: fix error recovery on invalid array section gcc/fortran/ChangeLog: PR fortran/105230 * expr.c (find_array_section): Correct logic to avoid NULL pointer dereference on invalid array section. gcc/testsuite/ChangeLog: PR fortran/105230 * gfortran.dg/pr105230.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit 0acdbe29f66017fc5cca40dcbd72a0dd41491d07)
[Bug analyzer/105103] RFE: detect bogus use of varargs in analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105103
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:2402dc6b982c4dacac2360830f0edc123c588110
commit r13-514-g2402dc6b982c4dacac2360830f0edc123c588110
Author: David Malcolm
Date: Mon May 16 15:32:11 2022 -0400
analyzer: implement four new warnings for misuses [PR105103]
This patch adds support to the analyzer for checking usage of ,
with four new warnings.
It adds:
(a) a state-machine for tracking "started" and "ended" states on va_list
instances, implementing two new warnings:
-Wanalyzer-va-list-leak
for complaining about missing va_end after a va_start or va_copy
-Wanalyzer-va-list-use-after-va-end:
for complaining about va_arg or va_copy used on a va_list that's had
va_end called on it
(b) interprocedural tracking of variadic parameters, tracking symbolic
values, implementing two new warnings:
-Wanalyzer-va-arg-type-mismatch
for type-checking va_arg usage against the types of the parameters
that were actually passed to the variadic call
-Wanalyzer-va-list-exhausted
for complaining if va_arg is used too many times on a va_list
Here's an LTO example of a type mismatch in a variadic call that
straddles two source files:
stdarg-lto-1-a.c: In function 'called_by_test_type_mismatch_1':
stdarg-lto-1-a.c:19:7: warning: 'va_arg' expected 'const char *' but
received 'int' for variadic argument 1 of 'ap'
[-Wanalyzer-va-arg-type-mismatch]
19 | str = va_arg (ap, const char *);
| ^
'test_type_mismatch_1': events 1-2
|
|stdarg-lto-1-b.c:3:6:
|3 | void test_type_mismatch_1 (void)
| | ^
| | |
| | (1) entry to 'test_type_mismatch_1'
|4 | {
|5 | called_by_test_type_mismatch_1 (42, 1066);
| | ~
| | |
| | (2) calling 'called_by_test_type_mismatch_1' from
'test_type_mismatch_1' with 1 variadic argument
|
+--> 'called_by_test_type_mismatch_1': events 3-4
|
|stdarg-lto-1-a.c:12:1:
| 12 | called_by_test_type_mismatch_1 (int placeholder, ...)
| | ^
| | |
| | (3) entry to 'called_by_test_type_mismatch_1'
|..
| 19 | str = va_arg (ap, const char *);
| | ~
| | |
| | (4) 'va_arg' expected 'const char *' but received
'int' for variadic argument 1 of 'ap'
|
gcc/ChangeLog:
PR analyzer/105103
* Makefile.in (ANALYZER_OBJS): Add analyzer/varargs.o.
* doc/invoke.texi: Add -Wanalyzer-va-arg-type-mismatch,
-Wanalyzer-va-list-exhausted, -Wanalyzer-va-list-leak, and
-Wanalyzer-va-list-use-after-va-end.
gcc/analyzer/ChangeLog:
PR analyzer/105103
* analyzer.cc (make_label_text_n): New.
* analyzer.h (class var_arg_region): New forward decl.
(make_label_text_n): New decl.
* analyzer.opt (Wanalyzer-va-arg-type-mismatch): New option.
(Wanalyzer-va-list-exhausted): New option.
(Wanalyzer-va-list-leak): New option.
(Wanalyzer-va-list-use-after-va-end): New option.
* checker-path.cc (call_event::get_desc): Split out decl access
into..
(call_event::get_caller_fndecl): ...this new function and...
(call_event::get_callee_fndecl): ...this new function.
* checker-path.h (call_event::get_desc): Drop "FINAL".
(call_event::get_caller_fndecl): New decl.
(call_event::get_callee_fndecl): New decl.
(class call_event): Make fields protected.
* diagnostic-manager.cc (null_assignment_sm_context::warn): New
overload.
(null_assignment_sm_context::get_new_program_state): New.
(diagnostic_manager::add_events_for_superedge): Move case
SUPEREDGE_CALL to a new pending_diagnostic::add_call_event vfunc.
* engine.cc (impl_sm_context::warn): Implement new override.
(impl_sm_context::get_new_program_state): New.
* pending-diagnostic.cc: Include "analyzer/diagnostic-manager.h",
"cpplib.h", "digraph.h", "ordered-hash-map.h", "cfg.h",
"basic-block.h", "gimple.h", "gimple-iterator.h", "cgraph.h"
"analyzer/supergraph.h", "analyzer/program-state.h",
"alloc-pool.h", "fibonacci_heap.h", "shortest-paths.h",
"sbitmap.h", "analyzer/exploded-graph.h", "diagnostic-path.h",
and "analyzer/checker-path.h".
(ht_ident_eq): New.
(fixup_location_in_macro_p): New.
(
[Bug fortran/105138] [7,8,9,10,F95] Bogus error when function name does not shadow an intrinsic when RESULT clause is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138 --- Comment #16 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d31975be113562448520f4c94fc75b9cbb09715e commit r10-10746-gd31975be113562448520f4c94fc75b9cbb09715e Author: Harald Anlauf Date: Mon Apr 4 20:42:51 2022 +0200 Fortran: a RECURSIVE procedure cannot be an INTRINSIC gcc/fortran/ChangeLog: PR fortran/105138 * intrinsic.c (gfc_is_intrinsic): When a symbol refers to a RECURSIVE procedure, it cannot be an INTRINSIC. gcc/testsuite/ChangeLog: PR fortran/105138 * gfortran.dg/recursive_reference_3.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit d46685b04071a485b56de353d997a866bfc8caba)
[Bug fortran/104849] ICE in find_array_section, at fortran/expr.cc:1616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104849 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:9fed680237d2c4242d3273ab8f64c82231d5eeb7 commit r10-10747-g9fed680237d2c4242d3273ab8f64c82231d5eeb7 Author: Harald Anlauf Date: Wed Mar 9 21:58:26 2022 +0100 Fortran: improve error recovery on invalid array section gcc/fortran/ChangeLog: PR fortran/104849 * expr.c (find_array_section): Avoid NULL pointer dereference on invalid array section. gcc/testsuite/ChangeLog: PR fortran/104849 * gfortran.dg/pr104849.f90: New test. (cherry picked from commit 22015e77d3e45306077396b9de8a8a28bb67fb20)
[Bug fortran/105230] [9/10/11/12/13 Regression] ICE in find_array_section, at fortran/expr.cc:1634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105230 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bbcff39a4c1004ef55c6a6330408a9fe8c258d01 commit r10-10748-gbbcff39a4c1004ef55c6a6330408a9fe8c258d01 Author: Harald Anlauf Date: Tue May 10 23:41:57 2022 +0200 Fortran: fix error recovery on invalid array section gcc/fortran/ChangeLog: PR fortran/105230 * expr.c (find_array_section): Correct logic to avoid NULL pointer dereference on invalid array section. gcc/testsuite/ChangeLog: PR fortran/105230 * gfortran.dg/pr105230.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit 0acdbe29f66017fc5cca40dcbd72a0dd41491d07)
[Bug analyzer/105103] RFE: detect bogus use of varargs in analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105103 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Implemented by the above patch for GCC 13
[Bug fortran/105138] [7,8,9,10,F95] Bogus error when function name does not shadow an intrinsic when RESULT clause is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138 --- Comment #17 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f43db17894744827d93ddcea7952d4ecf1f83f30 commit r9-10186-gf43db17894744827d93ddcea7952d4ecf1f83f30 Author: Harald Anlauf Date: Mon Apr 4 20:42:51 2022 +0200 Fortran: a RECURSIVE procedure cannot be an INTRINSIC gcc/fortran/ChangeLog: PR fortran/105138 * intrinsic.c (gfc_is_intrinsic): When a symbol refers to a RECURSIVE procedure, it cannot be an INTRINSIC. gcc/testsuite/ChangeLog: PR fortran/105138 * gfortran.dg/recursive_reference_3.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit d46685b04071a485b56de353d997a866bfc8caba)
[Bug fortran/105138] [7,8,9,10,F95] Bogus error when function name does not shadow an intrinsic when RESULT clause is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|13.0|9.5 --- Comment #18 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/104849] ICE in find_array_section, at fortran/expr.cc:1616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104849 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6b8cd1fb402163e16d2a139f4bee346ff0c8f234 commit r9-10187-g6b8cd1fb402163e16d2a139f4bee346ff0c8f234 Author: Harald Anlauf Date: Wed Mar 9 21:58:26 2022 +0100 Fortran: improve error recovery on invalid array section gcc/fortran/ChangeLog: PR fortran/104849 * expr.c (find_array_section): Avoid NULL pointer dereference on invalid array section. gcc/testsuite/ChangeLog: PR fortran/104849 * gfortran.dg/pr104849.f90: New test. (cherry picked from commit 22015e77d3e45306077396b9de8a8a28bb67fb20)
[Bug fortran/105230] [9/10/11/12/13 Regression] ICE in find_array_section, at fortran/expr.cc:1634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105230 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a9717558340352c832413343cef71f588eaf commit r9-10188-ga9717558340352c832413343cef71f588eaf Author: Harald Anlauf Date: Tue May 10 23:41:57 2022 +0200 Fortran: fix error recovery on invalid array section gcc/fortran/ChangeLog: PR fortran/105230 * expr.c (find_array_section): Correct logic to avoid NULL pointer dereference on invalid array section. gcc/testsuite/ChangeLog: PR fortran/105230 * gfortran.dg/pr105230.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit 0acdbe29f66017fc5cca40dcbd72a0dd41491d07)
[Bug fortran/105230] [9/10/11/12/13 Regression] ICE in find_array_section, at fortran/expr.cc:1634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105230 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all open branches.
[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #2) > This fixes the problem. Someone that regularly use git will need to commit > it. Are you sure this is the right solution? Consider: program p type t character(3) :: c = '(a)' end type class(t), parameter :: x = t() class(*), parameter :: y = t() print x%c end Intel accepts the code, and I haven't found anything prohibiting the above. F2018 has: C850 An entity with the PARAMETER attribute shall not be a variable, a coarray, or a procedure. I think we see here an area where gfortran lacks newer features. We shouldn't simply reject PARAMETER and CLASS. (There are a couple of related PRs.)
[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47359 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE CC||anlauf at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #7 from anlauf at gcc dot gnu.org --- The issue is resolved by the fix for pr105138. Thus very likely a duplicate. Closing. *** This bug has been marked as a duplicate of bug 105138 ***
[Bug fortran/105138] [7,8,9,10,F95] Bogus error when function name does not shadow an intrinsic when RESULT clause is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||rofirrim at gmail dot com --- Comment #19 from anlauf at gcc dot gnu.org --- *** Bug 47359 has been marked as a duplicate of this bug. ***
[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834 Bug 32834 depends on bug 47359, which changed state. Bug 47359 Summary: Recursive functions of intrinsic names generates invalid assembler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47359 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #3) > F2018 has: > > C850 An entity with the PARAMETER attribute shall not be a variable, a > coarray, or a procedure. Or we see here an disagreement between C850 and C708.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #17 from harper at msor dot vuw.ac.nz --- 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). On Mon, 16 May 2022, jvdelisle at gcc dot gnu.org wrote: > Date: Mon, 16 May 2022 00:49:44 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug fortran/105473] semicolon allowed when list-directed read > integer with decimal='point' > Resent-Date: Mon, 16 May 2022 12:49:53 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 > > --- Comment #13 from Jerry DeLisle --- > With John's multiple combinations test case I get the following results with > the attached patch. All places where we gave an error before the patch, we > give > errors now plus new errors > > $ gfc multi.f90 > $ ./a.out > i= 1 input(i) = "2,5," > with decimal=point x(:) = 2. 5. ios= 0 > with decimal=comma x(:) = 2. 666.00 ios=5010 > i= 2 input(i) = "2;5," > with decimal=point x(:) = 2. 666.00 ios=5010 > with decimal=comma x(:) = 2. 5. ios= 0 > i= 3 input(i) = "2 5," > with decimal=point x(:) = 2. 5. ios= 0 > with decimal=comma x(:) = 2. 5. ios= 0 > i= 4 input(i) = "2.5," > with decimal=point x(:) = 2.5000 5. ios= -1 > with decimal=comma x(:) = 2.5000 666.00 ios=5010 > i= 5 input(i) = "2,5;" > with decimal=point x(:) = 2. 5. ios=5010 > with decimal=comma x(:) = 2.5000 666.00 ios= -1 > i= 6 input(i) = "2;5;" > with decimal=point x(:) = 2. 666.00 ios=5010 > with decimal=comma x(:) = 2. 5. ios= 0 > i= 7 input(i) = "2 5;" > with decimal=point x(:) = 2. 5. ios=5010 > with decimal=comma x(:) = 2. 5. ios= 0 > 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= 9 input(i) = "2,5 " > with decimal=point x(:) = 2. 5. ios= 0 > with decimal=comma x(:) = 2.5000 666.00 ios= -1 > i= 10 input(i) = "2;5 " > with decimal=point x(:) = 2. 666.00 ios=5010 > with decimal=comma x(:) = 2. 5. ios= 0 > i= 11 input(i) = "2 5 " > with decimal=point x(:) = 2. 5. ios= 0 > with decimal=comma x(:) = 2. 5. ios= 0 > i= 12 input(i) = "2.5 " > with decimal=point x(:) = 2.5000 5. ios= -1 > with decimal=comma x(:) = 2.5000 666.00 ios= -1 > i= 13 input(i) = "2,5." > with decimal=point x(:) = 2. 5. ios= 0 > with decimal=comma x(:) = 2. 666.00 ios=5010 > i= 14 input(i) = "2;5." > with decimal=point x(:) = 2. 666.00 ios=5010 > with decimal=comma x(:) = 2. 5. ios= 0 > i= 15 input(i) = "2 5." > with decimal=point x(:) = 2. 5. ios= 0 > with decimal=comma x(:) = 2. 5. ios= 0 > i= 16 input(i) = "2.5." > with decimal=point x(:) = 2. 5. ios=5010 > with decimal=comma x(:) = 2. 666.00 ios=5010 > [jerry@amdr pr105473]$ gfc multi.f90 > [jerry@amdr pr105473]$ ./a.out > i= 1 input(i) = "2,5," > with decimal=point x(:) = 2. 5. ios= 0 > with decimal=comma x(:) = 2. 666.00 ios=5010 > Bad real number in item 1 of list input > i= 2 input(i) = "2;5," > with decimal=point x(:) = 2. 666.00 ios=5010 > Semicolon not allowed as separator with DECIMAL='point' > with decimal=comma x(:) = 2. 5. ios= 0 > i= 3 input(i) = "2 5," > with decimal=point x(:) = 2. 5. ios= 0 > with decimal=comma x(:) = 2. 5. ios= 0 > i= 4 input(i) = "2.5," > with decimal=point x(:) = 2.5000 5. ios= -1 > End of file > with decimal=comma x(:) = 2.5000 666.
[Bug c++/105553] [11/12/13 Regression] [DR1640] Deduction when attempting to create an array with an element type that is an abstract class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105553 --- Comment #3 from Glen Joseph Fernandes --- I would have expected this to only take effect in C++20 standards mode, leaving C++03 through C++17 modes with no change in behavior. Given the following intention in your commit message: > This change was moved as a DR, so I'm applying it to all standard levels. This could be reconsidered if it causes problems, but I don't expect it to. I'm going to assume that in general this wasn't a problem for most users. :)
[Bug c/105492] [13 Regression] ICE in set_underlying_type, at c-family/c-common.cc:8164 since r13-57-g0aa277bf0b4b7943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105492 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ed12749a3c9d9569a2c23df2e0db2136dcd3512d commit r13-515-ged12749a3c9d9569a2c23df2e0db2136dcd3512d Author: Jason Merrill Date: Thu May 5 11:03:44 2022 -0400 attribs: fix typedefs in generic code [PR105492] In my patch for PR100545 I added an assert to check for broken typedefs in set_underlying_type, and it found one in this case: rs6000_handle_altivec_attribute had the same problem as handle_mode_attribute. So let's move the fixup into decl_attributes. PR c/105492 gcc/ChangeLog: * attribs.cc (decl_attributes): Fix broken typedefs here. gcc/c-family/ChangeLog: * c-attribs.cc (handle_mode_attribute): Don't fix broken typedefs here.
[Bug c++/105623] New: [12/13 regression][rejects valid] invalid use of auto when deducing return type of base class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105623
Bug ID: 105623
Summary: [12/13 regression][rejects valid] invalid use of auto
when deducing return type of base class template
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hello at josephloser dot com
Target Milestone: ---
The following code used to work in GCC 11.3.0, but fails on GCC 12.1.0 and
trunk.
```
#include
constexpr auto g(auto name_fn) {
return name_fn();
}
template struct ct_string {
static constexpr char str[] = {Cs..., 0};
static constexpr auto name() { return std::string_view{str, sizeof...(Cs)};
}
};
struct S : ct_string<'f', 'o', 'o'> {
constexpr auto f() {
return g(name);
}
};
int main() {
{
S s;
[[maybe_unused]] constexpr auto name = s.f();
}
return 0;
}
```
This code works on GCC 11.3.0 but fails on GCC 12.1.0 onward, including trunk.
See it live at https://godbolt.org/z/9c8vb1eP5
One workaround is to explicitly provide the return type for `ct_string::foo`
static function such as at https://godbolt.org/z/ccqPxoM5P which works on GCC
11.3.0, 12.1.0, and trunk.
[Bug c/105492] [13 Regression] ICE in set_underlying_type, at c-family/c-common.cc:8164 since r13-57-g0aa277bf0b4b7943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105492 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jason Merrill --- Fixed.
[Bug c++/105623] [12/13 regression][rejects valid] invalid use of auto when deducing return type of base class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105623 Marek Polacek changed: What|Removed |Added Target Milestone|--- |12.2 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-16 Priority|P3 |P2 Keywords||rejects-valid CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Seems to have started with r12-1273-g1a98f830332e5a I'll try to reduce.
[Bug c++/105623] [12/13 regression][rejects valid] invalid use of auto when deducing return type of base class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105623
--- Comment #2 from Marek Polacek ---
// PR c++/105623
auto g(auto) {}
template struct ct_string {
static auto name() {}
};
struct S : ct_string<> {
auto f() { g(name); }
};
[Bug tree-optimization/102583] [x86] Failure to optimize 32-byte integer vector conversion to 16-byte float vector properly when converting upper part with -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102583 --- Comment #7 from Gabriel Ravier --- Can confirm it is indeed fixed
[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
pc at gcc dot gnu.org changed:
What|Removed |Added
CC||pc at gcc dot gnu.org
--- Comment #1 from pc at gcc dot gnu.org ---
gcc/testsuite/g++.dg/tsan/pr88018.C includes one of the files moved in the
patch:
```
// { dg-skip-if "" { *-*-* } { "*" } { "-O0" } }
// { dg-options "-fsanitize=thread -fno-ipa-pure-const -O1
-fno-inline-functions-called-once -w" }
#include "../pr69667.C"
```
I admit ignorance on the meaning or importance of the directory structure here.
Indeed the patch which moved pr69667.C was a small attempt to clean things up a
bit.
Would it be correct to move this test from g++.dg/tsan to g++.target/powerpc ?
(Or, do I need to move pr69667.C back to its original location? Or, do I need
to update the path within pr88018.C, which seems like the worst option?)
Did I miss this because I used `--disable-libsanitizer`, or because I just
missed that there was a FAIL for a test which I mistakenly thought was
unrelated to my changes? (There are a lot of FAILs to ignore.)
[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 --- Comment #5 from Steve Kargl --- On Mon, May 16, 2022 at 08:27:24PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 > > --- Comment #3 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #2) > > This fixes the problem. Someone that regularly use git will need to commit > > it. > > Are you sure this is the right solution? > 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.
[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 --- Comment #6 from Steve Kargl --- On Mon, May 16, 2022 at 10:16:51PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 > > --- Comment #5 from Steve Kargl --- > On Mon, May 16, 2022 at 08:27:24PM +, anlauf at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 > > > > --- Comment #3 from anlauf at gcc dot gnu.org --- > > (In reply to kargl from comment #2) > > > This fixes the problem. Someone that regularly use git will need to > > > commit > > > it. > > > > Are you sure this is the right solution? > > > > 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. > 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?
[Bug c++/105623] [12/13 regression][rejects valid] invalid use of auto when deducing return type of base class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105623
--- Comment #3 from David Stone ---
Simplified reproduction:
```
auto g(auto fn) {
return fn();
}
template
struct base {
static auto value() {
return 0;
}
};
struct S : base {
static auto f() -> int {
return g(value);
}
};
```
See it live: https://godbolt.org/z/18n8M8oG9
An additional workaround is to explicitly take the address of the function in
line 14 of my reproducer: `return g(&value);`.
[Bug tree-optimization/102583] [x86] Failure to optimize 32-byte integer vector conversion to 16-byte float vector properly when converting upper part with -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102583 H.J. Lu changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from H.J. Lu --- Fixed for GCC 13.
[Bug target/105073] [meta bug]Patch pending for GCC13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105073 Bug 105073 depends on bug 102583, which changed state. Bug 102583 Summary: [x86] Failure to optimize 32-byte integer vector conversion to 16-byte float vector properly when converting upper part with -mavx2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102583 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/105615] Partial ordering of constraints with empty parameter mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105615 Patrick Palka changed: What|Removed |Added Resolution|--- |INVALID CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- 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.
[Bug tree-optimization/105591] [13 Regression] ICE: in tree_to_poly_uint64, at tree.cc:3250 with -O -mavx512f -mno-avx2 since r13-379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105591 --- Comment #13 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:1fba0608d12a209a5d76d65bcb1dec1c07bc33e9 commit r13-517-g1fba0608d12a209a5d76d65bcb1dec1c07bc33e9 Author: liuhongt Date: Mon May 16 09:06:04 2022 +0800 Clamp vec_perm_expr index in simplify_bitfield_ref to avoid ICE. gcc/ChangeLog: PR tree-optimization/105591 * tree-ssa-forwprop.cc (simplify_bitfield_ref): Clamp vec_perm_expr index. gcc/testsuite/ChangeLog: * gcc.dg/pr105591.c: New test.
[Bug tree-optimization/105591] [13 Regression] ICE: in tree_to_poly_uint64, at tree.cc:3250 with -O -mavx512f -mno-avx2 since r13-379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105591 --- Comment #14 from Hongtao.liu --- Fixed in GCC13.
[Bug target/105033] Suboptimal for vec_concat lower halves of two vectors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105033 --- Comment #2 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:105c56a8cfde6015b989ab22c20c915c1b4e69ec commit r13-518-g105c56a8cfde6015b989ab22c20c915c1b4e69ec Author: liuhongt Date: Fri May 13 09:59:13 2022 +0800 Optimize vpermtiw/b to vpunpcklqdq for certain cases. Assembly Optimization like: - vmovq %xmm0, %xmm2 - vmovdqa .LC0(%rip), %xmm0 vmovq %xmm1, %xmm1 - vpermi2w%xmm1, %xmm2, %xmm0 + vmovq %xmm0, %xmm0 + vpunpcklqdq %xmm1, %xmm0, %xmm0 ... -.LC0: - .value 0 - .value 1 - .value 2 - .value 3 - .value 8 - .value 9 - .value 10 - .value 11 gcc/ChangeLog: PR target/105033 * config/i386/sse.md (*vec_concatv4si): Extend to .. (*vec_concat): .. V16QI and V8HImode. (*vec_concatv16qi_permt2): New pre_reload define_insn_and_split. (*vec_concatv8hi_permt2): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr105033.c: New test.
[Bug target/105033] Suboptimal for vec_concat lower halves of two vectors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105033 Hongtao.liu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hongtao.liu --- Fixed in GCC13.
[Bug target/105073] [meta bug]Patch pending for GCC13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105073 Bug 105073 depends on bug 105033, which changed state. Bug 105033 Summary: Suboptimal for vec_concat lower halves of two vectors. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105033 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/105624] New: [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
Bug ID: 105624
Summary: [13 Regression] ICE in final_scan_insn_1, at
final.cc:2861 (error: could not split insn)
Product: gcc
Version: 13.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: x86_64-pc-linux-gnu
gcc 13.0.0 20220515 snapshot (g:18547874ee205d830acb31f1e3c1c89fc7725c14) ICEs
when compiling the following testcase w/ -march=k8 -O1:
union U {
double d;
unsigned long long int i;
};
double
fabs (double x)
{
union U u;
u.d = x;
u.i &= ~0ULL >> 1;
return u.d;
}
% x86_64-pc-linux-gnu-gcc-13.0.0 -march=k8 -O1 -c ifnwa4ea.c
ifnwa4ea.c: In function 'fabs':
ifnwa4ea.c:15:1: error: could not split insn
15 | }
| ^
(insn 8 17 18 2 (parallel [
(set (reg:DI 0 ax [91])
(and:DI (reg:DI 0 ax [91])
(reg:DI 20 xmm0 [89])))
(clobber (reg:CC 17 flags))
]) "ifnwa4ea.c":14:11 530 {*anddi_1_btr}
(expr_list:REG_DEAD (reg:DI 20 xmm0 [89])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
during RTL pass: final
ifnwa4ea.c:15:1: internal compiler error: in final_scan_insn_1, at
final.cc:2861
0x73a629 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/rtl-error.cc:108
0x6c15f7 final_scan_insn_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/final.cc:2861
0xb6e51b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/final.cc:2940
0xb6e775 final_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/final.cc:1997
0xb6f351 rest_of_handle_final
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/final.cc:4285
0xb6f351 execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220515/work/gcc-13-20220515/gcc/final.cc:4363
[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 #7 from Hongtao.liu --- 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 &r0,and thought it was load not scalar？ r0.1_21 1 times scalar_store costs 12 in body r1.3_23 1 times scalar_store costs 12 in body r2.5_25 1 times scalar_store costs 12 in body r3.7_27 1 times scalar_store costs 12 in body node 0x866f238 1 times vec_construct costs 4 in prologue node 0x866f238 1 times vec_construct costs 4 in prologue r0.1_21 2 times unaligned_store (misalign -1) costs 24 in body /app/example.c:10:10: note: Cost model analysis for part in loop 0: Vector cost: 32 Scalar cost: 48
[Bug c++/105625] New: Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 Bug ID: 105625 Summary: Support .llvm_addrsig section Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- This is a feature request to implement an LLVM-compatible feature so that linkers can optimize GCC-generated object files as much as they can currently do for LLVM-generated ones. Disclaimer: I'm the creator of the mold linker (https://github.com/rui314/mold) Background: GNU gold and LLVM lld have a feature so-called Identical Code Folding (ICF). ICF finds functions that happen to be compiled to the exact same machine code to merge them. This is known as an effective optimization especially for C++ programs, since a function template tend to be compiled to the same machine code for different types. For example, `std::vector` and `std::vector` are likely to be instantiated to the exact same machine code, even though they will get different mangled names. ICF can merge such code. There's one caveat though. ICF is not a "safe" optimization. In C/C++, two function pointers are equal if and only if they are pointing the same function. For example, if you have two different functions `foo` and `bar`, `foo == bar` will never be true. ICF breaks this assumption if it merges `foo` and `bar`, as after merging, they will be at the same address. That said, if you know that there's no code that takes a pointer of `foo` or `bar`, it is safe to merge `foo` with `bar`, since it's impossible to compare pointers without taking their addresses. gold and lld implement a "safe" ICF with that observation. The gold's safe ICF merges only C++ constructors and destructors. Since there's no way to obtain a pointer of a ctors or dtors within the C++ language spec, they are always safe to merge. gold identifies ctors and dtors by reading their mangled names. What gold does is safe but too conservative as it cannot merge other functions. The lld's safe ICF works with an LLVM feature. Since mid-2018, LLVM emits a `.llvm_addrsig` section to all object files by default. That section contains symbol indices whose addresses are taken. Using this table, lld can merge functions more aggressively than gold can do. Recently, we implemented an lld-compatible safe ICF to mold. It works great, but it doesn't work with GCC as GCC does not produce `.llvm_addrsig` sections. Feature request: Can GCC produce the `.llvm_addrsig` section just like LLVM does? It will make GCC-generated executables on par with LLVM-generated ones with ICF in terms of file size. References: Here is an explanation of the `.llvm_addrsig` section: https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table This is a patch to have added the feature to LLVM: https://reviews.llvm.org/D47744 Here is an upstream issue for mold: https://github.com/rui314/mold/issues/484
[Bug c++/105625] Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 --- Comment #1 from Andrew Pinski --- I see most of it was implemented in the assembler. So you might want to report the support for .addrsig directive there too.
[Bug c++/105625] Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2022-05-17 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- >From reading the specifications of the extension, you do need assembler support first as there is no way for GCC to emit a reference to the index of the symbol table as that is not exposed via normal assembler directives. Suspended until GNU binutils support is added.
[Bug ipa/105625] Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 --- Comment #3 from Rui Ueyama --- I think we can implement the `.addrsig` support to the assembler, but I wonder if GCC will support it once the GNU assembler gains the feature?
[Bug ipa/105625] Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 --- Comment #4 from Andrew Pinski --- (In reply to Rui Ueyama from comment #3) > I think we can implement the `.addrsig` support to the assembler, but I > wonder if GCC will support it once the GNU assembler gains the feature? Yes I think it will, shouldn't be too hard to implement because IPA cgraph already has that information and uses it for ICF inside GCC.
[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 #8 from Hongtao.liu --- (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 &r0,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; (gdb) l 21723246move it to a vector register, otherwise we have to go 21823247via a GPR or via vpinsr which involves similar cost. 21923248Likewise with a BIT_FIELD_REF extracting from a vector 22023249register we can hope to avoid using a GPR. */ 22123250 if (!is_gimple_assign (def) 3251 || (!gimple_assign_load_p (def) 22323252 && (gimple_assign_rhs_code (def) != BIT_FIELD_REF 22423253 || !VECTOR_TYPE_P (TREE_TYPE 22523254 (TREE_OPERAND (gimple_assign_rhs1 (def), 0)) 22623255 stmt_cost += ix86_cost->sse_to_integer;
[Bug ipa/105625] Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 --- Comment #5 from Rui Ueyama --- Cool! We'll add a `.llvm_addrsig` support to binutils and get back to you guys.
