[Bug target/108484] [13 Regression] ICE building glibc for ia64 in cselib_subst_to_values, at cselib.cc:2148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug libstdc++/108487] [10/11/12/13 Regression] ~20-30x slowdown in populating std::vector from std::ranges::iota_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5 Keywords||missed-optimization
[Bug c++/104177] coroutine frame is not being allocated with the correct alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 --- Comment #19 from Andrew Pinski --- (In reply to Andrew Pinski from comment #17) > (In reply to David Ledger from comment #15) > > This is a complete minimum reproduction, just to aid Iain Sandoe: > > This is well defined code? because I thought operator new has alignment > requirements as defined by the C++ standard ... That example is undefined even by the standard operator new according basic.stc.dynamic.allocation/3.3 rule. (and undefined even worse by not enough for the size too).
[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 --- Comment #16 from Sam James --- (In reply to felix from comment #15) He means apinski who submitted a patch, not you.
[Bug c++/104177] coroutine frame is not being allocated with the correct alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 --- Comment #18 from Andrew Pinski --- basic.stc.dynamic.allocation/3 seems to be the important part here.
[Bug c++/104177] coroutine frame is not being allocated with the correct alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 --- Comment #17 from Andrew Pinski --- (In reply to David Ledger from comment #15) > This is a complete minimum reproduction, just to aid Iain Sandoe: This is well defined code? because I thought operator new has alignment requirements as defined by the C++ standard ...
[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 --- Comment #15 from felix at breitweiser dot de --- (In reply to Richard Earnshaw from comment #14) > (In reply to Richard Biener from comment #13) > > (In reply to Andrew Pinski from comment #10) > > > Updated patch submitted: > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589254.html > > > > I think you need to ping your patches more aggressively ... > > Richard Sandiford reviewed it here:| > https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589581.html > So the problem is that the review wasn't followed up by the submitter. I did not know that I have any further obligation on this past submitting the bug, I never submitted a bug before. Anyway, the since the patch works (at least for my use case), do I have to mark this as resolved, fixed?
[Bug tree-optimization/108449] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108449 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/108449] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108449 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:106f99406312d7ed47434de53c180718225ffa5e commit r13-5285-g106f99406312d7ed47434de53c180718225ffa5e Author: Richard Biener Date: Thu Jan 19 08:44:25 2023 +0100 tree-optimization/108449 - keep maybe_special_function_p behavior When we have a static declaration without definition we diagnose that and turn it into an extern declaration. That can alter the outcome of maybe_special_function_p here and there's really no point in doing that, so don't. PR tree-optimization/108449 * cgraphunit.cc (check_global_declaration): Do not turn undefined statics into externs. * gcc.dg/pr108449.c: New testcase.
[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #13 from Richard Biener --- I will have a look.
[Bug target/108489] internal_error adding data fields in a promise_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108489 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu Component|c++ |target Keywords||GC, ice-on-valid-code --- Comment #3 from Andrew Pinski --- Add --param ggc-min-expand=0 --param ggc-min-heapsize=0 gets a different crash and it only crashes on x86_64-linux-gnu (aarch64-linux-gnu seems to work). Get a different crash with -g also. There is some GC issue going on too dealing with RTL. The gimple IR at this point: _5 = operator new (40); _5->_Coro_frame_needs_free = 1; _5->_Coro_resume_fn = example; _5->_Coro_destroy_fn = example; .value = 0; .m_handle = 0B; _5->_Coro_resume_index = 0; example (_5); return ; The crash happens while expanding: .value = 0; (I think) I am not 100% sure this is valid gimple IR with a call between the assignment of and the return. But it might also be valid and then the bug is the target backend I think. Also the struct needs the following sized fields with the padding (you can't even be explict with the padding either): int t = 0; long t1 = 0;
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Richard Biener --- Fixed
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 --- Comment #15 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e61d43791e0943414d33c96de1dd4bfe5f611e29 commit r13-5284-ge61d43791e0943414d33c96de1dd4bfe5f611e29 Author: Richard Biener Date: Fri Jan 20 12:27:50 2023 +0100 modula2/108144 - Fix multilib install of libgm2 The following adjusts libgm2 to properly use the multilib build infrastructure, thereby fixing the install with --enable-version-specific-runtime-libs In particular config-ml.pl needs to be applied to generated Makefiles as documented in the manual and we have to avoid clobbering the variables via make arguments. The explicit install rules used different ways to construct the multilib dir which isn't necessary and breaks when MUTLIDIR is now finally set correctly. Instead use $(toolexeclibdir). This results in some dead variables in the Makefile.am (and there were some before), I refrained from doing even more changes here. Verified with an install with and without --enable-version-specific-runtime-libs and checking the result. PR modula2/108144 libgm2/ * configure.ac: Apply config-ml.pl to the generated Makefiles. Set multilib_arg, use AM_PROG_LIBTOOL. * configure: Regenerate. * Makefile.am (AM_MAKEFLAGS): Do not override MULTI* flags. * Makefile.in: Regenerate. * libm2cor/Makefile.am: Install to $(toolexeclibdir)$(M2LIBDIR) rather than $(inst_libdir)/$(MULTIDIR)$(M2LIBDIR). * libm2iso/Makefile.am: Likewise. * libm2log/Makefile.am: Likewise. * libm2min/Makefile.am: Likewise. * libm2pim/Makefile.am: Likewise. * libm2cor/Makefile.in: Regenerate. * libm2iso/Makefile.in: Likewise. * libm2log/Makefile.in: Likewise. * libm2min/Makefile.in: Likewise. * libm2pim/Makefile.in: Likewise.
[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 --- Comment #10 from pefoley2 at pefoley dot com --- It does? I wasn't aware of that. My read of the configure options is that the two options are tangential. And from a quick skim, I couldn't find anything that made enabling lto suppress Werror. Besides, regardless of whether it's supported or not, it's another example of this issue in the wild.
[Bug c++/53288] [C++11] Lifetime of temporary object backing pointer-to-member expression not extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:208c6678c25bd9a11e6c5911a4c123cb6b7f3d6e commit r13-5283-g208c6678c25bd9a11e6c5911a4c123cb6b7f3d6e Author: Jason Merrill Date: Tue Dec 20 16:27:43 2022 -0500 c++: lifetime extension with .* expression [PR53288] This PR points out a case where we are not extending the lifetime of a temporary when the subobject is denoted by a pointer-to-member operation. These rules were clarified in C++20 by CWG1299. There are other cases that also need to be handled under CWG1299, but are not fixed by this patch. PR c++/53288 DR 1299 gcc/cp/ChangeLog: * call.cc (extend_ref_init_temps_1): Handle ptrmem expression. gcc/testsuite/ChangeLog: * g++.dg/init/lifetime4.C: New test.
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
William Westfield changed:
What|Removed |Added
CC||westfw at westfw dot info
--- Comment #15 from William Westfield ---
It seems especially weird that the following AVR program generates the warning
for only the "&=" statement.
#include "avr/io.h"
int main(void){
DDRD &= ~_BV(PD3);
DDRD |= _BV(PD3);
return 0;
}
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490 --- Comment #10 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #8) > See PR101782 where you figured out the problem in the grammar :-) You know, my memory has sometimes smaller and sometimes bigger issues ;)
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490
--- Comment #9 from Jonathan Wakely ---
For completeness:
template concept C = true;
struct S
{
template requires C
[[nodiscard]] friend constexpr bool bar (const S &, const T &) { return true;
}
};
void
foo ()
{
S s;
bar (s, 0);
}
$ g++ -std=c++20 -c f.cc -fconcepts-ts
f.cc:6:3: error: two consecutive '[' shall only introduce an attribute before
'[' token
6 | [[nodiscard]] friend constexpr bool bar (const S &, const T &) {
return true; }
| ^
f.cc: In function 'void foo()':
f.cc:13:7: error: no matching function for call to 'bar(S&, int)'
13 | bar (s, 0);
| ^~
f.cc:6:39: note: candidate: 'template requires
constexpr bool bar(const S&, const T&)'
6 | [[nodiscard]] friend constexpr bool bar (const S &, const T &) {
return true; }
| ^~~
f.cc:6:39: note: template argument deduction/substitution failed:
f.cc:6:39: note: constraints not satisfied
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490
--- Comment #8 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Jonathan Wakely from comment #2)
> > Yes. The attribute has to be there, so it's a Circle bug if it doesn't
> > support that grammar.
>
> Why can't it be before the friend specifier?
> template _Sent2>
> requires sentinel_for<_Sent, _It2>
> [[nodiscard]] friend constexpr bool
> operator== (const common_iterator& __x,
> const common_iterator<_It2, _Sent2>& __y)
> {
> ...
> }
> I mean, at least
> struct S
> {
> template
> friend constexpr bool foo [[nodiscard]] (const S &, const T &) { return
> true; }
> template
> [[nodiscard]] friend constexpr bool bar (const S &, const T &) { return
> true; }
The problem is an ambiguity in the grammar for the requires-clause, and this
example doesn't have any requires-clause.
Try:
template requires C
[[nodiscard]] friend constexpr bool bar (const S &, const T &) { return true;
}
And then compile with -fconcepts-ts
f.cc:7:3: error: two consecutive '[' shall only introduce an attribute before
'[' token
7 | [[nodiscard]] friend constexpr bool bar (const S &, const T &) {
return true; }
| ^
See PR101782 where you figured out the problem in the grammar :-)
The libstdc++ code is not written that way because I *like* putting the
attribute in that position, but because it's necessary. And it's valid C++, so
this is a Circle bug.
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490 --- Comment #7 from Jakub Jelinek --- Though, if I try the above short testcase on godbolt with C++ (Circle), build 131 still rejects it but Latest accepts, so most likely they have fixed it already.
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490 --- Comment #6 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #5) > (In reply to Jonathan Wakely from comment #2) > > Yes. The attribute has to be there, so it's a Circle bug if it doesn't > > support that grammar. > > Why can't it be before the friend specifier? Of course, it doesn't mean the bug isn't on the Circle side.
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #2)
> Yes. The attribute has to be there, so it's a Circle bug if it doesn't
> support that grammar.
Why can't it be before the friend specifier?
template _Sent2>
requires sentinel_for<_Sent, _It2>
[[nodiscard]] friend constexpr bool
operator== (const common_iterator& __x,
const common_iterator<_It2, _Sent2>& __y)
{
...
}
I mean, at least
struct S
{
template
friend constexpr bool foo [[nodiscard]] (const S &, const T &) { return true;
}
template
[[nodiscard]] friend constexpr bool bar (const S &, const T &) { return true;
}
};
void
foo ()
{
S s;
foo (s, 0);
bar (s, 0);
}
warns in both cases with various versions of g++ as well as clang++ (tried
clang++ 4 and trunk and some random in between).
ICC (even 19) doesn't warn in either case.
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490 --- Comment #4 from Siddhesh Bhupendra Kukade --- Hi, I'm new to bugzilla could you guys please tell me where to see the source code, thanks.
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490 Siddhesh Bhupendra Kukade changed: What|Removed |Added CC||contact at siddheshkukade dot com --- Comment #3 from Siddhesh Bhupendra Kukade --- Hi
[Bug libstdc++/108487] [10/11/12/13 Regression] ~20-30x slowdown in populating std::vector from std::ranges::iota_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487 --- Comment #9 from Jonathan Wakely --- I think we just want to dispatch on iterator concept not iterator category.
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490 --- Comment #2 from Jonathan Wakely --- Yes. The attribute has to be there, so it's a Circle bug if it doesn't support that grammar.
[Bug c/108423] [12/13 Regression] ICE in make_ssa_name_fn with VLA types in arguments and inlining since r12-5338-g4e6bf0b9dd5585df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423 --- Comment #7 from Martin Uecker --- * gimplify_type_size does not recurse into pointer, record, or function types (the later are not mentioned). * the C FE has code to emit fake TYPE_DECLs for pointer types in c-decl.cc/grokdeclarator * In the FE, size expressions in parameters go into pending_sizes and emitted at a start of a function c-decl.cc/store_parm_decls * function.cc/gimplify_parm_type only considers types with non-constant size and otherwise recurses only into pointer types How all this fits together is a bit of mystery to me. Modifying gimplify_parm_type to also recurse into function types seems to fix this bug (and PR107557) but I am not sure if this is the right fix. Then there should also be similar missing cases related to records/unions?
[Bug libstdc++/108487] [10/11/12/13 Regression] ~20-30x slowdown in populating std::vector from std::ranges::iota_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487
--- Comment #8 from Mark Bourgeault ---
What about something like this?
#if __cplusplus >= 201709L
template>
vector(_InputIterator __first, _InputIterator __last,
const allocator_type& __a = allocator_type())
: _Base(__a)
{
struct PseudoRange { _InputIterator begin(); _InputIterator end(); };
if constexpr (std::ranges::random_access_range) {
_M_range_initialize(__first, __last,
std::random_access_iterator_tag());
}
else if constexpr (std::ranges::forward_range) {
_M_range_initialize(__first, __last, std::forward_iterator_tag());
}
else {
_M_range_initialize(__first, __last,
std::__iterator_category(__first));
}
#else
...
#endif
-
Here is a PoC:
#include
#include
#include
template
void test(I first, I last) {
struct PseudoRange { I begin(); I end(); };
if constexpr (std::ranges::random_access_range) {
std::cout << "RA\n";
}
else if constexpr (std::ranges::forward_range) {
std::cout << "F\n";
}
else {
std::cout << "I\n";
}
}
int main() {
auto rng = std::ranges::iota_view{0, 10} | std::views::transform([](int i)
{ return i*i; });
test(rng.begin(), rng.end());
auto rng2 = std::ranges::iota_view{0, 10} | std::views::filter([](int i) {
return i%2; });
test(rng2.begin(), rng2.end());
return 0;
}
