[Bug sanitizer/100114] libasan built against latest glibc doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100114 Richard Biener changed: What|Removed |Added Known to work||11.0 --- Comment #7 from Richard Biener --- Yeah, backporting everywhere is needed.
[Bug tree-optimization/100081] [11 Regression] Compile time hog in irange since r11-4135-ge864d395b4e862ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081 --- Comment #10 from Richard Biener --- (In reply to Andrew Macleod from comment #8) > OMG. Don't bother reducing. I can see the problem. > > EVRP is fine, but when wrestrict runs, its quite late, and the CFG has > > [local count: 28382607]: > <...> > _571 = _61 >= _593; > _3583 = &arr_724 + _3992; > _2220 = _831 <= _3583; > _47 = _571 | _2220; > _2935 = _376 * 2; > _3966 = &arr_725 + _2935; > _3024 = _61 >= _3966; > _4219 = _3992 * 2; > _4218 = &arr_725 + _4219; > _1836 = _831 <= _4218; > _3080 = _1836 | _3024; > <...> > _5348 = _5347 & _32080; > _5349 = _5348 & _32151; > _5350 = _5349 & _32176; > _5351 = _5350 & _32488; > _5352 = _5351 & _33691; > _5353 = _5352 & _33762; > _5354 = _5353 & _34753; > _35662 = _5354 & _34824; > if (_35662 != 0) > goto ; [90.00%] > else > goto ; [10.00%] > > Its a 7200 stmt basic block, made up of calculations and 2614 ORs and 1480 > ANDs. > > A request is made for a range which can be exported from this block, and > ranger is dutifully trying everything it can to process those blocks. > > Each AND/OR is a logical expression which evaluates a TRUE and FALSE range > for each operands, so it calculates up to 4 ranges for each pair of > operands. I knew this could get out of hand in pathological cases, so we > introduced a logical cache to help resolve this and avoid extra work. Its > actually making this one worse I think. Hmm, still the overall work should be linear to produce ranges for all of the SSA defs in this BB, no? As heuristic you might want to avoid producing ranges for single-use defs, like those that are just used in another & or | combination? Wrestrict should only be interested in ranges for the "tails" of this &| tree (for example _61 in _61 >= _3966). But yes, if you have any worse than O(n log n) algorithm then artificially limiting it's cost by capping 'n' at some (--param controlled) value is the way to go.
[Bug c/100141] New: Unable to build amdgcn-amdhsa offload accelerator for MinGW-w64 for both Windows 32-bit and 64-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100141 Bug ID: 100141 Summary: Unable to build amdgcn-amdhsa offload accelerator for MinGW-w64 for both Windows 32-bit and 64-bit Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: brechtsanders at users dot sourceforge.net Target Milestone: --- Created attachment 50625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50625&action=edit amdgcn-amdhsa/libgcc/config.log When I try to build the GCC amdgcn-amdhsa offload accelerator for MinGW-w64 for both Windows 32-bit (--target=amdgcn-amdhsa --enable-as-accelerator-for=i686-w64-mingw32) and 64-bit (--target=amdgcn-amdhsa --enable-as-accelerator-for=x86_64-w64-mingw32). This has been the case all versions I tried (last attempt was 10.3.0). The output I get is: checking for suffix of object files... configure: error: in `/R/winlibs64-10.3.0/gcc-offload-amdgcn-10.3.0/gcc-10.3.0/build_win_offload-amdgcn/amdgcn-amdhsa/libgcc': configure: error: cannot compute suffix of object files: cannot compile See attached amdgcn-amdhsa/libgcc/config.log The full command line (for Windows 64-bit) looks like this: ../configure --prefix=/R/winlibs64-10.3.0/inst_gcc-offload-amdgcn-10.3.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=amdgcn-amdhsa --enable-as-accelerator-for=x86_64-w64-mingw32 --with-build-time-tools=/d/Prog/winlibs64-10.3.0/custombuilt/share/amdgcn-tools/amdgcn-amdhsa/bin --with-gnu-as --with-gnu-ld --disable-serial-configure --enable-checking=release --without-libbacktrace --without-included-gettext --without-cuda-driver --enable-multiarch --enable-newlib-io-long-long --enable-linker-build-id --with-newlib --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-libgomp --enable-languages=c,c++,lto,objc,obj-c++,d CFLAGS="-I/d/Prog/winlibs64-10.3.0/custombuilt/include/mman-win32" LDFLAGS="-Wl,--as-needed -lmman"
[Bug tree-optimization/97236] [8 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236 Richard Biener changed: What|Removed |Added CC||sudi at gcc dot gnu.org --- Comment #18 from Richard Biener --- *** Bug 85804 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/85804] [8/9 Regression][AArch64] Mis-compilation of loop with strided array access and xor reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #15 from Richard Biener --- Duplicate (and fixed). *** This bug has been marked as a duplicate of bug 97236 ***
[Bug middle-end/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 --- Comment #9 from Martin Uecker --- The behavior of GCC is dangerous as the example in comment #1 show. You can not reason at all about the generated code. It is not just that the uninitialized value causes some random choice but it creates situation where seemingly impossible things can happen. Assume this propagates into another security relevant function which when analyzed independently appears completely safe, i.e. maintains some important property by carefully checking its inputs. But just having an uninitialized read somewhere else compromises the integrity of the whole program. Of course, if this is UB than this is technically allowed from the standard's point of view. But what the standard allows is one question. What a good compiler should do in case of undefined behavior is a completely different one. The "optimize based on the assumption that UB can not happen" philosophy amplifies even minor programming errors into something dangerous. This, of course, also applies to other UB (in varying degrees). For signed overflow we have -fsanitize=signed-integer-overflow which can help detect and mitigate such errors, e.g. by trapping at run-time. And also this is allowed by UB. In case of UB the choice of what to do lies with the compiler, but I think it is a bug if this choice is unreasonable and does not serve its users well.
[Bug c/100140] New: Reference gcc development github mirror - Latest Development Build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100140
Bug ID: 100140
Summary: Reference gcc development github mirror - Latest
Development Build
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: j130496 at live dot co.uk
Target Milestone: ---
Dear sir
Posting as under:
Used ../configure --enable-multilib and then make -s from build directory
created inside source downloaded from
https://github.com/gcc-mirror/gcc/commit/d64720a07f611c55e8c815c775a852d650a2e738
(link of latest GCC administrator bump on GCC development github mirror)
I am reproducing the comment posted there which gives entire details required
for bug tracking and resolving. Unfortunately, no developers are responding to
my messages on Github development builds since last 2 days hence posting here:
Posted as under on Github:
Dear sir
As conveyed earlier - even after latest daily bump, the following error while
using ../configure --enable-multilib followed by make -s persists. Request you
and entire community of developers to look into - I am not a developer myself
otherwise I could look into this and resolve myself and would have posted pull
request to be merged instead of requesting again and again. Facing this make -s
error since last 3 days. As I have personal interest in testing new development
of GCC 11 version (although not a developer and also not knowing much about C
and C++) - I am daily testing after changes. Error copied from terminal screen
is as under:
113 | "~" |
| ^~~~
gengtype-lex.c:365:15: warning: this statement may fall through
[-Wimplicit-fallthrough=]
365 | #define YY_DO_BEFORE_ACTION
| ~^~~
../../gcc/gengtype-lex.l:138:1: note: in expansion of macro
‘YY_DO_BEFORE_ACTION’
138 | ;
| ^ ~
../../gcc/gengtype-lex.l:134:1: note: here
134 | "ENUM_BITFIELD"{WS}?"("{WS}?{ID}{WS}?")" {
| ^~~~
/usr/local/x86_64-pc-linux-gnu/bin/ld:
/home/admin/Downloads/gcc_18042021_1708hrs_IST/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(guard.o):
in function __gnu_cxx::__is_single_threaded()':
/home/admin/Downloads/gcc_18042021_1708hrs_IST/build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/atomicity.h:52:
undefined reference to __libc_single_threaded'
/usr/local/x86_64-pc-linux-gnu/bin/ld:
/home/admin/Downloads/gcc_18042021_1708hrs_IST/build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/atomicity.h:52:
undefined reference to __libc_single_threaded'
/usr/local/x86_64-pc-linux-gnu/bin/ld:
/home/admin/Downloads/gcc_18042021_1708hrs_IST/build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/atomicity.h:52:
undefined reference to __libc_single_threaded'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:3008: build/genpreds] Error 1
make[2]: *** [Makefile:4822: all-stage2-gcc] Error 2
make[1]: *** [Makefile:25993: stage2-bubble] Error 2
make: *** [Makefile:1001: all] Error 2
My OS details: OS - AlmaLinux 8.3 x86_64 - kernel - 5.11.11-1.el8.elrepo.x86_64
Current stable GCC version details from terminal screen:
[root@admin build]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (GCC)
Once again requesting all to look into.
Thank you in advance.
Regards,
[Bug c++/100138] ICE with constructor constrained (C++20 Concepts) by parameter pack length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138 Patrick Palka changed: What|Removed |Added Last reconfirmed||2021-04-19 Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Patrick Palka --- Confirmed. Interestingly, avoiding CTAD by replacing 'Foo' with 'Foo<>` in the declaration of 'x' seems to be another workaround.
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 Patrick Palka changed: What|Removed |Added CC||pkeir at outlook dot com --- Comment #19 from Patrick Palka --- *** Bug 96414 has been marked as a duplicate of this bug. ***
[Bug c++/96414] Second char relation test incorrect with constexpr dynamic allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96414 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Thanks for the bug report. I think the underlying bug here is the same as that of the recently fixed PR99859, and indeed trunk accepts your testcase ever since r11-8056, so I'm going to mark this PR as a duplicate. *** This bug has been marked as a duplicate of bug 99859 ***
[Bug libstdc++/100139] std::views::{take, drop} don't type erase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100139 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Some of the wording changes of P1739 are problematic as discussed in LWG issue 3407 (https://cplusplus.github.io/LWG/lwg-active.html#3407), which is why we don't implement it yet. Though I suppose we could at least implement the workable parts of P1739 while waiting for the LWG issue to get resolved.
[Bug libstdc++/100139] New: std::views::{take, drop} don't type erase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100139
Bug ID: 100139
Summary: std::views::{take, drop} don't type erase
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hello gcc-team,
the following code:
```cpp
#include
#include
#include
#include
static_assert(std::same_as,
decltype(std::views::take(std::span{}, 2))>);
static_assert(std::same_as);
```
does not compile (yet).
https://godbolt.org/z/6Mq7x8zaj
AFAIK this should be
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1739r0.md that was
merged by https://github.com/cplusplus/draft/pull/3777.
There was a rather amusing error report at stackoverflow [1].
I tried to find that proposal in [2] but couldn't and wanted to ask if I looked
at the wrong place. If you have time to implement this, that would be awesome!
Thank you!
[1]
https://stackoverflow.com/questions/61867635/recursive-application-of-c20-range-adaptor-causes-a-compile-time-infinite-loop
[2] https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2020
[Bug c++/100138] New: ICE with constructor constrained (C++20 Concepts) by parameter pack length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138
Bug ID: 100138
Summary: ICE with constructor constrained (C++20 Concepts) by
parameter pack length
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 50624
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50624&action=edit
The C++ file producing the ICE
Compiling the code below with `-c -std=c++20` produces an ICE.
template
struct Foo
{
template
Foo(Ts... xs) requires(sizeof...(xs)==N) {}
};
void bar()
{
Foo x{64};
}
As a workaround, using Ts rather than xs within the requires clause avoids the
ICE. The error message is below:
constrained_ctor.hpp: In substitution of ‘template Foo(Ts
...)-> Foo requires sizeof ... ((Foo::__ct ::xs ...)) == N [with int N =
1; Ts = {int}]’:
constrained_ctor.hpp:10:11: required from here
constrained_ctor.hpp:5:26: internal compiler error: Segmentation fault
5 | Foo(Ts... xs) requires(sizeof...(xs)==N) {}
| ^
0x10d0e8f crash_signal
../../gcc/toplev.c:327
0x950d49 hash_table, tree_node*>
>::hash_entry, false, xcallocator>::find_slot_with_hash(tree_node* const&,
unsigned int, insert_option)
../../gcc/hash-table.h:963
0xac055d hash_map, tree_node*>
>::put(tree_node* const&, tree_node* const&)
../../gcc/hash-map.h:166
0xac055d register_local_specialization(tree_node*, tree_node*)
../../gcc/cp/pt.c:2004
0xad21e1 gen_elem_of_pack_expansion_instantiation
../../gcc/cp/pt.c:12496
0xad21e1 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13173
0xac63be tsubst_copy
../../gcc/cp/pt.c:16925
0xac7ca4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:20896
0xac7ad3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19856
0xad3128 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:19144
0x95a455 satisfy_atom
../../gcc/cp/constraint.cc:2984
0x95a455 satisfy_constraint_r
../../gcc/cp/constraint.cc:3047
0x95a779 satisfy_normalized_constraints
../../gcc/cp/constraint.cc:3069
0x957d7e satisfy_declaration_constraints
../../gcc/cp/constraint.cc:3277
0x957d7e constraint_satisfaction_value
../../gcc/cp/constraint.cc:3297
0x95a810 constraints_satisfied_p(tree_node*, tree_node*)
../../gcc/cp/constraint.cc:3334
0xaf98a5 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../gcc/cp/pt.c:21632
0x9053fd add_template_candidate_real
../../gcc/cp/call.c:3456
0x905eda add_template_candidate
../../gcc/cp/call.c:3541
0x905eda add_candidates
../../gcc/cp/call.c:6031
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/100137] -Werror=array-bounds false positive:"subscript -1 is outside array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137 --- Comment #1 from Moritz Beutel --- The problem was discovered in gsl-lite by a user of the library: https://github.com/gsl-lite/gsl-lite/issues/303 This bug (if confirmed) should probably be added to the -Warray-bounds meta-bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug c++/100137] New: -Werror=array-bounds false positive:"subscript -1 is outside array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137
Bug ID: 100137
Summary: -Werror=array-bounds false positive:"subscript -1 is
outside array bounds"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: spamandnoise at gmail dot com
Target Milestone: ---
- exact version of GCC: 11.0.1 20210417 (bug first appeared in GCC 10.3)
- system type: x86_64-linux-gnu
- options given when GCC was configured/built: see below
- complete command line that triggers the bug: `g++ -O2 -Werror -Wall
-std=c++17 -c test.cpp`
compiler output:
-
test.cpp: In function 'int main()':
test.cpp:38:11: error: array subscript -1 is outside array bounds of 'char [6]'
[-Werror=array-bounds]
38 | s.back() = '2';
| ~~^~
test.cpp:36:10: note: while referencing 'hello'
36 | char hello[] = "hello";
| ^
cc1plus: all warnings being treated as errors
Compiler returned: 1
-
- preprocessed file that triggers the bug:
-
typedef long unsigned int size_t; // expanded from
struct span
{
span( char* _data, size_t _size )
: first_( _data ),
last_( _data != nullptr ? _data + _size : nullptr )
{
if ( _size != 0 && _data == nullptr ) throw 42;
}
char& back() const
{
//return *( first_ + ( last_ - first_ - 1 ) ); // this works
return *( last_ - 1 );
}
char* first_;
char* last_;
};
size_t string_length( char const * ptr, size_t max = (size_t) - 1 )
{
size_t len = 0;
while ( len < max && ptr[len] )
{
++len;
}
return len;
}
int
main()
{
char hello[] = "hello";
span s{ hello, string_length( hello ) };
s.back() = '2';
}
-
`g++ -v` output:
-
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20210418/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,d
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210417 (experimental) (Compiler-Explorer-Build)
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-v' '-O2' '-Werror' '-Wall' '-std=c++17' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' '/app/'
/opt/compiler-explorer/gcc-trunk-20210418/bin/../libexec/gcc/x86_64-linux-gnu/11.0.1/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20210418/bin/../lib/gcc/x86_64-linux-gnu/11.0.1/
-D_GNU_SOURCE -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext
.cpp -masm=intel -mtune=generic -march=x86-64 -g -O2 -Werror -Wall -std=c++17
-version -fdiagnostics-color=always -o /app/output.s
GNU C++17 (Compiler-Explorer-Build) version 11.0.1 20210417 (experimental)
(x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
[...]
Compiler executable checksum: c26ce8a3d2d070f1dc9f9a165aea3eaf
-
[Bug fortran/99255] ICE in gfc_dt_upper_string, at fortran/module.c:441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255 --- Comment #2 from anlauf at gcc dot gnu.org --- Replacing class(t) :: x by class(t), allocatable :: x avoids the ICE. Could be an error recovery issue.
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-11, and backported to 10-branch as suggested by Paul. Closing. Thanks for the report!
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:aff57bcebe534b1d92f78bdfb89a4001a6d12af2 commit r10-9712-gaff57bcebe534b1d92f78bdfb89a4001a6d12af2 Author: Harald Anlauf Date: Fri Apr 16 16:24:31 2021 +0200 PR fortran/63797 - Bogus ambiguous reference to 'sqrt' The interface of an intrinsic procedure is automatically explicit. Do not write it to the module file to prevent wrong ambiguities on USE. gcc/fortran/ChangeLog: PR fortran/63797 * module.c (write_symtree): Do not write interface of intrinsic procedure to module file for F2003 and newer. gcc/testsuite/ChangeLog: PR fortran/63797 * gfortran.dg/pr63797.f90: New test. Co-authored-by: Paul Thomas (cherry picked from commit d264194c1069fbcd129222f86455137f29a5c6fd)
[Bug libstdc++/100133] std::copy extremely slow for random access iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Jonathan Wakely --- This should be RESOLVED INVALID not RESOLVED FIXED, because nothing needed to be fixed.
[Bug middle-end/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #8 from Andrew Pinski --- I read the standard fully differently but I will let someone else make the decision here. About "2) really dangerous" GCC already treat many other undefined behavior as undefined that being dangerous is wrong here. For an example GCC treats signed integer overflow as undefined and the dangerous part is similar to this case; though GCC does have a way to detect at runtime if that happens.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #14 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #13) > The following variant gives an ICE > >type t >end type > contains >function f() result(t) > character(3) :: c > c = 'abc' >end > end > > > Is the code valid? No.
[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 康桓瑋 changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from 康桓瑋 --- After actually executing the same code on my local and remote servers, I did not produce such a result, so I think it should only be an issue of the environment, thank you for your time.
[Bug libstdc++/100133] std::copy extremely slow for random access iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133 康桓瑋 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from 康桓瑋 --- (In reply to 康桓瑋 from comment #2) > After actually executing the same code on my local and remote servers, I did > not produce such a result. In both cases, std::copy achieved the expected > high-efficiency performance, so I think this should only be Quick C++ > Benchmark > Own question, thank you for your time Close.
[Bug libstdc++/100133] std::copy extremely slow for random access iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133 --- Comment #2 from 康桓瑋 --- After actually executing the same code on my local and remote servers, I did not produce such a result. In both cases, std::copy achieved the expected high-efficiency performance, so I think this should only be Quick C++ Benchmark Own question, thank you for your time
[Bug rtl-optimization/99927] Wrong code since r11-39-gf9e1ea10e657af9f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #18 from Segher Boessenkool --- Fixed for 11. This still needs backports for 10 and everything before, please don't close the bug.
[Bug fortran/100136] New: ICE, regression, using flag -fcheck=pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136 Bug ID: 100136 Summary: ICE, regression, using flag -fcheck=pointer Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50623&action=edit Fortran code showing problem Hi All! ICE using flag -fcheck=pointer. Seen on: GNU Fortran (GCC) 11.0.1 20210417 (experimental) Older versions don't ICE, but don't do any checking either... Thank you very much. Best regards, José Rui
[Bug tree-optimization/99927] [11 Regression] Wrong code since r11-39-gf9e1ea10e657af9f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927 --- Comment #17 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:b412ce8e961052e6becea3bc783a53e1d5feaa0f commit r11-8237-gb412ce8e961052e6becea3bc783a53e1d5feaa0f Author: Segher Boessenkool Date: Sat Apr 17 18:06:17 2021 + combine: Don't create REG_UNUSED notes if the reg already died (PR99927) If the register named in an existing REG_UNUSED note dies somewhere between where the note used to be and I3, we should just drop it. 2021-04-21 Segher Boessenkool PR rtl-optimization/99927 * combine.c (distribute_notes) [REG_UNUSED]: If the register already is dead, just drop it.
[Bug middle-end/88175] GCC should not warn within implicit copy-constructor (or should report the implicit function in a special way)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175 --- Comment #20 from Jonny Grant --- (In reply to Jonathan Wakely from comment #19) > Why is that needed? It says the location is something like: > > In member function ‘info& info::operator=(const info&)’, > > or: > > In copy constructor ‘info::info(const info&)’, > > If that isn't explicitly defined in the class, then obviously it's being > defined implicitly by the compiler. That property of C++ should not surprise > anybody. You're point is valid. Highlighting it is implicitly generated is purely an informative diagnostic. I've been on C++ teams where certain software engineers weren't aware of implicitly generated constructors.
[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534 --- Comment #5 from Paul Thomas --- This needs to be incorporated into the fix for PR100027. I hope that Jose takes this PR over :-) Paul
[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005 since r11-6325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446
--- Comment #13 from Bernd Edlinger ---
Hi Nathan,
I've been playing with a variant of c-c++-common/raw-string-6.c
with your patch:
$ cat raw-string-6.c
$ cat raw-string-6.c
// { dg-do compile }
// { dg-options "-std=gnu99" { target c } }
// { dg-options "-std=c++0x" { target c++ } }
#include ".h"
$ cat .h
const void *s0 = R"ouch()ouCh";
$ gcc -x c raw-string-6.c
In file included from raw-string-6.c:5:
.h:1:18: error: unterminated raw string
1 | const void *s0 = R"ouch()ouCh";
| ^
raw-string-6.c:6: error: expected expression at end of input
$ gcc -x c++ raw-string-6.c
In file included from raw-string-6.c:5:
.h:1:18: error: unterminated raw string
1 | const void *s0 = R"ouch()ouCh";
| ^
.h:1:16: error: expected primary-expression at end of input
1 | const void *s0 = R"ouch()ouCh";
|^
Do you agree that the C++ FE places the error about the end of input
on a somewhat surprising place?
Bernd.
[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98088
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Hafiz Abid Qadeer
:
https://gcc.gnu.org/g:e4dcb3383bff4c209a918127551cabc56b4171ae
commit r10-9711-ge4dcb3383bff4c209a918127551cabc56b4171ae
Author: Hafiz Abid Qadeer
Date: Thu Apr 8 17:31:30 2021 +0100
[OpenACC] Fix an ICE where a loop with GT condition is collapsed.
We have seen an ICE both on trunk and devel/omp/gcc-10 branches which can
be reprodued with this simple testcase. It occurs if an OpenACC loop has
a collapse clause and any of the loop being collapsed uses GT or GE
condition. This issue is specific to OpenACC.
int main (void)
{
int ix, iy;
int dim_x = 16, dim_y = 16;
{
for (iy = dim_y - 1; iy > 0; --iy)
for (ix = dim_x - 1; ix > 0; --ix)
;
}
}
The problem is caused by a failing assertion in expand_oacc_collapse_init.
It checks that cond_code for fd->loop should be same as cond_code for all
the loops that are being collapsed. As the cond_code for fd->loop is
LT_EXPR with collapse clause (set at the end of omp_extract_for_data),
this assertion forces that all the loop in collapse clause should use
< operator.
There does not seem to be anything in the code which demands this
condition as loop with > condition works ok otherwise. I digged old
mailing list a bit but could not find any discussion on this change.
Looking at the code, expand_oacc_for checks that fd->loop->cond_code is
either LT_EXPR or GT_EXPR. I guess the original intention was to have
similar checks on the loop which are being collapsed. But the way check
was written does not acheive that.
I have fixed it by modifying the check in the assertion to be same as
check on fd->loop->cond_code.
I tested goacc and libgomp (with nvptx offloading) and did not see any
regression. I have added new tests to check collapse with GT/GE condition.
PR middle-end/98088
gcc/
* omp-expand.c (expand_oacc_collapse_init): Update condition in
a gcc_assert.
gcc/testsuite/
* c-c++-common/goacc/collapse-2.c: New.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/collapse-2.c: Add check
for loop with GT/GE condition.
* testsuite/libgomp.oacc-c-c++-common/collapse-3.c: Likewise.
(cherry picked from commit ac200799acb5cd2fb9e1758f6bf5fff1978daaeb)
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #13 from Dominique d'Humieres --- The following variant gives an ICE type t end type contains function f() result(t) character(3) :: c c = 'abc' end end The back trace is * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x7fff206945d2 libsystem_platform.dylib`_platform_strlen + 18 frame #1: 0x000100e99509 f951`get_identifier(text=0x) at stringpool.c:95:32 frame #2: 0x00010012b302 f951`::build_function_decl(gfc_symbol *, bool) [inlined] gfc_sym_identifier(sym=) at trans-decl.c:366:10 frame #3: 0x00010012b2d5 f951`::build_function_decl(sym=0x00014331e0b0, global=) frame #4: 0x000100139a3b f951`gfc_generate_function_code(gfc_namespace*) [inlined] gfc_create_function_decl(global=, ns=0x00014403da00) at trans-decl.c:3082:23 frame #5: 0x000100139a2d f951`gfc_generate_function_code(gfc_namespace*) [inlined] gfc_generate_contained_functions(parent=0x000144038e00) frame #6: 0x000100139a03 f951`gfc_generate_function_code(ns=0x000144038e00) frame #7: 0x0001000b04c4 f951`gfc_parse_file() at parse.c:6354:25 frame #8: 0x0001001049bc f951`::gfc_be_parse_file() at f95-lang.c:212:18 frame #9: 0x000100ea0264 f951`::compile_file() at toplev.c:457:25 frame #10: 0x0001016597cf f951`toplev::main(int, char**) at toplev.c:2201:24 frame #11: 0x00010165948e f951`toplev::main(this=0x7ffeefbff09e, argc=, argv=) frame #12: 0x00010165b9e1 f951`main(argc=2, argv=0x7ffeefbff0d8) at main.c:39:22 Is the code valid?
[Bug fortran/99255] ICE in gfc_dt_upper_string, at fortran/module.c:441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c++/100135] New: ICE when using constants in a mdoule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100135
Bug ID: 100135
Summary: ICE when using constants in a mdoule
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.kox at commandoregel dot be
Target Milestone: ---
Using the following code from the book (Professional C++ 5th Edition) by Marc
Grergoire causes an ICE when trying to compile the "Employee" module.
I have 2 files:
Employee.cpp (the Interface, called Employee.cppm in the book):
===
export module employee;
import;
namespace Records {
const int DefaultStartingSalary{30'000};
export const int DefaultRaiseAndDemeritAmount{1'000};
export class Employee{
public:
Employee(const std::string& firstName, const std::string& lastName);
void promote(int raiseAmount = DefaultRaiseAndDemeritAmount);
void demote(int demeritAmount = DefaultRaiseAndDemeritAmount);
void hire();// Hires or rehires the employee
void fire();// Dismisses the employee
void display() const; // Display employee information on the console
// Getters and setters
void setFirstName(const std::string& firstName);
const std::string& getFirstName() const;
void setLastName(const std::string& lastName);
const std::string& getLastName() const;
void setEmployeeNumber(int employeeNumber);
int getEmployeeNumber()const;
void setSalary(int salary);
int getSalary()const;
bool isHired() const;
private:
std::string m_firstName;
std::string m_lastName;
int m_employeeNumber{-1};
int m_salary{DefaultStartingSalary};
bool m_hired{false};
};
}
===
And Employee-i.cpp (called Employee.cpp in the book):
===
module employee;
import;
//import ; // Not Available
using namespace std;
namespace Records {
Employee::Employee(const string& firstName, const string& lastName) :
m_firstName{firstName}, m_lastName{lastName}
{
}
void Employee::promote(int raiseAmount)
{
setSalary(getSalary() + raiseAmount);
}
void Employee::demote(int demeritAmount)
{
setSalary(getSalary() - demeritAmount);
}
void Employee::hire()
{
m_hired = true;
}
void Employee::fire()
{
m_hired = false;
}
void Employee::display() const
{
cout << "Employee: " << getLastName() << ", " << getFirstName() <<
endl;
cout << "-" << endl;
cout << (isHired() ? "Current employee" : "Former employee") << endl;
cout << "Employee number: " << getEmployeeNumber() << endl;
cout << "Salary: $" << getSalary() << endl;
cout << endl;
}
// Getters and setters
void Employee::setFirstName(const string& firstName)
{
m_firstName = firstName;
}
const string& Employee::getFirstName() const
{
return m_firstName;
}
void Employee::setLastName(const string& lastName)
{
m_lastName = lastName;
}
const string& Employee::getLastName() const
{
return m_lastName;
}
void Employee::setEmployeeNumber(int employeeNumber)
{
m_employeeNumber = employeeNumber;
}
int Employee::getEmployeeNumber() const
{
return m_employeeNumber;
}
void Employee::setSalary(int salary)
{
m_salary = salary;
}
int Employee::getSalary() const
{
return m_salary;
}
bool Employee::isHired() const
{
return m_hired;
}
}
===
Note: import ; is commented out since this module is not available yet
(the code is also modified to use the "old cout" syntax and not the new
format(""); syntax.
The error message thie causes is:
Employee.cpp:19:14: error: ‘void Records::Employee::promote(int)’ references
internal linkage entity ‘const int Records::DefaultRaiseAndDemeritAmount’
19 | void promote(int raiseAmount = DefaultRaiseAndDemeritAmount);
| ^~~
Employee.cpp:20:14: error: ‘void Records::Employee::demote(int)’ references
internal linkage entity ‘const int Records::DefaultRaiseAndDemeritAmount’
20 | void demote(int demeritAmount = DefaultRaiseAndDemeritAmount);
| ^~
Employee.cpp:15:14: error: ‘class Records::Employee’ references internal
linkage entity ‘const int Records::DefaultStartingSalary’
15 | export class Employee{
| ^~~~
Employee.cpp:4:8: error: failed to write compiled module: Bad file data
4 | export module employee;
|^~
Employee.cpp:4:8: note: compiled module file is ‘gcm.cache/employee.gcm’
In module imported at Employee-i.cpp:5:1:
employee: error: failed to read compiled module: No such file or directory
employee: note: compiled module file is ‘gcm.cache/employee.gcm’
employee: note: imports must be built before being imported
employee: fatal error: returning to the gate for a mechanical issue
comp
[Bug c++/100134] New: ICE when using a vector in a mdoule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100134
Bug ID: 100134
Summary: ICE when using a vector in a mdoule
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.kox at commandoregel dot be
Target Milestone: ---
Using the following code from the book (Professional C++ 5th Edition) by Marc
Grergoire causes an ICE when trying to compile the "Database" module.
I have 2 files:
Database.cpp (the Interface, called Database.cppm in the book):
===
export module database;
import;
import;
import employee;
namespace Records {
// const int FirstEmployeeNumber{1'000};
int FirstEmployeeNumber{1'000};
export class Database{
public:
Employee& addEmployee(const std::string& firstName, const std::string&
lastName);
Employee& getEmployee(int employeeNumber);
Employee& getEmployee(const std::string& firstName, const std::string&
lastName);
void displayAll()const;
void displayCurrent()const;
void displayFormer()const;
private:
std::vector m_employees;
int m_nextEmployeeNumber{FirstEmployeeNumber};
};
}
===
And the file Database-i.cpp (called Database.cpp in the book)
===
module database;
import;
using namespace std;
namespace Records {
Employee& Database::addEmployee(const string& firstName, const string&
lastName)
{
Employee theEmployee{firstName, lastName};
theEmployee.setEmployeeNumber(m_nextEmployeeNumber++);
theEmployee.hire();
m_employees.push_back(theEmployee);
return m_employees.back();
}
Employee& Database::getEmployee(int employeeNumber)
{
for (auto& employee : m_employees) {
if (employee.getEmployeeNumber()==employeeNumber) {
return employee;
}
}
throw logic_error{"No employee found"};
}
void Database::displayAll() const
{
for (const auto& employee : m_employees) {
employee.display();
}
}
void Database::displayCurrent() const
{
for (const auto& employee : m_employees) {
if (employee.isHired()) {
employee.display();
}
}
}
void Database::displayFormer() const
{
for (const auto& employee : m_employees) {
if (!employee.isHired( )) {
employee.display();
}
}
}
}
===
If I try to compile this module I get the following error message:
Database.cpp:4:8: internal compiler error: in add_binding_entity, at
cp/module.cc:12704
4 | export module database;
|^~
0x69ce1f depset::hash::add_binding_entity(tree_node*, WMB_Flags, void*)
../../gcc/cp/module.cc:12704
0xa3ed8c walk_module_binding(tree_node*, bitmap_head*, bool (*)(tree_node*,
WMB_Flags, void*), void*)
../../gcc/cp/name-lookup.c:3964
0xa10b58 depset::hash::add_namespace_entities(tree_node*, bitmap_head*)
../../gcc/cp/module.cc:12744
0xa29364 module_state::write(elf_out*, cpp_reader*)
../../gcc/cp/module.cc:17593
0xa2a9b8 finish_module_processing(cpp_reader*)
../../gcc/cp/module.cc:19857
0x9bdb5b c_parse_final_cleanups()
../../gcc/cp/decl2.c:5175
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/100132] Optimization breaks pointer association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Dominique d'Humieres --- Confirmed since at least GCC7.
[Bug libstdc++/100133] std::copy extremely slow for random access iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133
--- Comment #1 from 康桓瑋 ---
And the libstdc++‘s std::copy is also 8.9 times slower than the equivalent
std::tranfrom:
#include
#include
#include
const std::vector v(100, 42);
static void copy_from_vector(benchmark::State& state)
{
for (auto _ : state) {
std::vector to(v.size());
std::copy(
v.begin(), v.end(),
to.begin()
);
}
}
BENCHMARK(copy_from_vector);
static void transform_from_vector(benchmark::State& state)
{
for (auto _ : state) {
std::vector to(v.size());
std::transform(
v.begin(), v.end(),
to.begin(),
[](int x) { return x; }
);
}
}
BENCHMARK(transform_from_vector);
you can see the benchmark here:
https://quick-bench.com/q/yuGf3npWpeU2EQhzzGud-aYNlNE. If using libc++,
std::copy is 2.2 times faster than std::transform as expected, see
https://quick-bench.com/q/3_V0EaU2jxnx4kSjWdarq7FOSh0.
[Bug libstdc++/100133] New: std::copy extremely slow for random access iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133
Bug ID: 100133
Summary: std::copy extremely slow for random access iterator
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
HI, I found that libstdc++‘s std::copy is extremely slow for random access
iterator. For the following example, if libc++'s std::copy is used, copy from
std::vector will be 10 times faster than from std::list with -O3, but for
libstdc++'s std::copy, copying from std::vector is twice as slow as std::list.
#include
#include
#include
const std::vector v(100, 42);
const std::list l(100, 42);
static void copy_from_vector(benchmark::State& state)
{
for (auto _ : state) {
std::vector to(v.size());
std::copy(
v.begin(), v.end(),
to.begin()
);
}
}
BENCHMARK(copy_from_vector);
static void copy_from_list(benchmark::State& state)
{
for (auto _ : state) {
std::vector to(l.size());
std::copy(
l.begin(), l.end(),
to.begin()
);
}
}
BENCHMARK(copy_from_list);
you can see libc++‘s std::copy benchmark here:
https://quick-bench.com/q/OPrNMQpJf6jKPBT5G-Uq-4U6XHc
and libstdc++'s std::copy here:
https://quick-bench.com/q/cuKCK_VE-KJgD3xA-ogXNCj9UCQ.
