[Bug libstdc++/100900] New: error: missing 'typename' prior to dependent type name in elements_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100900 Bug ID: 100900 Summary: error: missing 'typename' prior to dependent type name in elements_view Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com Target Milestone: --- clang++ complains: /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/ranges:3392:19: error: missing 'typename' prior to dependent type name 'iterator_traits>::iterator_category' using _Cat = iterator_traits>::iterator_category;
[Bug tree-optimization/13563] if-conversion not agressive enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13563 Andrew Pinski changed: What|Removed |Added Depends on||56223 --- Comment #7 from Andrew Pinski --- I will be solving this one and the patch will depend on the patch set that fixes PR 56223 (well depends on part of that patch set). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56223 [Bug 56223] Integer ABS is not recognized for more complicated pattern
[Bug tree-optimization/13563] if-conversion not agressive enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13563 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Andrew Pinski --- Mine.
[Bug tree-optimization/56223] Integer ABS is not recognized for more complicated pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56223 --- Comment #6 from Andrew Pinski --- Created attachment 50925 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50925&action=edit Patch which starts to fix this This is step 1 in fixing this bug, there are two or three more steps/patches.
[Bug tree-optimization/56223] Integer ABS is not recognized for more complicated pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56223
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #5 from Andrew Pinski ---
I have a start to this, though it needs to be fixed. It only works for the
following extra case now:
int f(int a, int b, int c)
{
int d0, d1, d;
d1 = __builtin_abs(b);
if (a) {
d0 = __builtin_abs(c);
d = d0;
} else {
d = d1;
}
return d;
}
I also noticed that factor_out_conditional_conversion has a similar issue where
the cast is inside both if and else part.
[Bug c++/100899] internal compiler error: in retrieve_specialization, at cp/pt.c:1240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100899 Hans Erickson changed: What|Removed |Added CC||hans.p.erickson at gmail dot com --- Comment #1 from Hans Erickson --- Created attachment 50924 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50924&action=edit Source code for regression testing (if useful)
[Bug c++/100899] New: internal compiler error: in retrieve_specialization, at cp/pt.c:1240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100899 Bug ID: 100899 Summary: internal compiler error: in retrieve_specialization, at cp/pt.c:1240 Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hans.p.erickson at gmail dot com Target Milestone: --- Created attachment 50923 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50923&action=edit Preprocessed output Some template code that I am working on causes an internal compiler error with the gcc 10 series of compilers. Based on some experimentation with the Compiler Explorer site at godbolt.org it appears that this affects 10.1, 10.2, and 10.3, but doesn't affect version 9 compilers or version 11 compilers. The link to the code at godbolt.org is https://godbolt.org/z/svWW5Tq4r . The pre-processor output that I've attached is from 10.2. The attached output is from a compiler with the following properties: gcc version 10.2.0 (GCC) Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/hans/.local --enable-multilib
[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 --- Comment #19 from Patrick Palka --- Candidate patch that addresses the ICE in the original testcase and reductions: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571899.html
[Bug c/100898] New: ICE with -O2: in gimple_call_arg_ptr, at gimple.h:3264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100898
Bug ID: 100898
Summary: ICE with -O2: in gimple_call_arg_ptr, at gimple.h:3264
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.6GNjkccaVE-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210603 (experimental) [master revision
:fe23f36c0:9663c744e2d0942f14eafa725a1bd9f766f02a16] (GCC)
$ cat mutant.c
a;
fn1() {
for (; a;)
return bar(__builtin_va_arg_pack());
}
main() { fn1(); }
$ gcc-trunk -O2 mutant.c
mutant.c:1:1: warning: data definition has no type or storage class
1 | a;
| ^
mutant.c:1:1: warning: type defaults to ‘int’ in declaration of ‘a’
[-Wimplicit-int]
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | fn1() {
| ^~~
mutant.c: In function ‘fn1’:
mutant.c:4:12: warning: implicit declaration of function ‘bar’
[-Wimplicit-function-declaration]
4 | return bar(__builtin_va_arg_pack());
|^~~
mutant.c: At top level:
mutant.c:6:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
6 | main() { fn1(); }
| ^~~~
during IPA pass: inline
In function ‘fn1’:
cc1: internal compiler error: in gimple_call_arg_ptr, at gimple.h:3264
0x758b10 gimple_call_arg_ptr
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/gimple.h:3264
0x758b10 gimple_call_arg_ptr
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/gimple.h:3262
0x758b10 copy_bb
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/tree-inline.c:2085
0xf93522 copy_cfg_body
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/tree-inline.c:3022
0xf93522 copy_body
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/tree-inline.c:3278
0xf96a56 expand_call_inline
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/tree-inline.c:5105
0xf98109 gimple_expand_calls_inline
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/tree-inline.c:5300
0xf98109 optimize_inline_calls(tree_node*)
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/tree-inline.c:5473
0xcbf76b inline_transform(cgraph_node*)
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/ipa-inline-transform.c:790
0xe19e04 execute_one_ipa_transform_pass
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/passes.c:2290
0xe19e04 execute_all_ipa_transforms(bool)
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/passes.c:2337
0xa874a9 cgraph_node::expand()
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/cgraphunit.c:1821
0xa888cf expand_all_functions
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/cgraphunit.c:1992
0xa888cf symbol_table::compile()
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/cgraphunit.c:2356
0xa8b7cb symbol_table::compile()
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/cgraphunit.c:2269
0xa8b7cb symbol_table::finalize_compilation_unit()
/tmp/tmp.6GNjkccaVE-gcc-builder/gcc/gcc/cgraphunit.c:2537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 Patrick Palka changed: What|Removed |Added CC||mu11 at yahoo dot com --- Comment #18 from Patrick Palka --- *** Bug 100599 has been marked as a duplicate of this bug. ***
[Bug c++/100599] ICE in tree check: accessed elt 2 of ‘tree_vec’ with 1 elts in tsubst, at cp/pt.c:15649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100599 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Looks like this is essentially a dup of PR100102 *** This bug has been marked as a duplicate of bug 100102 ***
[Bug tree-optimization/56223] Integer ABS is not recognized for more complicated pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56223 --- Comment #4 from Andrew Pinski --- Note factor_out_conditional_conversion is a special case comment #3 really.
[Bug tree-optimization/56223] Integer ABS is not recognized for more complicated pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56223
--- Comment #3 from Andrew Pinski ---
There are ways of handling this case. I think the second one is better than
the first. The first is mentioned here.
The second would take:
if (a) {
foo();
b = d + e;
} else {
goo();
b = d -e;
}
and replace it with:
if (a) {
foo();
t = e;
} else {
goo();
t = -e;
}
b = d + t;
And then because in the original case foo and goo were non-existant, PHI-OPT
would replace the if statement with:
t = abs(e);
b = d + t;
[Bug target/80636] AVX / AVX512 register-zeroing should always use AVX 128b, not ymm or zmm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80636
Peter Cordes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Peter Cordes ---
This seems to be fixed for ZMM vectors in GCC8.
https://gcc.godbolt.org/z/7351be1v4
Seems to have never been a problem for __m256, at least not for
__m256 zero256(){ return _mm256_setzero_ps(); }
IDK what I was looking at when I originally reported; maybe just clang which
*did* used to prefer YMM-zeroing.
Some later comments suggested movdqa vs. pxor zeroing choices (and mov vs. xor
for integer), but the bug title is just AVX / AVX-512 xor-zeroing, and that
seems to be fixed. So I think this should be closed.
[Bug target/70387] -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387 Andrew Pinski changed: What|Removed |Added Component|c++ |target Target|i586-pc-msdosdjgpp |djgpp Severity|normal |enhancement Status|WAITING |NEW --- Comment #6 from Andrew Pinski --- (In reply to jwjagersma from comment #4) > Created attachment 38096 [details] > Test case 2 > > Generic test case, which doesn't require djgpp or a DOS machine. (Assuming > throwing from inline asm is similar enough) > > compile with: > "g++ -std=gnu++14 -fnon-call-exceptions throw_from_asm.cpp" Yes GCC adds no unwind info and it is hard to do from an inline-asm since GCC has no information on what the inline-asm could do. So that part is more of a documentation rather than anything else there. As far as the other one, throwing from an interrupt in DOS requires you have to have a MD_FALLBACK_FRAME_STATE_FOR defined which is not done for djgpp and would need to be custom for your interrupt handler. I don't know the best way forward for this really except to say there is not much to be done here unless someone steps up and adds interrupt handler support to djgpp and then adds throwing through the interrupt handler support too.
[Bug testsuite/28123] gcc.dg/cpp/_Pragma3.c is sensitive to timestamps when using from git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28123
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|NEW
Last reconfirmed|2006-06-21 15:02:45 |2021-6-3
Summary|gcc.dg/cpp/_Pragma3.c is|gcc.dg/cpp/_Pragma3.c is
|sensitive to timestamps |sensitive to timestamps
||when using from git
--- Comment #7 from Andrew Pinski ---
The released tar file will always be correct:
# Run gcc_update on them to set up the timestamps nicely, and (re)write
# the LAST_UPDATED file containing the git tag/revision used.
changedir "gcc-${RELEASE}"
contrib/gcc_update --touch
echo "Obtained from git: ${GITBRANCH} revision ${GITREV}" > LAST_UPDATED
So this is more about only when building from git.
[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
--- Comment #17 from Patrick Palka ---
Reduced valid reproducer:
template struct ratio;
template struct duration {
static constexpr int _S_gcd();
template using __is_harmonic = ratio<_S_gcd>;
using type = __is_harmonic;
};
[Bug target/100841] xtensa-linux: dwarf2cfi.c:291:12: error: comparison of integer expressions of different signedness: 'const unsigned int' and 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100841 Jan-Benedict Glaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan-Benedict Glaw --- Fixed by Jakub Jelinek.
[Bug target/100841] xtensa-linux: dwarf2cfi.c:291:12: error: comparison of integer expressions of different signedness: 'const unsigned int' and 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100841 --- Comment #4 from Jan-Benedict Glaw --- Builds now. Thanks a lot!
[Bug c++/100897] New: Symmetric transfer does not prevent stack-overflow for C++20 coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100897
Bug ID: 100897
Summary: Symmetric transfer does not prevent stack-overflow for
C++20 coroutines
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: l.v.merzljak at gmail dot com
Target Milestone: ---
Although the following code uses symmetric transfer, it crashes due to a
stack-overflow. The crash is also reproducible when using the task<> type of
the cppcoro library. The crash does not occur when using clang.
```
// main.cc
#include
#include
class Task {
public:
struct promise_type {
Task get_return_object() { return Handle::from_promise(*this); }
struct FinalAwaitable {
bool await_ready() const noexcept { return false; }
// Use symmetric transfer. Resuming coro.promise().m_continuation should
// not require extra stack space
std::coroutine_handle<> await_suspend(
std::coroutine_handle coro) noexcept {
if (coro.promise().m_continuation) {
return coro.promise().m_continuation;
} else {
// The top-level task started from within main() does not have a
// continuation. This will give control back to the main function.
return std::noop_coroutine();
}
}
void await_resume() noexcept {}
};
std::suspend_always initial_suspend() noexcept { return {}; }
FinalAwaitable final_suspend() noexcept { return {}; }
void unhandled_exception() noexcept { std::terminate(); }
void set_continuation(std::coroutine_handle<> continuation) noexcept {
m_continuation = continuation;
}
void return_void() noexcept {}
private:
std::coroutine_handle<> m_continuation;
};
using Handle = std::coroutine_handle;
Task(Handle coroutine) : m_coroutine(coroutine) {}
~Task() {
if (m_coroutine) {
m_coroutine.destroy();
}
}
void start() noexcept { m_coroutine.resume(); }
auto operator co_await() const noexcept { return Awaitable{m_coroutine}; }
private:
struct Awaitable {
Handle m_coroutine;
Awaitable(Handle coroutine) noexcept : m_coroutine(coroutine) {}
bool await_ready() const noexcept { return false; }
// Use symmetric transfer. Resuming m_coroutine should not require extra
// stack space
std::coroutine_handle<> await_suspend(
std::coroutine_handle<> awaitingCoroutine) noexcept {
m_coroutine.promise().set_continuation(awaitingCoroutine);
return m_coroutine;
}
void await_resume() {}
};
Handle m_coroutine;
};
Task inner() { co_return; }
Task outer() {
// Use large number of iterations to trigger stack-overflow
for (int i = 0; i != 5000; ++i) {
co_await inner();
}
}
int main() {
auto task = outer();
task.start();
}
```
I compile the code with `g++-11 main.cc -std=c++20 -O3 -fsanitize=address`.
Here is the output:
```
$ ./a.out
AddressSanitizer:DEADLYSIGNAL
=
==21002==ERROR: AddressSanitizer: stack-overflow on address 0x7fffc666dff8 (pc
0x7f6ec2dfa16d bp 0x7fffc666e870 sp 0x7fffc666e000 T0)
#0 0x7f6ec2dfa16d in __sanitizer::BufferedStackTrace::UnwindImpl(unsigned
long, unsigned long, void*, bool, unsigned int)
../../../../src/libsanitizer/asan/asan_stack.cpp:57
#1 0x7f6ec2df00eb in __sanitizer::BufferedStackTrace::Unwind(unsigned long,
unsigned long, void*, bool, unsigned int)
../../../../src/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:122
#2 0x7f6ec2df00eb in operator delete(void*)
../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
#3 0x560193552e57 in _Z5innerv.destroy(inner()::_Z5innerv.frame*)
(/home/leonard/Desktop/hiwi/async_io_uring/stack-overflow/a.out+0x1e57)
#4 0x560193553b30 in _Z5outerv.actor(outer()::_Z5outerv.frame*)
(/home/leonard/Desktop/hiwi/async_io_uring/stack-overflow/a.out+0x2b30)
#5 0x560193552bbb in _Z5innerv.actor(inner()::_Z5innerv.frame*)
(/home/leonard/Desktop/hiwi/async_io_uring/stack-overflow/a.out+0x1bbb)
...
```
[Bug target/100896] New: --enable-initfini-array should be enabled for cross compiler to Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100896 Bug ID: 100896 Summary: --enable-initfini-array should be enabled for cross compiler to Linux Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- --enable-initfini-array should be enabled for cross compiler to all *-*-linux* and *-*-gnu* targets.
[Bug target/43892] PowerPC suboptimal "add with carry" optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892 --- Comment #35 from Segher Boessenkool --- You get something like .L5: lwzu 9,4(10) addc 8,3,9 adde 3,9,3 bdnz .L5
[Bug target/100637] [i386] Vectorize 4-byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637 --- Comment #8 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:5883e567564c5b3caecba0c13e8a360a14cdc846 commit r12-1197-g5883e567564c5b3caecba0c13e8a360a14cdc846 Author: Uros Bizjak Date: Thu Jun 3 20:05:31 2021 +0200 i386: Add insert and extract patterns for 4-byte vectors [PR100637] The patch introduces insert and extract patterns for 4-byte vectors. It effectively only emits PINSR and PEXTR instructions when available, otherwise falls back to generic code that emulates these instructions via inserts, extracts, logic operations and shifts in integer registers. Please note that generic fallback produces better code than the current approach of constructing new vector in memory (due to store forwarding stall) so also enable QImode 8-byte vector inserts only with TARGET_SSE4_1. 2021-06-03 Uroš Bizjak gcc/ PR target/100637 * config/i386/i386-expand.c (ix86_expand_vector_set): Handle V2HI and V4QI modes. (ix86_expand_vector_extract): Ditto. * config/i386/mmx.md (*pinsrw): New insn pattern. (*pinsrb): Ditto. (*pextrw): Ditto. (*pextrw_zext): Ditto. (*pextrb): Ditto. (*pextrb_zext): Ditto. (vec_setv2hi): New expander. (vec_extractv2hihi): Ditto. (vec_setv4qi): Ditto. (vec_extractv4qiqi): Ditto. (vec_setv8qi): Enable only for TARGET_SSE4_1. (vec_extractv8qiqi): Ditto. gcc/testsuite/ PR target/100637 * gcc.target/i386/vperm-v2hi.c: New test. * gcc.target/i386/vperm-v4qi.c: Ditto.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #226 from dave.anglin at bell dot net --- John, would you please post your full patch set for ia64-hpux? This will help others.
[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 --- Comment #16 from Jonathan Wakely --- This is an old, latent g++ bug, but it now makes it impossible to use cuda with GCC (e.g. on Fedora) because of my libstdc++ changes. I will see if I can make another libstdc++ change to avoid the ICE without having to revert the change completely, as it was done to fix a non-conformance bug.
[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 --- Comment #15 from Jonathan Wakely --- (In reply to Erik Schnetter from comment #6) > I looked for the string "GCC" in the user header files, but could not find > any place where things would differ between GCC 10.2 and 10.3. I assume > there could be a difference in GCC-provided header files (the error message > mentions "chrono" and "gcd"), or it could be that nvcc examines the GCC > version and produces different code. The difference is r10-9609-g14f8307cf4261efd5ee4475b3c7f7c42c48557d6 in the header, which is in 10.3 and not 10.2
[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102
--- Comment #14 from Jonathan Wakely ---
cvised reproducer from PR 100448
template using __bool_constant struct intmax_t;
template struct ratio {
template struct duration {
static intmax_t _S_gcd();
template
using __is_harmonic =
__bool_constant::den>;
class _Period2 __is_harmonic<_Period2>
[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 Jonathan Wakely changed: What|Removed |Added CC||alexander.grund@tu-dresden. ||de --- Comment #13 from Jonathan Wakely --- *** Bug 100448 has been marked as a duplicate of this bug. ***
[Bug c++/100448] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100448 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- dup of PR 100102 then *** This bug has been marked as a duplicate of bug 100102 ***
[Bug c++/100895] New: gcc accepts invalid template argument in partial template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100895
Bug ID: 100895
Summary: gcc accepts invalid template argument in partial
template specialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
template
using type = int;
template
constexpr bool value = true;
template
struct S {};
template
struct S>> {};
S s;
https://godbolt.org/z/GebosdTrM
[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 Jonathan Wakely changed: What|Removed |Added CC||bowie.owens at gmail dot com --- Comment #12 from Jonathan Wakely --- *** Bug 100277 has been marked as a duplicate of this bug. ***
[Bug c++/100277] ICE on cuda host code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100277 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- Looks like a dup *** This bug has been marked as a duplicate of bug 100102 ***
[Bug libstdc++/100770] Incorrect if constexpr statement in ranges::unique_copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100770 --- Comment #2 from Patrick Palka --- Fixed on trunk so far by r12-1195: Author: Patrick Palka Date: Thu, 3 Jun 2021 12:30:29 -0400 libstdc++: Avoid hard error in ranges::unique_copy [PR100770] Here, in the constexpr if condition within ranges::unique_copy, when input_iterator<_Out> isn't satisfied we must avoid substituting into iter_value_t<_Out> because the latter isn't necessarily well-formed then. To that end, this patch factors out the condition into a concept and uses it throughout. This patch also makes the definition of our testsuite output_iterator_wrapper more minimal by setting its value_type, pointer and reference member types to void. This means our existing tests for unique_copy already exercise the fix for this bug, so we don't need to add another test. The only other fallout of this testsuite iterator change appears in std/ranges/range.cc, where the use of range_value_t on a test_output_range is now ill-formed. libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__detail::__can_reread_output): Factor out this concept from ... (__unique_copy_fn::operator()): ... here. Use the concept throughout. * testsuite/std/ranges/range.cc: Remove now ill-formed use of range_value_t on an output_range. * testsuite/util/testsuite_iterators.h (output_iterator_wrapper): Define value_type, pointer and reference member types to void.
[Bug libstdc++/100894] New: The std::common_reference implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100894
Bug ID: 100894
Summary: The std::common_reference implementation seems to be
wrong
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
In [meta#trans.other-6.3.1], the standard specifies "If T1 and T2 are reference
types and COMMON-REF(T1, T2) is well-formed, then the member typedef type
denotes that type", where COMMON-REF is defined in [meta#trans.other-3.5]: "If
A and B are both lvalue reference types, COMMON-REF(A, B) is COND-RES(COPYCV(X,
Y) &, COPYCV( Y, X) &) if that type exists and is a reference type."
libstdc++ does not check that COMMON-REF(A, B) must be a reference type, which
will lead to incorrect determination of the common reference type according to
bullet 1 in the following cases.
https://godbolt.org/z/7Mc7jjesK
#include
struct A {};
struct B { B(A); };
static_assert(
std::same_as<
std::common_reference_t, B>);
[Bug fortran/86694] gfortran rejects character parameter binding label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86694 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- Adding my text from the duplicate bug report. Interesting bug. gfortran tries to reduce the constant expression to a constant during the parse phase. This reduction occurs too early and needs to be moved to the resolution phase. In particular, decl.c:8052-8123 need to change/move to someplace in resolve.c where the host namespace can be resolved to accommodate the import statement. Good Luck and happy hacking.
[Bug fortran/86694] gfortran rejects character parameter binding label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86694 kargl at gcc dot gnu.org changed: What|Removed |Added CC||ehlert at thch dot uni-bonn.de --- Comment #2 from kargl at gcc dot gnu.org --- *** Bug 100870 has been marked as a duplicate of this bug. ***
[Bug fortran/100870] Constant expression for bind(C) name in interface body not importable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100870 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from kargl at gcc dot gnu.org --- Interesting bug. gfortran tries to reduce the constant expression to a constant during the parse phase. This reduction occurs too early and needs to be moved to the resolution phase. In particular, decl.c:8052-8123 need to change/move to someplace in resolve.c where the host namespace can be resolved to accommodate the import statement. Good Luck and happy hacking. *** This bug has been marked as a duplicate of bug 86694 ***
[Bug c++/100893] Template argument conversion fails for dependant constant function pointer template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100893 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-03 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Patrick Palka --- Confirmed, this never worked it seems.
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 --- Comment #10 from H.J. Lu --- (In reply to seurer from comment #9) > > seurer@gcc1-power7:~/gcc/git/build/gcc-test$ grep .rodata attr-retain-1.s > .string "used_rodata2" > .string "unused_rodata" > .string "used_rodata" > .globl used_rodata2 > .globl unused_rodata > .globl used_rodata > .type unused_rodata, @object > .size unused_rodata, 4 > unused_rodata: > .section.sdata.used_rodata,"awR" ^ used_rodata is in a writable section. Is this intentional? -m64 generates .section.rodata.used_rodata,"aR" .align 2 .type used_rodata, @object .size used_rodata, 4 used_rodata: .long 2 which looks correct. If it is intentional, test should exclude -m32 for powerpc64-linux-gnu. > .type used_rodata, @object > .size used_rodata, 4 > used_rodata: > .section.sdata.used_rodata2,"awR" > .type used_rodata2, @object > .size used_rodata2, 4 > used_rodata2:
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 --- Comment #9 from seurer at gcc dot gnu.org --- Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/compile/attr-retain-1.c -fdiagnostics-plain-output -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -w -ffat-lto-objects -fno-ident -S -m32 -o attr-retain-1.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/compile/attr-retain-1.c -fdiagnostics-plain-output -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -w -ffat-lto-objects -fno-ident -S -m32 -o attr-retain-1.s PASS: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) PASS: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .text.*,"axR" PASS: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .bss.*,"awR" PASS: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .data.*,"awR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .rodata.*,"aR" PASS: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .data.used_foo_sec,"awR" seurer@gcc1-power7:~/gcc/git/build/gcc-test$ /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/compile/attr-retain-1.c -fdiagnostics-plain-output -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -w -ffat-lto-objects -fno-ident -S -m32 -o attr-retain-1.s seurer@gcc1-power7:~/gcc/git/build/gcc-test$ grep .rodata attr-retain-1.s .string "used_rodata2" .string "unused_rodata" .string "used_rodata" .globl used_rodata2 .globl unused_rodata .globl used_rodata .type unused_rodata, @object .size unused_rodata, 4 unused_rodata: .section.sdata.used_rodata,"awR" .type used_rodata, @object .size used_rodata, 4 used_rodata: .section.sdata.used_rodata2,"awR" .type used_rodata2, @object .size used_rodata2, 4 used_rodata2:
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 --- Comment #8 from seurer at gcc dot gnu.org --- Created attachment 50922 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50922&action=edit assembler file
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-03 Ever confirmed|0 |1
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 Jonathan Wakely changed: What|Removed |Added Target Milestone|11.2|10.4 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #20 from Jonathan Wakely --- Fixed for 10.4 and 11.2, I'm not going to backport it to gcc-9.
[Bug libstdc++/100768] Range iterator operations should be function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100768 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |10.4 --- Comment #4 from Jonathan Wakely --- Fixed for 10.4 and 11.2
[Bug libstdc++/100833] ranges::advance should return n when i == bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100833 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 10.4 and 11.2
[Bug libstdc++/100833] ranges::advance should return n when i == bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100833 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:753c8680a46d371e179ff1ade36002486361095e commit r10-9887-g753c8680a46d371e179ff1ade36002486361095e Author: Jonathan Wakely Date: Tue Jun 1 16:02:45 2021 +0100 libstdc++: Fix return value of std::ranges::advance [PR 100833] The three-argument form of ranges::advance is supposed to return the difference between the second argument and the distance the iterator was advanced. When a non-random-access iterator is not advanced (because it already equals the sentinel) we were returning 0 rather than n - 0. libstdc++-v3/ChangeLog: PR libstdc++/100833 * include/bits/range_access.h (ranges::advance(iter, n, sentinel)): Fix return value for no-op case. * testsuite/24_iterators/range_operations/advance.cc: Test return values of three-argument overload. (cherry picked from commit d8326291695c0f13124c232ddf4fd34e3310e649)
[Bug libstdc++/100768] Range iterator operations should be function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100768 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e01562b302eae3d415b43a4efe7ce52cff3e0063 commit r10-9886-ge01562b302eae3d415b43a4efe7ce52cff3e0063 Author: Jonathan Wakely Date: Wed May 26 17:32:53 2021 +0100 libstdc++: Change [range.iter.op] functions to function objects [PR 100768] The standard specifies std::ranges::distance etc as function templates, but it also requires them to not be found by ADL, and to suppress ADL when normal unqualified lookup does find them. That means they need to be function objects. libstdc++-v3/ChangeLog: PR libstdc++/100768 * include/bits/range_access.h (ranges::advance) (ranges::distance, ranges::next, ranges::prev): Replace function templates with function objects. * testsuite/24_iterators/headers/iterator/synopsis_c++20.cc: Adjust for changes to function objects. * testsuite/std/ranges/adaptors/elements.cc: Add using declarations for names from namespace ranges. * testsuite/std/ranges/adaptors/transform.cc: Likewise. * testsuite/24_iterators/range_operations/100768.cc: New test. (cherry picked from commit a49a045b92f982f5617c3bbde97a33157237e25b)
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 --- Comment #19 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a937d0269c1202326a74965329159d90f176438a commit r10-9885-ga937d0269c1202326a74965329159d90f176438a Author: Jonathan Wakely Date: Tue Jun 1 11:00:16 2021 +0100 libstdc++: Fix installation of python hooks [PR 99453] When no shared library is installed, the new code to determine the name of the -gdb.py file yields an empty string. Use the name of the static library in that case. libstdc++-v3/ChangeLog: PR libstdc++/99453 * python/Makefile.am: Use archive name for printer hook if no dynamic library name is available. * python/Makefile.in: Regenerate. (cherry picked from commit 9f7bc160b4a0f27dce248d1226e3ae7104b0e67b)
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 --- Comment #18 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5b4b18b892278380cdb303c097466009914b828e commit r10-9884-g5b4b18b892278380cdb303c097466009914b828e Author: Philippe Blain Date: Fri Mar 12 19:26:46 2021 -0500 libstdc++: Install libstdc++*-gdb.py more robustly [PR 99453] In order for GDB to auto-load the pretty printers, they must be installed as "libstdc++.$ext-gdb.py", where 'libstdc++.$ext' is the name of the object file that is loaded by GDB [1], i.e. the libstdc++ shared library. The approach taken in libstdc++-v3/python/Makefile.am is to loop over files matching 'libstdc++*' in $(DESTDIR)$(toolexeclibdir) and choose the last file matching that glob that is not a symlink, the Libtool '*.la' file or a Python file. That works fine for ELF targets where the matching names are: libstdc++.a libstdc++.so libstdc++.so.6 libstdc++.so.6.0.29 But not for macOS with: libstdc++.6.dylib libstdc++.a Or MinGW with: libstdc++-6.dll libstdc++.dll.a Try to make a better job at installing the pretty printers with the correct name by copying the approach taken by isl [2], that is, using a sed invocation on the Libtool-generated 'libstdc++.la' to read the correct name for the current platform. [1] https://sourceware.org/gdb/onlinedocs/gdb/objfile_002dgdbdotext-file.html [2] https://repo.or.cz/isl.git/blob/HEAD:/Makefile.am#l611 libstdc++-v3/ChangeLog: PR libstdc++/99453 * python/Makefile.am: Install libstdc++*-gdb.py more robustly. * python/Makefile.in: Regenerate. Co-authored-by: Jonathan Wakely (cherry picked from commit c2fc1702cb3a3d5cc9c40de47f63b4c8f3f1d09c)
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #8 from Dominique d'Humieres --- > So gnu is indeed faster for real(8), but the result was changed. What OS are you using? In any sensible library REAL(4° should be faster than REAL(8). > notice the result was also changed REAL(4): 33554432.0 REAL(8): 150945570.07620683 REAL(16): 150945570.075233660889594015556531239 I did not do a full numerical analysis, but it is known that SUM is very limited for REAL(4).
[Bug fortran/100892] ICE on procedure pointer to function returning array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100892 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2021-06-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, an old bug (at least 4.8.0).
[Bug libstdc++/100577] [11/12 Regression] Unhelpful diagnostics for ill-formed call to partially applied range adaptor object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100577 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:57ed620ebfa4275d04efeec973e88f506b0e3ba8 commit r12-1184-g57ed620ebfa4275d04efeec973e88f506b0e3ba8 Author: Patrick Palka Date: Thu Jun 3 09:49:30 2021 -0400 libstdc++: Simplify range adaptors' forwarding of bound args [PR100577] r11-8053 rewrote the range adaptor implementation in conformance with P2281R1, making partial application act like a SFINAE-friendly perfect forwarding call wrapper. Making SFINAE-friendliness coexist with perfect forwarding here requires adding fallback deleted operator() overloads (as described in e.g. section 5.5 of P0847R6). But unfortunately, as reported in PR100577, this necessary technique of using of deleted overloads regresses diagnostics for ill-formed calls to partially applied range adaptors in GCC. Although GCC's diagnostics can arguably be improved here by having the compiler explain why the other candidates weren't viable when overload resolution selects a deleted candidate, we can also largely work around this on the library side (and achieve more concise diagnostics than by a frontend-side improvement alone) if we take advantage of the observation that not all range adaptors need perfect forwarding call wrapper semantics, in fact only views::split currently needs it, because all other range adaptors either take no extra arguments or only arguments that are expected to be freely/cheaply copyable, e.g. function objects and integer-like types. (The discussion section in P2281R1 goes into detail about why views::split is special.) To that end, this introduces opt-in flags for denoting a range adaptor as having "simple" extra arguments (in the case of a range adaptor non-closure) or having a "simple" call operator (in the case of a range adaptor closure). These flags are then used to conditionally simplify the operator() for the generic _Partial and _Pipe class templates, down from needing three overloads thereof (including one defined as deleted) to just needing a single overload. The end result is that diagnostic quality is restored for all adaptors except for views::split, and diagnostics for the adaptors are generally made more concise since there's only a single _Partial/_Pipe overload to diagnose instead of three of them. libstdc++-v3/ChangeLog: PR libstdc++/100577 * include/std/ranges (_RangeAdaptorClosure): Document _S_has_simple_call_op mechanism. (_RangeAdaptor): Document _S_has_simple_extra_args mechanism. (__closure_has_simple_call_op): New concept. (__adaptor_has_simple_extra_args): Likewise. (_Partial<_Adaptor, _Args...>): New partial specialization. (_Partial<_Adaptor, _Arg>): Likewise. (_Pipe<_Lhs, _Rhs>): Likewise. (views::_All::_S_has_simple_call_op): Define to true. (views::_Filter::_S_has_simple_extra_args): Likewise. (views::_Transform::_S_has_simple_extra_args): Likewise. (views::_Take::_S_has_simple_extra_args): Likewise. (views::_TakeWhile::_S_has_simple_extra_args): Likewise. (views::_Drop::_S_has_simple_extra_args): Likewise. (views::_DropWhile::_S_has_simple_extra_args): Likewise. (views::_Join::_S_has_simple_call_op): Likewise. (views::_Split): Document why we don't define _S_has_simple_extra_args to true for this adaptor. (views::_Common::_S_has_simple_call_op): Define to true. (views::_Reverse::_S_has_simple_call_op): Likewise. (views::_Elements::_S_has_simple_call_op): Likewise. * testsuite/std/ranges/adaptors/100577.cc: New test.
[Bug c++/100592] Bogus "qualifiers cannot be applied" error with reference type produced by dependent alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100592 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d999d9b7e53b9a9cd2004a19e84c637e5e5013f5 commit r12-1183-gd999d9b7e53b9a9cd2004a19e84c637e5e5013f5 Author: Patrick Palka Date: Thu Jun 3 09:39:13 2021 -0400 c++: cv-qualified dependent name of alias tmpl [PR100592] Here, the dependent template name in the return type of f() resolves to an alias of int& after substitution, and we end up complaining about qualifying this reference type with 'const' from cp_build_qualified_type rather than just silently dropping the qualification as per [dcl.ref]/1. The problem is ultimately that make_typename_type ignores the tf_keep_type_decl flag when the dependent name is a template-id. This in turn causes the TYPE_DECL check within tsubst to fail, and so we end up not passing tf_ignore_bad_quals to cp_build_qualified_type. This patch fixes this by making make_typename_type respect the tf_keep_type_decl flag in this situation. PR c++/100592 gcc/cp/ChangeLog: * decl.c (make_typename_type): After calling lookup_template_class, adjust the result to its TYPE_NAME and then consider the tf_keep_type_decl flag. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-71.C: New test.
[Bug c++/100862] using enum member access fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100862 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:69f517ac20566a645ff41a9bfca535822205a538 commit r12-1182-g69f517ac20566a645ff41a9bfca535822205a538 Author: Patrick Palka Date: Thu Jun 3 09:37:11 2021 -0400 c++: using-enum and access specifiers [PR100862] When copying the enumerators imported by a class-scope using-enum declaration, we need to override current_access_specifier so that finish_member_declaration gives the copies the same access as the using-enum decl. (A class-scope using-enum is processed late, so current_access_specifier at this point is otherwise set to the last access specifier within the class.) To that end, this patch makes handle_using_decl call set_current_access_from_decl accordingly. For consistency, this patch makes build_enumerator use set_current_access_from_decl too. PR c++/100862 gcc/cp/ChangeLog: * pt.c (set_current_access_from_decl): Move to ... * class.c (set_current_access_from_decl): ... here. (handle_using_decl): Use it to propagate the access of the using-enum decl to the copy of the imported enumerator. * cp-tree.h (set_current_access_from_decl): Declare. * decl.c (build_enumerator): Simplify using make_temp_override and set_current_access_from_decl. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/using-enum-9.C: New test.
[Bug tree-optimization/27109] Simplify "a - 10 > 150" into "a > 160" when range of a is known (in VRP or somewhere else)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #4 from Andrew Macleod --- well, in evrp we now produce: === BB 6 Imports: a_3(D) Exports: _1 a_3(D) _1 : a_3(D)(I) a_3(D) unsigned int [100, 200] : _1 = a_3(D) + 4294967286; if (_1 > 150) goto ; [INV] else goto ; [INV] _1 : unsigned int [90, 190] 6->7 (T) _1 : unsigned int [151, 190] 6->7 (T) a_3(D) : unsigned int [161, 200] 6->8 (F) _1 : unsigned int [90, 150] 6->8 (F) a_3(D) : unsigned int [100, 160] we know its not going to overflow. who or what should make the decision? looks like some sort of simplification or peephole. Also note that you can now find this out from any pass with the range_query infrastructure that Aldy added: at the start of the pass call enable_ranger() for context sensitive info, and then anywhere you can get_range_query()->range_of_expr (r, stmt, name) will get a range. so for the initial stmt 1 = a_3(D) + 4294967286; asking for the range of a_3 on this stmt would give you [100,200] or asking for the range of the stmt (or i_1 in the next statetment) will give you [90,190] Aldy has also implemented an overflow checker for expressions.. not sure it applies to stmts.. yet. If any of this interests you, send him a note. We're still working out user case functionality, so if there is anything else we need to present this kind of info, let us know. I think he's planning to write a guide for this next week. Another option is to work it backwards. given the stmt: # RANGE [90, 190] NONZERO 255 _1 = a_3(D) + 4294967286; range-ops can tell you that if _1 is [90,190] then it can evaluate the expression and solve that a_3 is [100,200].. if that helps. internally it knows if there was a potential overflow, but that isnt exported in any useful way way at the moment.
[Bug c++/100893] New: Template argument conversion fails for dependant constant function pointer template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100893
Bug ID: 100893
Summary: Template argument conversion fails for dependant
constant function pointer template parameters
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlegg at feralinteractive dot com
Target Milestone: ---
When compiling this C++ code:
void f();
struct S {using F = void (* const)();};
template void g() {}
void h() {g();}
GCC 11.1.1, and (much) earlier versions, reject it with:
: In function 'void h()':
:4:19: error: no matching function for call to 'g()'
4 | void h() {g();}
| ^~
:3:45: note: candidate: 'template void g()'
3 | template void g() {}
| ^
:3:45: note: template argument deduction/substitution failed:
:4:16: error: could not convert template argument 'f' from 'void (*)()'
to 'void (* const)()'
4 | void h() {g();}
|^~
My language lawyering isn't good enough to explain why, but I think the
template argument conversion should work, and the compiler should behave as it
does when the const is removed. Similar conversions seem to work if F is a
constant type but not a function pointer, or if the second template parameter
on g is not dependant on the first. MSVC and Clang also accept the example
code.
[Bug target/100887] [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100887 --- Comment #7 from Jakub Jelinek --- Created attachment 50921 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50921&action=edit gcc12-pr100887-2.patch Untested fix for the #c3 ICE.
[Bug target/100703] __vector_pair and __vector_quad cannot be passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100703 Bill Schmidt changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Bill Schmidt --- So, already fixed. Closing.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Jonathan Wakely changed: What|Removed |Added CC||tobi at gcc dot gnu.org --- Comment #41 from Jonathan Wakely --- *** Bug 100891 has been marked as a duplicate of this bug. ***
[Bug c++/100891] #pragma GCC diagnostic ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100891 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- I think this is another dup of PR 53431 *** This bug has been marked as a duplicate of bug 53431 ***
[Bug c++/100877] g++ freezes system by consuming infinite amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100877 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug c/98892] FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98892 Eric Botcazou changed: What|Removed |Added Host|hppa-unknown-linux-gnu | Last reconfirmed||2021-06-03 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Build|hppa-unknown-linux-gnu | Target|hppa-unknown-linux-gnu | --- Comment #1 from Eric Botcazou --- I'm seeing it on x86-64/Linux as well: FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c -fplugin=./diagnostic_plugin_test_tree_expression_range.so 1 blank line(s) in output FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c -fplugin=./diagnostic_plugin_test_tree_expression_range.so expected multiline pattern lines 550-551 not found: " __builtin_types_compatible_p \\(long, int\\) \\+ f \\(i\\)\\);.*\\n ~\\^~~\\n" FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c -fplugin=./diagnostic_plugin_test_tree_expression_range.so (test for excess errors) but it apparently goes away and comes back.
[Bug fortran/100892] New: ICE on procedure pointer to function returning array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100892 Bug ID: 100892 Summary: ICE on procedure pointer to function returning array of size n Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daniel.price at monash dot edu Target Milestone: --- Created attachment 50920 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50920&action=edit test code Attached code shows test case giving ICE on associated(ptr, func) if the function returns an array of size(n), where n is an input to the function: ``` module testmodule implicit none procedure(func1), pointer :: my_ptr => null() contains subroutine test_sub if (associated(my_ptr, func1)) print*,'associated' end subroutine test_sub function func1(n) integer, intent(in) :: n real, dimension(n) :: func1 end function end module testmodule ``` compiling this gives: % gfortran -c test-ice.f90 -o test-ice.o f951: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. Checked with gfortran v11.1.0 via Homebrew on Mac OS: % gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.1.0_1/libexec/gcc/x86_64-apple-darwin20/11.1.0/lto-wrapper Target: x86_64-apple-darwin20 Configured with: ../configure --prefix=/usr/local/Cellar/gcc/11.1.0_1 --libdir=/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran,d --program-suffix=-11 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-zstd=/usr/local/opt/zstd --with-pkgversion='Homebrew GCC 11.1.0_1' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-libphobos --build=x86_64-apple-darwin20 --with-system-zlib --disable-multilib --without-build-config --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (Homebrew GCC 11.1.0_1) Cheers, Daniel
[Bug ipa/99122] [10 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #37 from CVS Commits --- The releases/gcc-11 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:8b1190d527d01dc74ee53e47b0366d01270c330c commit r11-8508-g8b1190d527d01dc74ee53e47b0366d01270c330c Author: Eric Botcazou Date: Thu Jun 3 12:39:39 2021 +0200 Tame fix for PR ipa/99122 The return part has a major performance impact in Ada where variable-sized types are first-class citizens, but it turns out that it is not exercized in the testsuite yet, so back it out for now. gcc/ PR ipa/99122 * tree-inline.c (inline_forbidden_p): Remove test on return type. gcc/testsuite/ * gnat.dg/inline22.adb: New test.
[Bug target/100887] [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100887 --- Comment #6 from Zdenek Sojka --- (In reply to Jakub Jelinek from comment #5) > Created attachment 50919 [details] > gcc12-pr100887.patch > > Untested fix. Thank you for the patch. So the testcase from c#3 might be unrelated.
[Bug target/100887] [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100887 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 50919 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50919&action=edit gcc12-pr100887.patch Untested fix.
[Bug ipa/99122] [10 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #36 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:ad085ef5fb4142df2027f81ea03992fdafc6e2f6 commit r12-1176-gad085ef5fb4142df2027f81ea03992fdafc6e2f6 Author: Eric Botcazou Date: Thu Jun 3 12:39:39 2021 +0200 Tame fix for PR ipa/99122 The return part has a major performance impact in Ada where variable-sized types are first-class citizens, but it turns out that it is not exercized in the testsuite yet, so back it out for now. gcc/ PR ipa/99122 * tree-inline.c (inline_forbidden_p): Remove test on return type. gcc/testsuite/ * gnat.dg/inline22.adb: New test.
[Bug target/100887] [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100887 --- Comment #4 from Zdenek Sojka --- (In reply to Jakub Jelinek from comment #1) > ICEs since r12-1128-gef8176e0fac935c095cc39f4ecdfd43cdb8cb3f3 That is when __builtin_shufflevector() was introduced.
[Bug target/100887] [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100887
--- Comment #3 from Zdenek Sojka ---
Probably related issue:
$ cat testcase.c
typedef unsigned long long __attribute__((__vector_size__ (16))) U;
typedef unsigned long long __attribute__((__vector_size__ (32))) V;
typedef unsigned long long __attribute__((__vector_size__ (64))) W;
U
foo (V v)
{
return __builtin_shufflevector ((W){}, v, 0, 8);
}
$ x86_64-pc-linux-gnu-gcc -mavx512f testcase.c
testcase.c: In function 'foo':
testcase.c:6:1: error: not allowed type combination in 'bit_insert_expr'
6 | foo (V v)
| ^~~
W
V
_2 = BIT_INSERT_EXPR <{ 0, 0, 0, 0, 0, 0, 0, 0 }, v, 64>;
testcase.c:6:1: internal compiler error: 'verify_gimple' failed
0x10b85ad verify_gimple_in_seq(gimple*)
/repo/gcc-trunk/gcc/tree-cfg.c:5161
0xdaf5e6 gimplify_body(tree_node*, bool)
/repo/gcc-trunk/gcc/gimplify.c:15404
0xdaf75d gimplify_function_tree(tree_node*)
/repo/gcc-trunk/gcc/gimplify.c:15475
0xbd9127 cgraph_node::analyze()
/repo/gcc-trunk/gcc/cgraphunit.c:670
0xbdbc57 analyze_functions
/repo/gcc-trunk/gcc/cgraphunit.c:1234
0xbdc8ed symbol_table::finalize_compilation_unit()
/repo/gcc-trunk/gcc/cgraphunit.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/100885] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2671: insn does not satisfy its constraints: {sse4_1_zero_extendv8qiv8hi2}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100885 --- Comment #5 from Hongtao.liu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571815.html
[Bug libstdc++/100889] Wrong param type for std::atomic_ref<_Tp*>::wait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Keywords||rejects-valid Last reconfirmed||2021-06-03 CC||rodgertq at gcc dot gnu.org Status|UNCONFIRMED |NEW
[Bug target/100887] [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100887
--- Comment #2 from Jakub Jelinek ---
Slightly adjusted so that it doesn't use uninitialized vars and does actually
return what is computed:
typedef unsigned __int128 U __attribute__((__vector_size__ (64)));
typedef unsigned __int128 V __attribute__((__vector_size__ (32)));
typedef unsigned __int128 W __attribute__((__vector_size__ (16)));
W
foo (U u, V v)
{
return __builtin_shufflevector (u, v, 0);
}
[Bug target/100887] [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100887 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-06-03 Target Milestone|--- |12.0 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE: in |[12 Regression] ICE: in |ix86_expand_vector_init_con |ix86_expand_vector_init_con |cat, at |cat, at |config/i386/i386-expand.c:1 |config/i386/i386-expand.c:1 |4178 with -mavx512f and |4178 with -mavx512f and |__builtin_shufflevector() |__builtin_shufflevector() Status|UNCONFIRMED |NEW --- Comment #1 from Jakub Jelinek --- ICEs since r12-1128-gef8176e0fac935c095cc39f4ecdfd43cdb8cb3f3
[Bug c++/67193] Overzealous -Wstack-usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67193 Tobias Schlüter changed: What|Removed |Added Known to fail||10.3.0, 11.1.0 --- Comment #4 from Tobias Schlüter --- Confirmed with 10.3 and 11.1
[Bug c++/100877] g++ freezes system by consuming infinite amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100877 Feng Wang changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Feng Wang --- A bug in the attached code causes this problem.
[Bug c++/100891] New: #pragma GCC diagnostic ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100891
Bug ID: 100891
Summary: #pragma GCC diagnostic ignored
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tobi at gcc dot gnu.org
Target Milestone: ---
$ cat t.cpp
#if defined(__GNUC__)
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wmultichar"
// Check that I'm disabling warnings correctly: the following warnings
disappear correctly:
#pragma GCC diagnostic ignored "-Wnarrowing"
#pragma GCC diagnostic ignored "-Woverflow"
#endif
constexpr int native{ 'ABCD' };
constexpr short i{123456}; // crosscheck
#if defined(__GNUC__)
#pragma GCC diagnostic pop
#endif
$ g++ -Wall -c t.cpp
t.cpp:8:35: warning: multi-character character constant [-Wmultichar]
constexpr int native{ 'ABCD' };
^~
$
Compiler explorer link here: https://godbolt.org/z/P5cjqKs4a
Verified with all versions on the compiler explorer back to 6.2.
[Bug ipa/100888] ICE: symtab_node::verify failed, symtab_node::verify()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100888 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-03 --- Comment #1 from Martin Liška --- Started with my r9-6392-g606711a1671cc637.
[Bug target/100333] arm: ICE (unrecognizable insn) with CMSE nonsecure call and -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100333 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:e58539d965059994ebac606ae7533e857bbe199f commit r11-8506-ge58539d965059994ebac606ae7533e857bbe199f Author: Alex Coplan Date: Wed May 19 15:52:45 2021 +0100 arm: Fix ICE with CMSE nonsecure calls on Armv8.1-M [PR100333] As the PR shows, we ICE shortly after expanding nonsecure calls for Armv8.1-M. For Armv8.1-M, we have TARGET_HAVE_FPCXT_CMSE. As it stands, the expander (arm.md:nonsecure_call_internal) moves the callee's address to a register (with copy_to_suggested_reg) only if !TARGET_HAVE_FPCXT_CMSE. However, looking at the pattern which the insn appears to be intended to match (thumb2.md:*nonsecure_call_reg_thumb2_fpcxt), it requires the callee's address to be in a register. This patch therefore just forces the callee's address into a register in the expander. gcc/ChangeLog: PR target/100333 * config/arm/arm.md (nonsecure_call_internal): Always ensure callee's address is in a register. gcc/testsuite/ChangeLog: PR target/100333 * gcc.target/arm/cmse/pr100333.c: New test. (cherry picked from commit 5b953740da1976d90d974055c6d825c509c6e654)
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #15 from Andrew Pinski --- (In reply to Andrew Pinski from comment #14) > My patch needs to be re-written to use match.pd instead. I am going to update it.
[Bug c++/100859] [12 Regression][OpenMP] ICE in tsubst_omp_clauses, at cp/pt.c:17520 since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:098f4e989beb1a1be1157430c56ea4f158c1d538
commit r12-1171-g098f4e989beb1a1be1157430c56ea4f158c1d538
Author: Jakub Jelinek
Date: Thu Jun 3 10:38:08 2021 +0200
openmp: Assorted depend/affinity/iterator related fixes [PR100859]
The depend-iterator-3.C testcases shows various bugs.
1) tsubst_omp_clauses didn't handle OMP_CLAUSE_AFFINITY (should be
handled like OMP_CLAUSE_DEPEND)
2) because locators can be arbitrary lvalue expressions, we need
to allow for C++ array section base (especially when array section
is just an array reference) FIELD_DECLs, handle them as this->member,
but don't need to privatize in any way
3) similarly for this as base
4) depend(inout: this) is invalid, but for different reason than the
reported
one, again this is an expression, but not lvalue expression, so that
should be reported
5) the ctor/dtor cloning in the C++ FE (which is using walk_tree with
copy_tree_body_r) didn't handle iterators correctly, walk_tree normally
doesn't walk TREE_PURPOSE of TREE_LIST, and in the iterator case
that TREE_VEC contains also a BLOCK that needs special handling during
copy_tree_body_r
2021-06-03 Jakub Jelinek
PR c++/100859
gcc/
* tree-inline.c (copy_tree_body_r): Handle iterators on
OMP_CLAUSE_AFFINITY or OMP_CLAUSE_DEPEND.
gcc/c/
* c-typeck.c (c_finish_omp_clauses): Move OMP_CLAUSE_AFFINITY
after depend only cases.
gcc/cp/
* semantics.c (handle_omp_array_sections_1): For
OMP_CLAUSE_{AFFINITY,DEPEND} handle FIELD_DECL base using
finish_non_static_data_member and allow this as base.
(finish_omp_clauses): Move OMP_CLAUSE_AFFINITY
after depend only cases. Let this be diagnosed by !lvalue_p
case for OMP_CLAUSE_{AFFINITY,DEPEND} and remove useless
assert.
* pt.c (tsubst_omp_clauses): Handle OMP_CLAUSE_AFFINITY.
gcc/testsuite/
* g++.dg/gomp/depend-iterator-3.C: New test.
* g++.dg/gomp/this-1.C: Don't expect any diagnostics for
this as base expression of depend array section, expect a different
error wording for this as depend locator and add testcases
for affinity clauses.
[Bug fortran/59202] Erroneous argument aliasing with defined assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59202
--- Comment #4 from federico ---
The self-assignment issue is present even if the derived type has no
allocatable components. Here is a sample test program that gives an error with
gfortran 10.2.0:
module assign
implicit none
private
type, public :: t
integer :: a
contains
procedure :: destroy=>t_destroy
procedure :: assign=>t_assign
generic :: assignment(=) =>assign
end type t
contains
elemental subroutine t_destroy(this)
class(t), intent(inout) :: this
this%a = 0
end subroutine t_destroy
subroutine t_assign(this,that)
class(t), intent(inout) :: this
class(t), intent(in) :: that
call this%destroy() ! Clean memory first
select type (thatPtr=>that)
type is (t)
this%a = thatPtr%a
end select
end subroutine t_assign
end module assign
program test
use assign
type(t), allocatable :: t1(:)
allocate(t1(10))
do i=1,10
t1(i)%a = i
end do
n = 0
do i=1,10
if (mod(i,2)/=0) then
n = n + 1
t1(n) = t1(i)
print *, 'i=',i,' t(i)%a=',t1(i)%a,' expected t(i)%a=',i,':
',merge('ERROR!','OK',t1(i)%a/=i)
endif
end do
end program test
[Bug fortran/59202] Erroneous argument aliasing with defined assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59202 federico changed: What|Removed |Added CC||federico.perini at gmail dot com --- Comment #3 from federico --- Created attachment 50918 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50918&action=edit test program for self-assignment with derived type
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #7 from Nadav Halahmi --- (In reply to Dominique d'Humieres from comment #6) > On a MacOS, Corei9, 2.4Ghz, the program runs in ~1s, almost indpendtly of > the option level. > > This PR remind me an old problem in which the transcendental functions were > almost slower for REAL(4) then for REAL(8) on some Unix distros (Fedora(?), > based of "correct rounding"). > > What are your timings if you replace > > real :: sum, n, q > > with > > real(8) :: sum, n, q > > and > > sum = sum + (i ** (0.05 + n)) > > with > > sum = sum + (i ** (0.05_8 + n)) > > ? Timings for this change (notice the result was also changed): gnu: 150945570.07620683 Time = 6.303 seconds. intel: 150945570.076207 Time = 2.349 seconds. So gnu is indeed faster for real(8), but the result was changed.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 Andrew Pinski changed: What|Removed |Added Assignee|andres.tiraboschi@tallertec |unassigned at gcc dot gnu.org |hnologies.com | Status|ASSIGNED|NEW
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 Andrew Pinski changed: What|Removed |Added CC||david at westcontrol dot com --- Comment #15 from Andrew Pinski --- *** Bug 100890 has been marked as a duplicate of this bug. ***
[Bug c/100890] The "div" standard library functions could be optimised as builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100890 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 70742. *** This bug has been marked as a duplicate of bug 70742 ***
[Bug target/100885] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2671: insn does not satisfy its constraints: {sse4_1_zero_extendv8qiv8hi2}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100885 --- Comment #4 from Hongtao.liu --- > Need to adjust the third constraint from (v, vm, C, n) to (Yw, Ywm, C, n) Also for those extend instructions which need AVX512VL is needed for xmm16-xmm32.
[Bug c/100890] New: The "div" standard library functions could be optimised as builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100890
Bug ID: 100890
Summary: The "div" standard library functions could be
optimised as builtins
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
The C standard library has a family of functions for calculating the division
and remainder as a pair - "div", "ldiv", "lldiv", "imaxdiv". These could be
optimised by the compiler using inline code, in the same manner as many other
library functions such as the "abs" family (listed under "Other builtins" in
the manual).
For example, "div" can be implemented as:
div_t div(int a, int b) {
div_t d;
d.quot = a / b;
d.rem = a % b;
return d;
}
Inlining this in place of a call to "div" results in code that is smaller and
faster on most targets, as well as providing far more optimisation
opportunities (constant propagation, re-arranging with other code, etc.).
[Bug target/100703] __vector_pair and __vector_quad cannot be passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100703 --- Comment #3 from Alexander Grund --- I found that this was fixed in 10.3 and 11.1 by https://github.com/gcc-mirror/gcc/commit/e2882e76089cecdc268d0835c54cabfa80b5b0be So yes only happens in 10.2. Thanks for checking that!
[Bug target/43892] PowerPC suboptimal "add with carry" optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #34 from Joakim Tjernlund ---
(In reply to Christophe Leroy from comment #28)
> Looks like we have a way to do it. Works at least with GCC 5.5, 8.2, 9.2,
> 10.1
>
> unsigned long g(unsigned long a, unsigned long b)
> {
> unsigned long long s = (unsigned long long)a + (unsigned long long)b;
>
> return (s >> 32) + s;
> }
>
> 0020 :
> 20: 7c 63 20 14 addcr3,r3,r4
> 24: 7c 63 01 94 addze r3,r3
> 28: 4e 80 00 20 blr
>
Does that work when placed in a loop to?
Something close to the example in the first comment:
for(;len; --len)
sum = add32carry(sum, *++buf);
addic 3, 3, 0 /* clear carry */
.L31:
lwzu 0,4(9)
adde 3, 3, 0 /* add with carry */
bdnz .L31
addze 3, 3 /* add in final carry */
