[Bug ada/108472] gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 Dennis Clarke changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Dennis Clarke --- The bootstrap now completes just fine. However the testsuite shows a very large number of failures : https://gcc.gnu.org/pipermail/gcc-testresults/2023-January/776331.html 371 "unexpected failures" seems like a very large amount of fail for the gcc compiler. The g++ seems very good as do the other components. Also there is not even a single report of test results from anyone anywhere for 12.2.0 this month and mybe that explains why this page is broken : https://gcc.gnu.org/gcc-12/buildstat.html In fact ALL of those "buildstat" pages are broken and have been for years. That is another topic entirely. NOTE : I did *not* set LD_LIBRAR_PATH at all as I have never heard of that thing nor do I know of any document that suggests we need that. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
[Bug c/108483] gcc warns about suspicious constructs for unevaluted ?: operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483 --- Comment #6 from Jakub Jelinek --- Seems kernel has #define NULL ((void *)0), so if it is solely about allowing NULL, you could also #define ARRAY_SIZE_MAYBENULL(x) _Generic((x), void*: (BUG_ON(x), 0), default: \ sizeof(x)/sizeof(_Generic((x), void*: (x), default:*(x or similar, so that uses of the macro on anything but arrays (not pointers) or NULL pointer will be diagnosed with warning or runtime error (the latter case for non-NULL void * typed pointers).
[Bug tree-optimization/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 Alexander Monakov changed: What|Removed |Added Component|rtl-optimization|tree-optimization Keywords||needs-bisection Summary|~20-30x slowdown in |[10/11/12/13 Regression] |populating std::vector from |~20-30x slowdown in |std::ranges::iota_view |populating std::vector from ||std::ranges::iota_view CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- Regarding fn1, would you mind re-running the test on your Xeon CPU with fn2 removed from the source code and -falign-loops=32 added to gcc command line? For fn1, assembly of the inner loop should be identical, so I think the 20% you were seeing may result from different loop alignment with respect to 32b fetch boundary. Also please note that cloud instances backing godbolt.org have different CPUs, so timing results from different runs are not directly comparable. Regarding fn2, this may partially be a library issue, compiling preprocessed source from gcc-10.4 using gcc-10.2 also exhibits the problem. Inner loop becomes significantly more complicated. Bisecting should be helpful.
[Bug c/108483] gcc warns about suspicious constructs for unevaluted ?: operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483
--- Comment #7 from Jakub Jelinek ---
If it needs to be used in constant expression and you want warnings for the
non-void * cases with pointers, not arrays and errors for use of void *
pointers except for NULL, then maybe:
typedef __SIZE_TYPE__ size_t;
typedef __UINTPTR_TYPE__ uintptr_t;
#define NULL ((void *) 0)
#define ARRAY_SIZE_MAYBENULL(x) _Generic((x), void*: (size_t) (uintptr_t)
((char (*) [__builtin_constant_p (x) && (x) == 0 ? 1 : _Generic((x), void*: -1,
default: 1)]) 0), default: \
sizeof(x)/sizeof(_Generic((x), void*: (x), default:*(x
int a[10];
int *q;
void *r;
int p[] = {
ARRAY_SIZE_MAYBENULL (a),
ARRAY_SIZE_MAYBENULL (NULL),
ARRAY_SIZE_MAYBENULL ((const void *) 0),
ARRAY_SIZE_MAYBENULL ((volatile void *) 0),
ARRAY_SIZE_MAYBENULL ((void *restrict) 0),
ARRAY_SIZE_MAYBENULL ((const volatile void *) 0),
ARRAY_SIZE_MAYBENULL (q),
ARRAY_SIZE_MAYBENULL (r),
ARRAY_SIZE_MAYBENULL ((void *) (uintptr_t) 0x1234abc)
};
This warns -Wsizeof-pointer-div on the const void *, volatile void *, const
volatile void * and q cases and errors on the last 2.
clang seems to also emit those 4 -Wsizeof-pointer-div warnings, but doesn't
emit any errors nor warnings on the last 2.
[Bug c++/108489] New: internal_error adding data fields in a promise_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108489
Bug ID: 108489
Summary: internal_error adding data fields in a promise_type
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janwilmans at gmail dot com
Target Milestone: ---
https://cppcoach.godbolt.org/z/xr58MxGf9
```
#include
struct ReturnObject {
struct promise_type {
ReturnObject get_return_object() {
return {};
}
std::suspend_always initial_suspend() {
return {};
}
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() {}
};
int value = 0;
std::coroutine_handle<> m_handle;
};
ReturnObject example() {
co_await std::suspend_always{};
}
int main()
{
example();
return 0;
}
```
during RTL pass: expand
: In function 'ReturnObject example()':
:22:14: internal compiler error: in get_address_mode, at
rtlanal.cc:6277
22 | ReturnObject example() {
| ^~~
0x1bb069e internal_error(char const*, ...)
???:0
0x6ff396 fancy_abort(char const*, int, char const*)
???:0
0xa7ecfc adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See
[Bug c++/108489] internal_error adding data fields in a promise_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108489 --- Comment #1 from Jan Wilmans --- remove line 18, to make it compile, and fail at runtime using ASAN -std=c++20 -O3 -Wconversion -Wsign-conversion -Werror -Wall -Wpedantic -fcoroutines -fsanitize=address -fsanitize=undefined -freport-bug = ==1==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7fc3044ae6b8 in operator new(unsigned long) (/opt/compiler-explorer/gcc-12.2.0/lib64/libasan.so.8+0xbc6b8) #1 0x402252 in example() /app/example.cpp:24 #2 0x403007 (/app/output.s+0x403007) SUMMARY: AddressSanitizer: 40 byte(s) leaked in 1 allocation(s).
[Bug c++/108489] internal_error adding data fields in a promise_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108489 --- Comment #2 from Jan Wilmans --- tested: fails on all GCC versions after 10.1, including trunk.
[Bug target/108287] AVR build: gcc/config/avr/t-avr tries to edit the source tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287 --- Comment #4 from Georg-Johann Lay --- Well, updating or creating some auto-generated files is intentional. What's not supported as of GCC documentation is configure'ing in the source tree: https://gcc.gnu.org/install/configure.html > First, we **highly** recommend that GCC be built into a separate directory > from the sources which does not reside within the source tree. > This is how we generally build GCC; building where srcdir == objdir > should still work, but doesn’t get extensive testing; building where > objdir is a subdirectory of srcdir is unsupported. The reason why it does not work for you might be: 1) Maybe you changed avr-mcus.def to support more devices. This change will trigger more changes, for example to auto-generated documentation (texi) bits. This means you are basically a maintainer, which in turn means you migth have more jobs to do, or tools to use than a simple user who just builds GCC from source. 2) When you get the sources from some repo like git, the checked-out sources might have timestamps that don't reflect their true state. This triggers make to re-build auto-generated files, even though no prerequisite was changed and the targets need not be rebuilt. To fix this, run ./contrib/gcc_update --touch from the top-level source dir. This script will touch some source files and fix their timestamps. You obviously need write permission for that.
[Bug target/108287] AVR build: gcc/config/avr/t-avr tries to edit the source tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287 --- Comment #5 from Georg-Johann Lay --- ...ok, yes, building outside srcdir won't fix this one. But points 1) and 2) still apply.
[Bug target/106307] error when I do a test on a pointer on Arduino 1.8.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106307 Georg-Johann Lay changed: What|Removed |Added Last reconfirmed||2023-01-21 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING
[Bug tree-optimization/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 #2 from MARK BOURGEAULT --- >> For fn1, assembly of the inner loop should be identical, so I think the 20% >> you were seeing may result from different loop alignment with respect to 32b >> fetch boundary Yes, it does appear that this is the explanation for the difference. Here are the full results: original code * gcc 10.3 -std=c++20 -O3 => fn1 = ~2000ms, fn2 = ~1000ms * gcc 10.3 -std=c++20 -O3 -falign-loops=32 => fn1 = ~2000ms, fn2 = ~1000ms * gcc 12.2 -std=c++20 -O3 => fn1 = ~2500ms, fn2 = ~32000ms * gcc 12.2 -std=c++20 -O3 -falign-loops=32 => fn1 = ~2000ms, fn2 = ~32000ms fn1 only * gcc 10.3 -std=c++20 -O3 => fn1 = ~2500ms * gcc 10.3 -std=c++20 -O3 -falign-loops=32 => fn1 = ~2000ms * gcc 12.2 -std=c++20 -O3 => fn1 = ~2000ms * gcc 12.2 -std=c++20 -O3 -falign-loops=32 => fn1 = ~2000ms >> Also please note that cloud instances backing godbolt.org have different >> CPUs, so timing results from different runs are not directly comparable. Yes, I know. I really only used godbolt to reach the conclusion that the issue still exists on trunk.
[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 --- Comment #5 from David Binderman --- (In reply to David Binderman from comment #0) > The bug seems to exist since sometime before g:02c031088ac0bbf7, dated > 20221220. I tried out a revision from a month earlier, dated 2022-11-20, g:59cc4da605e5cb8e, and the bug seems to exist there too. I will try 8f2358.
[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 --- Comment #6 from David Binderman --- (In reply to David Binderman from comment #5) > (In reply to David Binderman from comment #0) > > The bug seems to exist since sometime before g:02c031088ac0bbf7, dated > > 20221220. > > I tried out a revision from a month earlier, dated 2022-11-20, > g:59cc4da605e5cb8e, and the bug seems to exist there too. > > I will try g:8f2358724fa4 That worked, so the current range is [g:8f2358724fa4,g:59cc4da605e5cb8e]. I will try a git bisect.
[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 --- Comment #7 from David Binderman --- (In reply to David Binderman from comment #6) > (In reply to David Binderman from comment #5) > > (In reply to David Binderman from comment #0) > > > The bug seems to exist since sometime before g:02c031088ac0bbf7, dated > > > 20221220. > > > > I tried out a revision from a month earlier, dated 2022-11-20, > > g:59cc4da605e5cb8e, and the bug seems to exist there too. > > > > I will try g:8f2358724fa4 > > That worked, so the current range is [g:8f2358724fa4,g:59cc4da605e5cb8e]. > > I will try a git bisect. Git hash g:e7c8f5005bf87e4b seemed good, so I am trying g:3e070cff11f81051.
[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 --- Comment #8 from David Binderman --- (In reply to David Binderman from comment #7) > (In reply to David Binderman from comment #6) > > (In reply to David Binderman from comment #5) > > > (In reply to David Binderman from comment #0) > > > > The bug seems to exist since sometime before g:02c031088ac0bbf7, dated > > > > 20221220. > > > > > > I tried out a revision from a month earlier, dated 2022-11-20, > > > g:59cc4da605e5cb8e, and the bug seems to exist there too. > > > > > > I will try g:8f2358724fa4 > > > > That worked, so the current range is > > [g:8f2358724fa4,g:59cc4da605e5cb8e]. > > > > I will try a git bisect. > > Git hash g:e7c8f5005bf87e4b seemed good, so I am trying g:3e070cff11f81051. That seems bad, so trying g:51a233b97cc9c51e. Current range is about 151 revisions.
[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
Alexander Monakov changed:
What|Removed |Added
Component|tree-optimization |libstdc++
--- Comment #3 from Alexander Monakov ---
libstdc++ uses a less efficient specialization of _M_range_initialize.
With 10.2 headers, we use
template
void
_M_range_initialize(_ForwardIterator __first, _ForwardIterator __last,
std::forward_iterator_tag)
{
const size_type __n = std::distance(__first, __last);
this->_M_impl._M_start
= this->_M_allocate(_S_check_init_len(__n, _M_get_Tp_allocator()));
this->_M_impl._M_end_of_storage = this->_M_impl._M_start + __n;
this->_M_impl._M_finish =
std::__uninitialized_copy_a(__first, __last,
this->_M_impl._M_start,
_M_get_Tp_allocator());
}
but with 10.4 headers, we use
template
void
_M_range_initialize(_InputIterator __first, _InputIterator __last,
std::input_iterator_tag)
{
try {
for (; __first != __last; ++__first)
emplace_back(*__first);
} catch(...) {
clear();
throw;
}
}
[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 --- Comment #9 from David Binderman --- (In reply to David Binderman from comment #8) > Current range is about 151 revisions. After a few more rounds, current range seems to be g:fbad7a74aaaddea3 to g:c16c40808331a029, some 10 commits.
[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 David Binderman changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #10 from David Binderman --- (In reply to David Binderman from comment #9) > (In reply to David Binderman from comment #8) > > Current range is about 151 revisions. > > After a few more rounds, current range seems to be g:fbad7a74aaaddea3 > to g:c16c40808331a029, some 10 commits. Both remaining revisions are by Richard, so adding them in.
[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 --- Comment #11 from David Binderman --- It looks to me like g:af96500eea72c674a5686b35c66202ef2bd9688f is the culprit. Over to Richard for their best advice.
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #14 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:442d2bdc1d2a98aba0b18aeaa3e87fa946ac8031 commit r13-5274-g442d2bdc1d2a98aba0b18aeaa3e87fa946ac8031 Author: Iain Sandoe Date: Wed Jan 18 19:58:33 2023 + Darwin, fixincludes: Handle MacOS13 SDK Apple-specific deprecations [PR107568]. The SDK for MacOS13 includes Apple-specific deprecations of some functions that are not deprecated in Posix, C or C++ and widely used in GCC. The fix makes the deprecation conditional on __APPLE_LOCAL_DEPRECATIONS so that end users may still observe them but they are hidden from normal compilations. Signed-off-by: Iain Sandoe PR target/107568 fixincludes/ChangeLog: * fixincl.x: Regenerate. * inclhack.def: Add a fix for MacOS13 SDK function deprecations in stdio.h. * tests/base/stdio.h (__deprecated_msg): New test.
[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand since r12-5253-g4df7f8c79835d569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #11 from Steven Sun --- (In reply to Andrew Pinski from comment #10) > https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2392 > > "potentially-evaluated". Oh, I realized that, According to the DR 2392 accepted as a DR at the November, 2022 meeting: https://cplusplus.github.io/CWG/issues/2392.html We should not evaluate that expression in the first dimension of `new` anymore. So this is not a bug. This also applys for expressions appearing in requirement-seq of requires-expressions. So surprising! (Correct me if I am wrong)
[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 #5 from Martin Uecker --- Probably related to PR88256
[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 #6 from Martin Uecker --- Actually, I meant PR84305 for C.
[Bug c/107557] [12/13 Regression] ICE -fsanitize=undefined and VLA as argument type to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #5 from Martin Uecker --- This seems similar to PR108423 and I assume the common cause is that the fix for PR84305 did not consider the case of function types with variably modified return type (which are obscure).
[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 --- Comment #12 from Andrew Pinski --- This is just a latent bug exposed by Richi's copyprop improvement. Folding statement: ivtmp_37 = ivtmp_38 - 1; gimple_simplified to ivtmp_37 = 1; Folded into: ivtmp_37 = 1; Folding statement: if (ivtmp_37 != 0) Not folded While trunk (GCC 13): Folding statement: ivtmp_9 = ivtmp_39 - 1; Queued stmt for removal. Folds to: 1 Folding statement: if (ivtmp_9 != 0) gimple_simplified to if (1 != 0) Folded into: if (1 != 0) Which is the correct thing to do and removes an branch earlier. Which then removes a few extra loops. Except now LOOP_DIST_ALIAS is not conditionalizing two loops any more.
[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 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #1 from Jeffrey A. Law --- Created attachment 54325 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54325&action=edit Testcase for c6x
[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 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2023-01-21 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Jeffrey A. Law --- I'm seeing this for c6x as well building libgcc. Testcase attached, compile with -O2 -g.
[Bug target/30527] Use of input/output operands in __asm__ templates not fully documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527 Nate Eldredge changed: What|Removed |Added CC||nate at thatsmathematics dot com --- Comment #8 from Nate Eldredge --- For arm/aarch64 in particular, there is an extra wrinkle, which is that armclang *does* support and document the template modifiers. See https://developer.arm.com/documentation/100067/0610/armclang-Inline-Assembler/Inline-assembly-template-modifiers?lang=en. As best I can tell, they are exactly the same as what gcc already supports (undocumentedly). So that makes this into a compatibility issue. People may be writing code for armclang using the modifiers, and then want to build with gcc instead. In practice it will work fine, but from the gcc docs, you wouldn't know it. On these targets, some of the modifiers are pretty important, and there are fairly basic things that you simply can't do without them. For example, on aarch64, the b/h/s/d/q modifiers to get the names of various scalar pieces of a vector register (v15 -> b15 / h15 / s15 / d15 / q15). It's just impossible to write any scalar floating-point asm without this, or SIMD code using the "across vector" instructions like ADDV which need a scalar output operand. Or, the c modifier to suppress the leading # on an immediate. This one is documented for x86, where the need for it is similarly obvious, but no indication in the docs that it works on arm/aarch64 as well. I really do think it would be a good idea for these to become officially supported and documented by gcc, at least for these targets.
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 --- Comment #14 from CVS Commits --- The releases/gcc-12 branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:6d307fda2b9ba71fe18f1449f7444bed7ff05193 commit r12-9055-g6d307fda2b9ba71fe18f1449f7444bed7ff05193 Author: Jerry DeLisle Date: Sat Jan 21 14:58:05 2023 -0800 Backported from master: PR fortran/106731 gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_auto_array_allocation): Remove gcc_assert (!TREE_STATIC()). gcc/testsuite/ChangeLog: * gfortran.dg/pr106731.f90: New test.
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Jerry DeLisle --- Backport complete, closing.
[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595 --- Comment #11 from CVS Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:48f544ad5c98b668d8d345eaafcf09cc0bd44635 commit r13-5276-g48f544ad5c98b668d8d345eaafcf09cc0bd44635 Author: Jerry DeLisle Date: Sat Jan 21 15:19:57 2023 -0800 fortran: [PR102595] PR fortran/102595 gcc/fortran/ChangeLog: * data.cc (gfc_assign_data_value): Remove check for PARAMETER in DATA. * primary.cc (match_variable): Add check for PARAMETER in DATA. gcc/testsuite/ChangeLog: * gfortran.dg/pr88048.f90: Adjust for changed error message. * gfortran.dg/parameter_data0.f90: New test.
[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 #4 from Jonathan Wakely --- That's because iota_view's iterator is only an input iterator in gcc-10, as a result of r10-9796-g1cb39945993c89
[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 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100070 Keywords|needs-bisection | --- Comment #5 from Jonathan Wakely --- See https://cplusplus.github.io/LWG/issue3291 for the rationale. See PR 100070 for suggestions to deal with such iterators better.
[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 #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > That's because iota_view's iterator is only an input iterator in gcc-10, I meant to say gcc-10.4 there.
[Bug modula2/102343] gm2/cpp/pass/subaddr.mod FAILs for non-default multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102343 Iain Sandoe changed: What|Removed |Added Attachment #54289|0 |1 is obsolete|| --- Comment #3 from Iain Sandoe --- Created attachment 54326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54326&action=edit Patch to be posted this patch is candidate for posting - see changelog entry.
[Bug libstdc++/108490] New: circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490 Bug ID: 108490 Summary: circle compiler support for libstdc++ Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- libstdc++ does not work correctly for circle compiler. do not know whether you can fix it. https://www.circle-lang.org/ an object cannot be the target of a friend-declaration operator== [[nodiscard]] (const common_iterator& __x, ^ declaration: /home/cqwrteur/toolchains/native/native/include/c++/13.0.0/bits/max_size_type.h:774:28 during parsing of std::numeric_limits::digits initializer static constexpr int digits ^ error: /home/cqwrteur/toolchains/native/native/include/c++/13.0.0/ext/numeric_traits.h:64:7
[Bug ipa/105438] [11/12/13 Regression] Incorrect array-bounds warning with array size carried over from a previous template instantiation since r11-4987-g602c6cfc79ce4ae6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438 --- Comment #10 from Bernie Innocenti --- Still present on GCC 12.2. Could someone look into it please, or point me at the point in ipa-icf.cc where the array-bounds analysis information should have been updated after merging the template instantiations?
[Bug libstdc++/108490] circle compiler support for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490 --- Comment #1 from Andrew Pinski --- This seems like a bug in circle ...
[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 #7 from MARK BOURGEAULT --- >> See PR 100070 for suggestions to deal with such iterators better. Unless I'm missing something, there's nothing in that PR that a *user* can do to achieve the gcc 10.3 performance w/ std::iota_view.
