[Bug middle-end/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467 --- Comment #4 from Bernd Edlinger --- Created attachment 50778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50778=edit Proposed patch
[Bug testsuite/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
--- Comment #3 from Bernd Edlinger ---
Okay, after some debugging I see the problem.
Usually thunks are emitted from ymtab-thunks.cc:
cfun->is_thunk = 1;
insn_locations_init ();
set_curr_insn_location (DECL_SOURCE_LOCATION (thunk_fndecl));
prologue_location = curr_insn_location ();
targetm.asm_out.output_mi_thunk (asm_out_file, thunk_fndecl,
fixed_offset, virtual_value, alias);
the only other place where prologue_location is set
is in cfgexpand.c:
if (!DECL_IS_UNDECLARED_BUILTIN (current_function_decl))
{
/* Eventually, all FEs should explicitly set function_start_locus. */
if (LOCATION_LOCUS (fun->function_start_locus) == UNKNOWN_LOCATION)
set_curr_insn_location
(DECL_SOURCE_LOCATION (current_function_decl));
else
set_curr_insn_location (fun->function_start_locus);
}
else
set_curr_insn_location (UNKNOWN_LOCATION);
prologue_location = curr_insn_location ();
BUT this special "thunk" is emitted from toplev.c:
/* This must be at the end before unwind and debug info.
Some target ports emit PIC setup thunks here. */
targetm.asm_out.code_end ();
and here the prologue_location is not initialized, also the backend
does not know about it's significance.
So the source line number for this thunk is indeed wrong.
[Bug testsuite/100484] New: [12 regression] Test case gcc.dg/sso-9.c fails after r12-622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100484 Bug ID: 100484 Summary: [12 regression] Test case gcc.dg/sso-9.c fails after r12-622 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:e2bc5b6c04df820017c497a2578bd3c4c7b6c89b, r12-622 Missing error message? make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/sso-9.c" Executing on host: /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/sso-9.c -fdiagnostics-plain-output-ansi -pedantic-errors -S -o sso-9.s(timeout = 300) spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/sso-9.c -fdiagnostics-plain-output -ansi -pedantic-errors -S -o sso-9.s FAIL: gcc.dg/sso-9.c (test for errors, line 25) PASS: gcc.dg/sso-9.c (test for excess errors) testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds === gcc Summary === # of expected passes1 # of unexpected failures1 commit e2bc5b6c04df820017c497a2578bd3c4c7b6c89b (HEAD, refs/bisect/bad) Author: Eric Botcazou Date: Fri May 7 20:44:36 2021 +0200
[Bug c++/100482] namespaces as int in decltype expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100482
--- Comment #1 from Jeremy R. ---
This appears to be valid for function return types as well but the compiler
does error when decltype is used in a function parameter
namespace std{}
int A(int a) { // fine
decltype(std) b = a;
return b;
}
decltype(std) B(int a) { // fine
decltype(std) b = a;
return b;
}
auto C(int a) -> decltype(std) { // fine
decltype(std) b = a;
return b;
}
int D(decltype(std) a) { // error: expected initializer before 'a'
decltype(std) b = a;
return b;
}
[Bug c/100483] New: Extend -fno-semantic-interposition to global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
Bug ID: 100483
Summary: Extend -fno-semantic-interposition to global variables
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
int var;
int foo() { return var; }
(I implemented this for clang 11 x86)
% clang -fpic -fno-semantic-interposition -O2 -S a.c
% cat a.s
...
foo:# @foo
.Lfoo$local:
# %bb.0:# %entry
movl.Lvar$local(%rip), %eax
retq
...
var:
.Lvar$local:
.long 0 # 0x0
.size var, 4
# On x86-64, because of R_X86_64_REX_GOTPCRELX, it isn't too bad without the
optimization.
# This is more useful on other architectures without GOT optimization.
# With my clang patch https://reviews.llvm.org/D101873
% clang -target aarch64 -fpic -fno-semantic-interposition
-fno-asynchronous-unwind-tables -O2 -S a.c
% cat a.s
...
foo:// @foo
.Lfoo$local:
// %bb.0: // %entry
adrpx8, .Lvar$local
ldr w0, [x8, :lo12:.Lvar$local]
ret
[Bug c++/100482] New: namespaces as int in decltype expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100482
Bug ID: 100482
Summary: namespaces as int in decltype expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hahayes12 at tutanota dot com
Target Milestone: ---
case:
#include
int main() {
decltype(std) i{1};
std::cout << i;
}
g++ main.cpp
./a.out
1
as you can see namespaces are usable in decltype expressions and treated as
ints.
[Bug c++/100481] New: namespaces as int in decltype expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100481
Bug ID: 100481
Summary: namespaces as int in decltype expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hahayes12 at tutanota dot com
Target Milestone: ---
case:
#include
int main() {
decltype(std) i{};
std::cout << i;
}
g++ main.cpp
./a.out
1
[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100249 --- Comment #8 from 康桓瑋 --- (In reply to Patrick Palka from comment #6) > > Maybe this can help: > > > > auto&& __proj_val = std::__invoke(__proj, __val); > > if (std::__invoke(__comp, > > std::forward(__proj_val), std::__invoke(__proj, > > __lo))) > > return __lo; > > We could safely forward __proj_val only in the second invocation of __comp, > after which __proj_val is no longer used, but I'm not sure that's > worthwhile... I specifically asked the forum for this, Tim Song replied that both forwards are safe, you can see more details in https://stackoverflow.com/a/67348274/11638718. Sorry to reply so late.
[Bug web/100480] Where to file complaints re project-maintainers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480 abebeos at lazaridis dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from abebeos at lazaridis dot com --- You should not close issues that fast, especially not as "RESOLVED INVALID". One would possibly prefer to not use a public group for complaints, so, which email would this be? Additionally, this is a deficit (if not defect) of your website - other projects mention dedicated complaint emails & other channels clearly.
[Bug libstdc++/100475] semiregular-box's constructor uses wrong list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475 --- Comment #4 from 康桓瑋 --- (In reply to 康桓瑋 from comment #3) > Also, the operator->() simply uses operator& instead of std::__addressof. > > https://godbolt.org/z/zfGnEoePG Another issue is that the has_value() of this specialization will always return true, which will make the precondition __glibcxx_assert(_M_pred.has_value()) for filter_view's begin() almost useless. Although it is not clear why semiregular-box is partial specialization in gcc-11, it is obvious that this needs to be treated with care.
[Bug libstdc++/100475] semiregular-box's constructor uses wrong list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475 --- Comment #3 from 康桓瑋 --- Also, the operator->() simply uses operator& instead of std::__addressof. https://godbolt.org/z/zfGnEoePG
[Bug web/100480] Where to file complaints re project-maintainers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- The footer of the gcc.gnu.org pages says: "Comments on these web pages and the development of GCC are welcome on our developer list at g...@gcc.gnu.org."
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #58 from abebeos at lazaridis dot com --- Well, now I'm really really curious. Does the gcc project have at least some(!) liberal qualities, or will IT-fascism win? Follow-up: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480
[Bug web/100480] New: Where to file complaints re project-maintainers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480 Bug ID: 100480 Summary: Where to file complaints re project-maintainers? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: abebeos at lazaridis dot com Target Milestone: --- I would like to file a formal complain re the behavior of gcc project-maintainers and possibly leadership. Could not find any info on the website. Where do I file such a complaint?
[Bug libstdc++/100479] range adaptors handle cached iterators incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-05-07
[Bug libstdc++/100479] New: range adaptors handle cached iterators incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479
Bug ID: 100479
Summary: range adaptors handle cached iterators incorrectly
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
struct _CachedPosition<_Range>
{
private:
iterator_t<_Range> _M_iter{};
public:
constexpr bool
_M_has_value() const
{ return _M_iter != iterator_t<_Range>{}; }
constexpr iterator_t<_Range>
_M_get(const _Range&) const
{
__glibcxx_assert(_M_has_value());
return _M_iter;
}
constexpr void
_M_set(const _Range&, const iterator_t<_Range>& __it)
{
__glibcxx_assert(!_M_has_value());
_M_iter = __it;
}
};
- The domain of == for forward iterators is limited to iterators over the same
underlying sequence. While value-initialized forward iterators of the same type
may be compared against each other, comparing them against iterators into other
ranges is not required to be well-defined, so it cannot be used as a sentinel
value.
- The cache cannot be allowed to propagate when the view containing it is
copied/moved, and has to be invalidated when the view containing it is moved.
Any cached iterator points to the original underlying view, and not the new
one; also, moving from a view can change its value (if it is well-defined to
use the moved-from view), so the cache is no longer valid. (Handling this case
correctly was actually the original use case for non-propagating-cache in
range-v3.)
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #16 from CVS Commits --- The master branch has been updated by Andrew Stubbs : https://gcc.gnu.org/g:07d7d37d1a33efb04f1262e56f4b82d6e1089e75 commit r12-632-g07d7d37d1a33efb04f1262e56f4b82d6e1089e75 Author: Andrew Stubbs Date: Fri May 7 15:31:05 2021 +0100 Ensure emit_move_insn operands are valid Some architectures are fine with PLUS in move instructions, but others are not (amdgcn is the motivating example). 2021-05-07 Jakub Jelinek Andrew Stubbs gcc/ChangeLog: PR target/100418 * builtins.c (try_store_by_multiple_pieces): Use force_operand for emit_move_insn operands.
[Bug fortran/100478] Type Pointer Segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100478 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-05-07 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Maybe we need a temporary for the second pointer assignment.
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #7 from Steve Kargl --- On Fri, May 07, 2021 at 09:12:15PM +, anlauf at gcc dot gnu.org wrote: > --- Comment #6 from anlauf at gcc dot gnu.org --- > There seems to be something fishy with default initialization of function > results of derived types. There is no default initialization in the code below. default initialization is type foo integer :: i = 1 ! <-- Default initialization end tyep foo > Looking at the attached code, I guessed the > following potential reproducer: > > program p > implicit none > type multi > real, allocatable :: mp(:) > end type > type fm > type(multi) :: mfm > end type > type(fm), allocatable :: a(:,:) > integer :: n = 1 > allocate (a(n,n)) > a = mm (a, a) > a = mm (a, a) ! crashes here with -fsanitize=address > contains > function mm (ma, mb) > type(fm) :: ma(:,:), mb(:,:) > type(fm), dimension(size(ma,dim=1),size(mb,dim=2)) :: mm So, it is the size(ma,dim=1) and size(mb,dim=2) that are causing the problem.
[Bug fortran/100478] New: Type Pointer Segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100478 Bug ID: 100478 Summary: Type Pointer Segfaults Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: poorasmith at protonmail dot com Target Milestone: --- The following program segfaults (11.1.0 and 9.3.0) with "option 2" (pointer referencing itself) but works fine with "option 1" (direct reference). Both options work fine with 7.5.0. program fortranNull implicit none type myType type(myType), pointer, dimension(:) :: someType => null() end type myType type(myType), target, dimension(1) :: typeTarget type(myType), pointer, dimension(:) :: typePointer character(len=1) :: arg call get_command_argument(1, arg) if (arg .eq. '1') then write(*,*) 'Direct Assignment' typePointer => typeTarget typePointer => typeTarget(1)%someType else if (arg .eq. '2') then write(*,*) 'Referenced Assignment' typePointer => typeTarget typePointer => typePointer(1)%someType else write(*,*) 'expected either "1" or "2" command line argument' end if end program fortranNull
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #6 from anlauf at gcc dot gnu.org --- There seems to be something fishy with default initialization of function results of derived types. Looking at the attached code, I guessed the following potential reproducer: program p implicit none type multi real, allocatable :: mp(:) end type type fm type(multi) :: mfm end type type(fm), allocatable :: a(:,:) integer :: n = 1 allocate (a(n,n)) a = mm (a, a) a = mm (a, a) ! crashes here with -fsanitize=address contains function mm (ma, mb) type(fm) :: ma(:,:), mb(:,:) type(fm), dimension(size(ma,dim=1),size(mb,dim=2)) :: mm integer :: i, j do i = 1, size(ma,dim=1) do j = 1, size(mb,dim=2) print *, i, j, allocated (mm(i,j)% mfm% mp) end do end do end function mm end program p Compiling and running the program prints: 1 1 F 1 1 T The second output line should really be identical to the first one, which is confirmed by other compilers. Under Linux, setting MALLOC_PERTURB_=1 I get: 1 1 T 1 1 T Adding -fsanitize=address to the command line, I get a traceback pointing to the line commented above: 1 1 T 1 1 T Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x14c71f85649f in ??? #1 0x14c720845c36 in _ZN11__sanitizer30atomic_compare_exchange_strongINS_14atomic_uint8_tEEEbPVT_PNS2_4TypeES5_NS_12memory_orderE at ../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:80 #2 0x14c720845c36 in _ZN6__asan9Allocator38AtomicallySetQuarantineFlagIfAllocatedEPNS_9AsanChunkEPvPN11__sanitizer18BufferedStackTraceE at ../../../../gcc-trunk/libsanitizer/asan/asan_allocator.cpp:621 #3 0x14c720845c36 in _ZN6__asan9Allocator10DeallocateEPvmmPN11__sanitizer18BufferedStackTraceENS_9AllocTypeE at ../../../../gcc-trunk/libsanitizer/asan/asan_allocator.cpp:697 #4 0x14c720845c36 in _ZN6__asan9asan_freeEPvPN11__sanitizer18BufferedStackTraceENS_9AllocTypeE at ../../../../gcc-trunk/libsanitizer/asan/asan_allocator.cpp:971 #5 0x14c7208cac07 in __interceptor_free at ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:128 #6 0x401f10 in p at /home/anlauf/Downloads/pr100440-red.f90:13 #7 0x402180 in main at /home/anlauf/Downloads/pr100440-red.f90:13
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #5 from kargl at gcc dot gnu.org --- David, On amd64-*-freebsd, I see % gfcx -o z -O2 -fcheck=all allocate_error.f95 % ./z Sample 10. Eigenvalue from matrix powers. Iterationeigenvalue approximation 0 1.0 21 j= 1 allocated(FMMATMUL21_FM(J)%MFM%mp) = F allocated(FMMATMUL21_FM(J)%MFM%mp) = F At line 2499 of file allocate_error.f95 Fortran runtime error: Allocatable argument 'fmmatmul21_fm' is not allocated with a number of different options. The runtime error is expected as 'allocated(FMMATMUL21_FM(J)%MFM%mp) = F', and the print statement checking size() is not protected by an 'if' statement. valgrind shows ==8708== HEAP SUMMARY: ==8708== in use at exit: 10,737 bytes in 68 blocks ==8708== total heap usage: 170 allocs, 102 frees, 40,166 bytes allocated ==8708== ==8708== LEAK SUMMARY: ==8708==definitely lost: 0 bytes in 0 blocks ==8708==indirectly lost: 0 bytes in 0 blocks ==8708== possibly lost: 0 bytes in 0 blocks ==8708==still reachable: 10,737 bytes in 68 blocks ==8708== suppressed: 0 bytes in 0 blocks which suggests that this might be a MacOS specific bug. Note, if I comment out your print statement for diagnostics, I see % ./z Sample 10. Eigenvalue from matrix powers. Iterationeigenvalue approximation 0 1.0 124.238372093023255813953488372093023255813953488372093023260 2 .889072890369341844887411185964338107009906299229814263038M+20 3 .102214801410512542129975983352534954405105702575200225476M+43 4 .133558489514054527062720546215032551914781174136345314241M+87 5 .321140870607048831918216893831115589158773657747578318060M+175 6 .205341864155723417152215792855218285040195823798023639691M+352 7 .667355770417440618516624449043958628107088436355045114363M+705
[Bug c++/100476] coroutines: questionable handling of void get_return_object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476 --- Comment #5 from Iain Sandoe --- (In reply to Jason Merrill from comment #3) > (In reply to Jason Merrill from comment #2) > > (In reply to Iain Sandoe from comment #1) > > > I am by no means an expert at reading standardese - and it might be that > > > I'm > > > not alone, (library writers might have made the same assumption) but it > > > seems to me that: > In general, you can't construct an object from a void expression; a void > expression can't be used as an operand for anything. well, we were not trying to do that - the erroneous behaviour was treating a void return from g_r_o as meaning we should construct the return value like: retval = CoroRetType();
[Bug c++/100476] coroutines: questionable handling of void get_return_object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476 --- Comment #4 from Iain Sandoe --- great, that does simplify things - and means that a useful error can be diagnosed from a mismatched type between g_r_o/g_r_o_o_a_f and the coroutine ramp return value. The statement about phasing of the calls does mean that the expression has to be evaluated quite early (before the initial call to the actor function).
[Bug c++/100476] coroutines: questionable handling of void get_return_object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #3 from Jason Merrill ---
(In reply to Jason Merrill from comment #2)
> (In reply to Iain Sandoe from comment #1)
> > I am by no means an expert at reading standardese - and it might be that I'm
> > not alone, (library writers might have made the same assumption) but it
> > seems to me that:
> >
> > http://eel.is/c++draft/dcl.fct.def.coroutine#7
> >
> > Doe not make any specification about what get_return_object() returns,
> > only that it is possible to use it either (a) to initialise the return value
> > directly or (b) to construct a return value object from it.
>
> It says that you initialize the return value from get_return_object(), which
> sounds like
>
> return promise.get_return_object();
>
> in a non-coroutine, which is an error if get_return_object returns void.
In general, you can't construct an object from a void expression; a void
expression can't be used as an operand for anything.
struct A { };
A a1 = A(); // default-initialize
A a2 = A((void)0); // error
[Bug c++/100476] coroutines: questionable handling of void get_return_object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476 --- Comment #2 from Jason Merrill --- (In reply to Iain Sandoe from comment #1) > I am by no means an expert at reading standardese - and it might be that I'm > not alone, (library writers might have made the same assumption) but it > seems to me that: > > http://eel.is/c++draft/dcl.fct.def.coroutine#7 > > Doe not make any specification about what get_return_object() returns, > only that it is possible to use it either (a) to initialise the return value > directly or (b) to construct a return value object from it. It says that you initialize the return value from get_return_object(), which sounds like return promise.get_return_object(); in a non-coroutine, which is an error if get_return_object returns void.
[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461 H.J. Lu changed: What|Removed |Added Resolution|--- |WONTFIX Status|WAITING |RESOLVED --- Comment #7 from H.J. Lu --- (In reply to Daniel Starke from comment #6) > Thank you for the suggestion, however, I am not involved in the mingw-w64 > project. Furthermore, the fact that this regression remains against all > versions of mingw-w64 known to date does not change. It doesn't make what mingw-w64 did is correct. > It is also unclear to me why only these two intrinsics are handled > differently now. What was the purpose of this change? Do we break existing > code if the change is reverted? See PR target/99744.
[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246 --- Comment #4 from Iain Sandoe --- for the record the patch in comment #3 allowed bootstrap to succeed on Darwin12 with clang 3.4-based Xcode.
[Bug c++/100476] coroutines: questionable handling of void get_return_object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476 --- Comment #1 from Iain Sandoe --- I am by no means an expert at reading standardese - and it might be that I'm not alone, (library writers might have made the same assumption) but it seems to me that: http://eel.is/c++draft/dcl.fct.def.coroutine#7 Doe not make any specification about what get_return_object() returns, only that it is possible to use it either (a) to initialise the return value directly or (b) to construct a return value object from it.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #15 from anlauf at gcc dot gnu.org --- It also helps if you change the status to ASSIGNED... ;-)
[Bug c++/100462] g++ fails to find a generated pre-compiled header when using `-include`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 --- Comment #13 from Jakub Jelinek --- The error is clear, the header you want to include doesn't exist, which is the case. Usually people use PCH as an optimization, have the header normally in search path and have there also the precompiled version of that header. If it can be used, it is, otherwise it is parsed normally. You chose to not have the header in search path, so when it is not successufully used as PCH, it isn't found. But to mention that in the diagnostic the compiler would need to for all missing headers search again for PCH headers. That doesn't look like a good idea to me.
[Bug c++/100462] g++ fails to find a generated pre-compiled header when using `-include`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 --- Comment #12 from Marco Trevisan --- Well, I see... At least the error should be a bit clearer though.
[Bug c++/100462] g++ fails to find a generated pre-compiled header when using `-include`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #11 from Jakub Jelinek --- And that is documented to behave that way. The PCH header must be the first header that contains any tokens. PCH works by dumping the compiler state after compiling the header, and at #include line if found restores that state from the *.gch file. So, there can't be any state before that, it would be lost. And the macros and important options need to match.
[Bug c++/100462] g++ fails to find a generated pre-compiled header when using `-include`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 Marco Trevisan changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #10 from Marco Trevisan --- (In reply to Jakub Jelinek from comment #9) > certainly contains lots of tokens, so you can't expect PCH to work > after including that header. It needs to go before that. Could be any include... The point here is that any `-include` in command line breaks pch.
[Bug c++/100462] g++ fails to find a generated pre-compiled header when using `-include`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #9 from Jakub Jelinek --- certainly contains lots of tokens, so you can't expect PCH to work after including that header. It needs to go before that.
[Bug target/87839] [9 Regression] ICE in final_scan_insn_1, at final.c:3070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87839 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3488242b9a949ebc55b4a857380f94506f90ff76 commit r8-10959-g3488242b9a949ebc55b4a857380f94506f90ff76 Author: Jakub Jelinek Date: Wed Nov 21 17:41:03 2018 +0100 aarch64: Fix ICE in final_scan_insn_1 [PR87839] 2021-05-07 Jakub Jelinek PR target/87839 * config/aarch64/atomics.md (aarch64_compare_and_swap): Use rIJ constraint for aarch64_plus_operand rather than rn. * gcc.target/aarch64/pr87839.c: New test.
[Bug middle-end/100477] New: Bogus -Wstringop-overflow warning on memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
Bug ID: 100477
Summary: Bogus -Wstringop-overflow warning on memset
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following test case:
#include
#include
class Container
{
public:
typedef unsigned char value_type;
typedef value_type* pointer;
typedef std::size_t size_type;
Container();
void clear();
void reserve(size_type);
size_type size() const { return _size; }
void resize(size_type n)
{
if(n == 0)
{
clear();
return;
}
if(n > _capacity)
{
reserve(n);
}
else if(_owned && n < _size)
{
std::memset(_buf + n, 0, (_size - n) * sizeof(value_type));
}
_size = n;
}
private:
pointer _buf;
size_type _size;
size_type _capacity;
int _shrinkCounter;
bool _owned;
};
void test(Container& c, int v)
{
Container::size_type position = c.size();
c.resize(position + sizeof(int));
}
$ g++ -Wall -O3 -o memset_warning.o -c memset_warning.cpp
In file included from /usr/include/string.h:519,
from /usr/include/c++/10/cstring:42,
from memset_warning.cpp:2:
In function ‘void* memset(void*, int, size_t)’,
inlined from ‘void Container::resize(Container::size_type)’ at
memset_warning.cpp:32:24,
inlined from ‘void test(Container&, int)’ at memset_warning.cpp:48:13:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:59:33: warning: ‘void*
__builtin_memset(void*, int, long unsigned int)’ specified bound
18446744073709551612 exceeds maximum object size 9223372036854775807
[-Wstringop-overflow=]
59 | return __builtin___memset_chk (__dest, __ch, __len,
| ~~~^
60 | __glibc_objsize0 (__dest));
| ~~
Here, the reported constant 18446744073709551612 is -4, which implies the
compiler is ignoring the `n < _size` check and calculates `(_size - n)` for
memset even though it will never be called.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.3.0-1ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-gDeRY6/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-gDeRY6/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1)
[Bug libstdc++/100475] semiregular-box's constructor uses wrong list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
--- Comment #2 from 康桓瑋 ---
Reduced example:
#include
struct S {
S() = default;
S(int, int) {}
S(std::initializer_list) = delete;
};
std::ranges::single_view single(std::in_place, 0, 0);
https://godbolt.org/z/d1bE8sPdd
[Bug libstdc++/100475] semiregular-box's constructor uses wrong list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475 Patrick Palka changed: What|Removed |Added Last reconfirmed||2021-05-07 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Confirmed.
[Bug c++/100462] g++ fails to find a generated pre-compiled header when using `-include`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #8 from Marco Trevisan ---
It's also relevant to say that just using
main.c:
#include "gjs_pch.h"
int main(int argc, char**argv)
{
std::string s = "Hi";
return 0;
}
fails with:
❯ g++ -I _build main.c -o main -include string
/tmp/main.c:1:10: fatal error: gjs_pch.h: No such file or directory
1 | #include "gjs_pch.h"
| ^~~
While works when not passing any `-include` to the command line
[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461 --- Comment #6 from Daniel Starke --- Thank you for the suggestion, however, I am not involved in the mingw-w64 project. Furthermore, the fact that this regression remains against all versions of mingw-w64 known to date does not change. It is also unclear to me why only these two intrinsics are handled differently now. What was the purpose of this change? Do we break existing code if the change is reverted?
[Bug c/100450] Missing ' ' space for '-E' preprocessing output, works with direct compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #9 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:e2979f8687f590461bef9f87bd997390af67312e
commit r8-10958-ge2979f8687f590461bef9f87bd997390af67312e
Author: Jakub Jelinek
Date: Fri May 7 17:48:37 2021 +0200
libcpp: Fix up pragma preprocessing [PR100450]
Since the r0-85991-ga25a8f3be322fe0f838947b679f73d6efc2a412c
https://gcc.gnu.org/legacy-ml/gcc-patches/2008-02/msg01329.html
changes, so that we handle macros inside of pragmas that should expand
macros, during preprocessing we print those pragmas token by token,
with CPP_PRAGMA printed as
fputs ("#pragma ", print.outf);
if (space)
fprintf (print.outf, "%s %s", space, name);
else
fprintf (print.outf, "%s", name);
where name is some identifier (so e.g. print
#pragma omp parallel
or
#pragma omp for
etc.). Because it ends in an identifier, we need to handle it like
an identifier (i.e. CPP_NAME) for the decision whether a space needs
to be emitted in between that #pragma whatever or #pragma whatever whatever
and following token, otherwise the attached testcase is preprocessed as
#pragma omp forreduction(+:red)
rather than
#pragma omp for reduction(+:red)
The cpp_avoid_paste function is only called for this purpose.
2021-05-07 Jakub Jelinek
PR c/100450
* lex.c (cpp_avoid_paste): Handle token1 CPP_PRAGMA like CPP_NAME.
* c-c++-common/gomp/pr100450.c: New test.
(cherry picked from commit 170c850e4bd46745e2a5130b5eb09f9fceb98416)
[Bug c/100450] Missing ' ' space for '-E' preprocessing output, works with direct compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:ec910efa1f70e3903091b23e80c5c554b4db6c9b
commit r9-9521-gec910efa1f70e3903091b23e80c5c554b4db6c9b
Author: Jakub Jelinek
Date: Fri May 7 17:48:37 2021 +0200
libcpp: Fix up pragma preprocessing [PR100450]
Since the r0-85991-ga25a8f3be322fe0f838947b679f73d6efc2a412c
https://gcc.gnu.org/legacy-ml/gcc-patches/2008-02/msg01329.html
changes, so that we handle macros inside of pragmas that should expand
macros, during preprocessing we print those pragmas token by token,
with CPP_PRAGMA printed as
fputs ("#pragma ", print.outf);
if (space)
fprintf (print.outf, "%s %s", space, name);
else
fprintf (print.outf, "%s", name);
where name is some identifier (so e.g. print
#pragma omp parallel
or
#pragma omp for
etc.). Because it ends in an identifier, we need to handle it like
an identifier (i.e. CPP_NAME) for the decision whether a space needs
to be emitted in between that #pragma whatever or #pragma whatever whatever
and following token, otherwise the attached testcase is preprocessed as
#pragma omp forreduction(+:red)
rather than
#pragma omp for reduction(+:red)
The cpp_avoid_paste function is only called for this purpose.
2021-05-07 Jakub Jelinek
PR c/100450
* lex.c (cpp_avoid_paste): Handle token1 CPP_PRAGMA like CPP_NAME.
* c-c++-common/gomp/pr100450.c: New test.
(cherry picked from commit 170c850e4bd46745e2a5130b5eb09f9fceb98416)
[Bug c/100450] Missing ' ' space for '-E' preprocessing output, works with direct compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:d7c8e6261532e7b2d16221becd5db11ded03e059
commit r10-9810-gd7c8e6261532e7b2d16221becd5db11ded03e059
Author: Jakub Jelinek
Date: Fri May 7 17:48:37 2021 +0200
libcpp: Fix up pragma preprocessing [PR100450]
Since the r0-85991-ga25a8f3be322fe0f838947b679f73d6efc2a412c
https://gcc.gnu.org/legacy-ml/gcc-patches/2008-02/msg01329.html
changes, so that we handle macros inside of pragmas that should expand
macros, during preprocessing we print those pragmas token by token,
with CPP_PRAGMA printed as
fputs ("#pragma ", print.outf);
if (space)
fprintf (print.outf, "%s %s", space, name);
else
fprintf (print.outf, "%s", name);
where name is some identifier (so e.g. print
#pragma omp parallel
or
#pragma omp for
etc.). Because it ends in an identifier, we need to handle it like
an identifier (i.e. CPP_NAME) for the decision whether a space needs
to be emitted in between that #pragma whatever or #pragma whatever whatever
and following token, otherwise the attached testcase is preprocessed as
#pragma omp forreduction(+:red)
rather than
#pragma omp for reduction(+:red)
The cpp_avoid_paste function is only called for this purpose.
2021-05-07 Jakub Jelinek
PR c/100450
* lex.c (cpp_avoid_paste): Handle token1 CPP_PRAGMA like CPP_NAME.
* c-c++-common/gomp/pr100450.c: New test.
(cherry picked from commit 170c850e4bd46745e2a5130b5eb09f9fceb98416)
[Bug c/100450] Missing ' ' space for '-E' preprocessing output, works with direct compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8482ed658ca77bfd7fc119cd62afd5b70a024500
commit r11-8371-g8482ed658ca77bfd7fc119cd62afd5b70a024500
Author: Jakub Jelinek
Date: Fri May 7 17:48:37 2021 +0200
libcpp: Fix up pragma preprocessing [PR100450]
Since the r0-85991-ga25a8f3be322fe0f838947b679f73d6efc2a412c
https://gcc.gnu.org/legacy-ml/gcc-patches/2008-02/msg01329.html
changes, so that we handle macros inside of pragmas that should expand
macros, during preprocessing we print those pragmas token by token,
with CPP_PRAGMA printed as
fputs ("#pragma ", print.outf);
if (space)
fprintf (print.outf, "%s %s", space, name);
else
fprintf (print.outf, "%s", name);
where name is some identifier (so e.g. print
#pragma omp parallel
or
#pragma omp for
etc.). Because it ends in an identifier, we need to handle it like
an identifier (i.e. CPP_NAME) for the decision whether a space needs
to be emitted in between that #pragma whatever or #pragma whatever whatever
and following token, otherwise the attached testcase is preprocessed as
#pragma omp forreduction(+:red)
rather than
#pragma omp for reduction(+:red)
The cpp_avoid_paste function is only called for this purpose.
2021-05-07 Jakub Jelinek
PR c/100450
* lex.c (cpp_avoid_paste): Handle token1 CPP_PRAGMA like CPP_NAME.
* c-c++-common/gomp/pr100450.c: New test.
(cherry picked from commit 170c850e4bd46745e2a5130b5eb09f9fceb98416)
[Bug target/88952] The asm operator modifiers for rs6000 should be documented like they are for x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952 Segher Boessenkool changed: What|Removed |Added Target|powerpc-*-* |powerpc* Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #16 from Segher Boessenkool --- I overhauled the Power machine-specific constraints documentation in e01975f97cbb. The output modifiers should not be documented like on x86. The way we do it is superior imo: you can find it, and it is in a logical place (together with the machine constraints to which they apply). For constraints and output modifiers we do not currently document (but that we *should* -- most are internal only!) please open new PRs.
[Bug middle-end/100473] O2 vs optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #3 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #2) > I think we've never claimed that -O2 stands for -O1 + specific options, > similarly to how -O1 certainly is not -O0 + lots of options (even much more > different, because if (optimize) is very common and is used in gating tests > of whole pass sets. From https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Optimize-Options.html#Optimize-Options : Not all optimizations are controlled directly by a flag. Only optimizations that have a flag are listed in this section.
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 --- Comment #1 from Nick Clifton --- Created attachment 50777 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50777=edit Proposed patch Here is a possible patch for the problem, adding a recursion limit to the demangle_path() function. Note - a variation of this bug appears to have been reported on the Ubuntu mailing lists with a different reproducer: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1925348
[Bug c++/100476] New: coroutines: questionable handling of void get_return_object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476 Bug ID: 100476 Summary: coroutines: questionable handling of void get_return_object Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jason at gcc dot gnu.org CC: iains at gcc dot gnu.org Target Milestone: --- morph_fn_to_coro includes the comment /* For class type return objects, we can attempt to construct, even if the gro is void. */ I don't see anything in the standard to allow this. Disabling that support breaks pr96749-2.C, pr94879-folly-1.C, pr94883-folly-2.C, which all have void get_return_object() and a coroutine that returns non-void. I believe this is the result of testcase reduction, not something that a user actually wrote. Munging the second of those to appease clang gives the error I expect: https://godbolt.org/z/PTbsWf8hj :50:3: error: no viable conversion from returned value of type 'void' to function return type 'n'
[Bug tree-optimization/79333] FRE/PRE do not allow folding to look at SSA defs during elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79333 --- Comment #5 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:601191b2a48cb8f4657bb2fa2270a7fde9d52e9c commit r12-617-g601191b2a48cb8f4657bb2fa2270a7fde9d52e9c Author: Christophe Lyon Date: Fri May 7 15:52:35 2021 + tree-optimization/79333 - fold stmts following SSA edges in VN copysign is only available with c99_runtime, skip ssa-fre-94.c otherwise. 2021-05-07 Christophe Lyon PR tree-optimization/79333 gcc/testsuite/ * gcc.dg/tree-ssa/ssa-fre-94.c: Require c99_runtime.
[Bug libstdc++/100475] New: semiregular-box's constructor uses wrong list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475
Bug ID: 100475
Summary: semiregular-box's constructor uses wrong
list-initialization
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: ---
The specialization of semiregular-box's constructor in ranges#L166:
template
requires constructible_from<_Tp, _Args...>
constexpr explicit
__box(in_place_t, _Args&&... __args)
noexcept(is_nothrow_constructible_v<_Tp, _Args...>)
: _M_value{std::forward<_Args>(__args)...}
{ }
uses the wrong list-initialization, which will incorrectly construct the vector
with the initializer list in the following example:
#include
#include
#include
int main() {
std::ranges::single_view> single(std::in_place, 100, 0);
std::cout << single.begin()->size() << "\n";
}
https://godbolt.org/z/c88o3WzYP
[Bug c/100450] Missing ' ' space for '-E' preprocessing output, works with direct compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:170c850e4bd46745e2a5130b5eb09f9fceb98416
commit r12-616-g170c850e4bd46745e2a5130b5eb09f9fceb98416
Author: Jakub Jelinek
Date: Fri May 7 17:48:37 2021 +0200
libcpp: Fix up pragma preprocessing [PR100450]
Since the r0-85991-ga25a8f3be322fe0f838947b679f73d6efc2a412c
https://gcc.gnu.org/legacy-ml/gcc-patches/2008-02/msg01329.html
changes, so that we handle macros inside of pragmas that should expand
macros, during preprocessing we print those pragmas token by token,
with CPP_PRAGMA printed as
fputs ("#pragma ", print.outf);
if (space)
fprintf (print.outf, "%s %s", space, name);
else
fprintf (print.outf, "%s", name);
where name is some identifier (so e.g. print
#pragma omp parallel
or
#pragma omp for
etc.). Because it ends in an identifier, we need to handle it like
an identifier (i.e. CPP_NAME) for the decision whether a space needs
to be emitted in between that #pragma whatever or #pragma whatever whatever
and following token, otherwise the attached testcase is preprocessed as
#pragma omp forreduction(+:red)
rather than
#pragma omp for reduction(+:red)
The cpp_avoid_paste function is only called for this purpose.
2021-05-07 Jakub Jelinek
PR c/100450
* lex.c (cpp_avoid_paste): Handle token1 CPP_PRAGMA like CPP_NAME.
* c-c++-common/gomp/pr100450.c: New test.
[Bug target/98218] [TARGET_MMX_WITH_SSE] Miss vec_cmpmn/vcondmn expander for 64bit vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218 --- Comment #6 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:5795ec0edc30e077a9900cf3ca0a04ad8ac5ac97 commit r12-615-g5795ec0edc30e077a9900cf3ca0a04ad8ac5ac97 Author: Uros Bizjak Date: Fri May 7 17:14:34 2021 +0200 i386: Implement mmx_pblendv to optimize SSE conditional moves [PR98218] Implement mmx_pblendv to optimize V8HI, V4HI and V2SI mode conditional moves for SSE4.1 targets. 2021-05-07 Uroš Bizjak gcc/ PR target/98218 * config/i386/i386-expand.c (ix86_expand_sse_movcc): Handle V8QI, V4HI and V2SI modes. * config/i386/mmx.md (mmx_pblendvb): New insn pattern. * config/i386/sse.md (unspec): Move UNSPEC_BLENDV ... * config/i386/i386.md (unspec): ... here.
[Bug c++/93320] internal compiler error: in is_base_type, at dwarf2out.c:12987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93320
vopl at bk dot ru changed:
What|Removed |Added
CC||vopl at bk dot ru
--- Comment #7 from vopl at bk dot ru ---
Very similar ICE here. Affected versions are 9 and 10 but not 11. The problem
take place only with -g option supplied
$cat b11.cpp && echo EOFF
template
struct Generic
{
template using Api = decltype([](){});
};
template
struct Def
{
using Api = Generic::template Api<>;
};
Def d;
EOFF
$ g++ -v -g -std=c++20 b11.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/gcc-10.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/10.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 10.2.0-r5 p6'
--disable-esp --enable-libstdcxx-time --with-build-config=bootstrap-lto
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp
--disable-libada --enable-systemtap --enable-vtable-verify --with-zstd
--enable-lto --with-isl --disable-isl-version-check --enable-default-pie
--disable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (Gentoo 10.2.0-r5 p6)
COLLECT_GCC_OPTIONS='-v' '-g' '-std=c++2a' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/cc1plus -quiet -v -D_GNU_SOURCE
b11.cpp -quiet -dumpbase b11.cpp -mtune=generic -march=x86-64 -auxbase b11 -g
-std=c++2a -version -o /tmp/ccSzE9Pi.s
GNU C++17 (Gentoo 10.2.0-r5 p6) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
/usr/include
End of search list.
GNU C++17 (Gentoo 10.2.0-r5 p6) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 109a96b688365221cca69113b161e683
b11.cpp: In instantiation of 'struct Def':
b11.cpp:15:10: required from here
b11.cpp:9:8: internal compiler error: in is_base_type, at dwarf2out.c:12994
9 | struct Def
|^~~
0x5f1460 is_base_type
/usr/src/debug/sys-devel/gcc-10.2.0-r5/gcc-10.2.0/gcc/dwarf2out.c:12994
0x5f1460 is_base_type
/usr/src/debug/sys-devel/gcc-10.2.0-r5/gcc-10.2.0/gcc/dwarf2out.c:12964
0xe773ec modified_type_die
/usr/src/debug/sys-devel/gcc-10.2.0-r5/gcc-10.2.0/gcc/dwarf2out.c:13432
0xe76ce3 add_type_attribute
/usr/src/debug/sys-devel/gcc-10.2.0-r5/gcc-10.2.0/gcc/dwarf2out.c:21587
0xe71356 gen_typedef_die
/usr/src/debug/sys-devel/gcc-10.2.0-r5/gcc-10.2.0/gcc/dwarf2out.c:25406
0xe70e8a gen_decl_die
/usr/src/debug/sys-devel/gcc-10.2.0-r5/gcc-10.2.0/gcc/dwarf2out.c:26364
0xe8ce3c gen_member_die
/usr/src/debug/sys-devel/gcc-10.2.0-r5/gcc-10.2.0/gcc/dwarf2out.c:25183
0xe8ce3c gen_struct_or_union_type_die
/usr/src/debug/sys-devel/gcc-10.2.0-r5/gcc-10.2.0/gcc/dwarf2out.c:25279
0xe8ce3c gen_tagged_type_die
/usr/src/debug/sys-devel/gcc-10.2.0-r5/gcc-10.2.0/gcc/dwarf2out.c:25480
0xe7383d gen_type_die_with_usage
/usr/src/debug/sys-devel/gcc-10.2.0-r5/gcc-10.2.0/gcc/dwarf2out.c:25675
0xe731c6 gen_type_die
[Bug c++/100462] g++ fails to find a generated pre-compiled header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 --- Comment #7 from Marco Trevisan --- (In reply to Marco Trevisan from comment #6) > # Works > g++ -I _build main.c -o main -include string -include gjs_pch.h Ouch, I forgot to delete an include after pasting # Works g++ -I _build main.c -o main -include gjs_pch.h
[Bug c++/100462] g++ fails to find a generated pre-compiled header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #6 from Marco Trevisan ---
(In reply to Jakub Jelinek from comment #5)
> As documented - see
> https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html - PCH is only
> tried if no C token is seen before the #include directive (comments and
> preprocessor directives like #if/#ifdef/#define/#undef are fine, but e.g.
> #pragma is not).
> So, is #include "gjs_pch.hh" the first thing in your sources?
Well it's not because I instead was following the approach of
> This also works with -include. So yet another way to use precompiled headers,
> good for projects not designed with precompiled header files in mind, is to
> simply take most of the header files used by a project, include them from
> another header file, precompile that header file, and -include the
> precompiled header. If the header files have guards against multiple
> inclusion, they are skipped because they’ve already been included (in the
> precompiled header).
Thus, `-include` is ignored here it seems... Because it comes after another
include...
As per this I think the minimal reproducer is actually easy to have:
// main.c
int main(int argc, char**argv)
{
std::string s = "Hi";
return 0;
}
// header.h
#include
mkdir _build
g++ -c header.h -o _build/gjs_pch.h.gch
# Works
g++ -I _build main.c -o main -include string -include gjs_pch.h
# Fails
g++ -I _build main.c -o main -include string -include gjs_pch.h
cc1plus: fatal error: gjs_pch.h: No such file or directory
So, in this case I'm not sure that the pch should be ignored...
[Bug c/100473] O2 vs optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jakub Jelinek --- And git grep 'optimize > 1' gcc/config/arc/arc.c:return (optimize > 1 && !TARGET_NO_COND_EXEC); gcc/config/arc/arc.c: if (optimize > 1 && !TARGET_NO_COND_EXEC) gcc/config/i386/i386-expand.c: && optimize > 1) gcc/config/i386/i386-features.c: && TARGET_STV && TARGET_SSE2 && optimize > 1); gcc/config/mcore/mcore.c: if (optimize > 1 && blk_size > 2) gcc/config/rl78/rl78.c: if (optimize > 1) gcc/cse.c: else if (tem == 1 || optimize > 1) gcc/dce.c: return optimize > 1 && flag_dce && dbg_cnt (dce_ud); gcc/df-core.c: if (optimize > 1) gcc/early-remat.c:return optimize > 1 && NUM_POLY_INT_COEFFS > 1; gcc/ira.c: if (optimize > 1) gcc/ira.c: if (optimize > 1) gcc/tree-eh.c: if (optimize > 1) gcc/tree-ssa-sccvn.c: return flag_tree_fre != 0 && (may_iterate || optimize > 1); gcc/tree-ssa-sccvn.c: bool iterate_p = may_iterate && (optimize > 1); git grep 'optimize <= 1' gcc/df-problems.c: df_live->optional_p = (optimize <= 1); git grep 'optimize < 2' gcc/builtins.c: if (optimize < 2 || optimize_insn_for_size_p ()) gcc/cfgexpand.c: if (toplevel && optimize < 2) gcc/config/arc/arc.c: if (optimize < 2 || TARGET_NO_COND_EXEC) gcc/config/pa/pa.c: if (optimize < 2) gcc/dse.c: if (optimize < 2) gcc/expr.c: if (optimize < 2) gcc/loop-invariant.c: if (optimize < 2) gcc/tree-ssa-loop-im.c: if (optimize < 2) I think we've never claimed that -O2 stands for -O1 + specific options, similarly to how -O1 certainly is not -O0 + lots of options (even much more different, because if (optimize) is very common and is used in gating tests of whole pass sets.
[Bug c++/100465] Overloading operator+= and including filesystem causes conflicting overload compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465 --- Comment #5 from Jonathan Wakely --- As a workaround the library could use __str.append or __str.operator+=
[Bug c++/100474] New: ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100474
Bug ID: 100474
Summary: ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
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: ---
This is a very tough one that is extremely difficult to reduce, but I will try.
https://godbolt.org/z/69GsTKrxe
#include
struct S {
S(auto, auto...);
};
ranges::single_view s(ranges::in_place, {0});
/opt/compiler-explorer/libs/rangesv3/trunk/include/concepts/concepts.hpp:1076:13:
internal compiler error: in diagnose_trait_expr, at cp/constraint.cc:3706
1076 | META_IS_CONSTRUCTIBLE(T, Args...);
| ^
0x1d05ab9 internal_error(char const*, ...)
???:0
0x6b fancy_abort(char const*, int, char const*)
???:0
0x742edf diagnose_constraints(unsigned int, tree_node*, tree_node*)
???:0
0x959a35 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x6e2a4a build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0x6e3f50 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0x7f7fd8 build_aggr_init(tree_node*, tree_node*, int, int)
???:0
0x7b65f4 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x8e533d c_parse_file()
???:0
0xa65902 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #4 from David.Smith at lmu dot edu --- > Thanks for reduce this to a testcase. I don't see it attached > to this email or in bugzilla. gcc.gno.org may have stripped > the attachment (for some dumb reason). Feel free to send the >test case to me, and I make sure it gets attached to the bug > report. Ok, I will try attaching it as a zip file this time. From: sgk at troutmask dot apl.washington.edu Sent: Thursday, May 6, 2021 3:54 PM To: Smith, David Subject: [Bug fortran/100440] allocated() gives True for unallocated variable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #3 from Steve Kargl --- On Thu, May 06, 2021 at 09:31:49PM +, David.Smith at lmu dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 > > --- Comment #2 from David.Smith at lmu dot edu --- > > With neither access to the actual code nor a reduced testcase, > > it will be virtually impossible to debug this problem. > > Right, I have enclosed a small program pulled out of my real application > that displays the error. Thanks for reduce this to a testcase. I don't see it attached to this email or in bugzilla. gcc.gno.org may have stripped the attachment (for some dumb reason). Feel free to send the test case to me, and I make sure it gets attached to the bug report. > > > Does the code run with the following compiler options: > > > -O0 -fno-frontend-optimize -fcheck=all > > Yes, it compiles and runs, giving the allocate error. > > > Does the code compile without warning if you use -Wall -Wextra? > > There are many warnings, and I think they may all be ignored for this > program: > > IUNKNO = -HUGE(I_TWO)/18 > Warning: Integer division truncated to constant ‘119304647’ > > (Yes, that is what we want) > > IF (MB%MP(2) /= MUNKNO .OR. MB%MP(3) /= 1) THEN > Warning: Inequality comparison for REAL(8) > > (This is a numerical analysis application -- it knows what it is > doing when it compares reals) > > KT1 = MWA%MP(J+1) > Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) > > (ditto) > > TYPE(MULTI), SAVE, DIMENSION(LMBERN) :: MBERN > Warning: Array ‘mbern’ at (1) is larger than limit set by > ‘-fmax-stack-var-size=’, > moved from stack to static storage. > > (That's fine here) > > INTEGER :: J,JMA,JMW,N1,N2 > Warning: Unused variable ‘jma’ declared > > (I removed most of the routines in the full program to make a small > version that gives the error. Also removed some test code that uses > these 'unused' variables) > >IF (KRESLT /= 0) THEN >Warning: ‘kreslt’ may be used uninitialized in this function > > (ditto) > > > > I have attached the file "allocate_error.f95". Output (without the warnings): > > > gfortran allocate_error.f95 -o allocate_error -Wall -Wextra -O0 > -fno-frontend-optimize -fcheck=all > $ allocate_error > > > > Sample 10. Eigenvalue from matrix powers. > > Iterationeigenvalue approximation > > 0 1.0 > 21 j= 1 allocated(FMMATMUL21_FM(J)%MFM%mp) = T > size(FMMATMUL21_FM(J)%MFM%mp) =1 > allocate_error(29813,0x108292dc0) malloc: *** error for object > 0xb000: pointer being freed was not allocated > allocate_error(29813,0x108292dc0) malloc: *** set a breakpoint in > malloc_error_break to debug > > Program received signal SIGABRT: Process abort signal. > > Backtrace for this error: > #0 0x104c1ad3d > #1 0x104c1a16d > #2 0x7fff6f56042c > zsh: abort allocate_error The above malloc error suggests to me that you're possibly stepping off the end of an array. -fcheck=all should have caught that. :( -- You are receiving this mail because: You reported the bug.
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #35 from Niall Douglas --- (In reply to Jonathan Wakely from comment #34) > > Perhaps I ought to open a separate issue here, as my specific problem is > > that std::atomic<__int128>::compare_exchange_weak() is not using cmpxchg16b? > > Isn't that covered by PR 94649? That issue is definitely closer to mine, but still not the same. Still, I'll relocate this report from here to there. Thanks for pointing me at it.
[Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649 Niall Douglas changed: What|Removed |Added CC||s_gccbugzilla at nedprod dot com --- Comment #4 from Niall Douglas --- Relocating my issue from PR 80878 to here: I got bit by this GCC regression today at work. Consider https://godbolt.org/z/M9fd7nhdh where std::atomic<__int128>::compare_exchange_weak() is called with option -march=sandybridge passed to the command line: - On GCC 6.4 and earlier, this emits lock cmpxchg16b, as you would expect. - From GCC 7 up to trunk (12?), this emits __atomic_compare_exchange_16. - On clang, this emits lock cmpxchg16b, as you would expect. This is clearly a regression. GCCs before 7 did the right thing. GCCs from 7 onwards do not. clangs with libstdc++ do do the right thing. Please mark this bug as a regression affecting all versions of GCC from 7 to trunk. --- cut --- NOTE that unlike the original PR above where the struct is a UDT, I am talking here about std::atomic<__int128>::compare_exchange_weak(). It seems weird that __int128 is treated as a UDT when the CPU is perfectly capable of hardware CAS. Common feedback from this and other PRs: 1. Changing this would break ABI Firstly, I told GCC -march=sandybridge, and we know that libatomic will choose cmpxchg16b to implement __atomic_compare_exchange_16 because cpuid for sandybridge will say cmpxchg16b is supported. So, it's the same implementation for __atomic_compare_exchange_16, nothing breaks here. 2. static const std::atomic<__int128>::load() will segfault std::atomic<__int128> could examine the macro environment (__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 et al) and if only 128 bit compare and swap is available, but 128 bit atomics are not, then std::atomic<__int128> could be conditionally marked with attribute section to prevent it being stored into the read only code section. That said, I don't actually consider static const std::atomic<__int128>::load() segfaulting important enough to special case, in my opinion. 3. This was changed in GCC 7 because _Atomic is broken _Atomic is indeed broken, but I am talking about std::atomic the C++ library type here. As Mr. Wakely said in another PR: > std::atomic just calls the relevant __atomic built-in for all operations. > What the built-in does is not up to libstdc++. ... to this I would say both yes and no. __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 is not defined if the architecture relies on software emulation (libatomic) to implement 128 bit CAS. So std::atomic::compare_exchange_X() *could* examine macros for architecture and presence of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 and inline some assembler for certain architectures as a QoI measure, which is not ABI breaking because if __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 is 1, then libatomic will be choosing that same assembler in any case. Note that I refer to the CAS operation only, for load and store it's trivial to write CAS based emulations, but you could just leave those continue to call libatomic. Ultimately I probably agree that because _Atomic is broken, the compiler is not the right thing to change here. But libstdc++'s std::atomic implementation is another matter.
[Bug c++/100462] g++ fails to find a generated pre-compiled header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- As documented - see https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html - PCH is only tried if no C token is seen before the #include directive (comments and preprocessor directives like #if/#ifdef/#define/#undef are fine, but e.g. #pragma is not). So, is #include "gjs_pch.hh" the first thing in your sources?
[Bug c/100473] O2 vs optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473
--- Comment #1 from Andreas Schwab ---
$ git grep 'optimize >= 2'
gcc/ChangeLog-2008: 100 for optimize >= 2.
gcc/ChangeLog-2010: only conditionally on optimize >= 2.
gcc/ada/gcc-interface/trans.c:&& optimize >= 2
gcc/c-family/c-opts.c: optimize >= 2 && cxx_dialect >= cxx11);
gcc/config/aarch64/aarch64-cc-fusion.cc: virtual bool gate (function *) {
return TARGET_SVE && optimize >= 2; }
gcc/config/aarch64/cortex-a57-fma-steering.c: && optimize >= 2;
gcc/config/aarch64/falkor-tag-collision-avoidance.c: && optimize >=
2);
gcc/config/arm/arm.c: else if (optimize >= 2)
gcc/config/arm/arm.h: ((optimize >= 2) \
gcc/config/msp430/msp430.c: bool speed = (!optimize_size && optimize >= 2);
gcc/config/msp430/msp430.c: && (optimize >= 2 && !optimize_size
gcc/config/msp430/msp430.c: && (optimize >= 2 && !optimize_size)
gcc/config/msp430/msp430.h:#define NO_FUNCTION_CSE (optimize >= 2 &&
!optimize_size)
gcc/expr.c: && optimize >= 2
gcc/expr.c: if (SCALAR_INT_MODE_P (mode) && optimize >= 2)
gcc/opts.c: opt2 = (opts->x_optimize >= 2);
gcc/tree-ssa-dce.c: return perform_tree_ssa_dce (/*aggressive=*/optimize >=
2);
gcc/tree-ssa-loop-ivcanon.c: virtual bool gate (function *) { return optimize
>= 2; }
[Bug c++/100465] Overloading operator+= and including filesystem causes conflicting overload compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465
--- Comment #4 from Jonathan Wakely ---
Reduced:
namespace N
{
template
struct string_view
{
using char_type = C;
};
template
struct string
{
void operator+=(const string&);
template
void operator+=(const T&);
};
template
void f()
{
string s;
s += string_view();
}
} // namespace N
template
void operator+=(T1&, const T2&){}
int main()
{
N::f();
}
Clang and EDG compile this, GCC doesn't:
100465.cc: In instantiation of ‘void N::f() [with T = char]’:
100465.cc:32:14: required from here
100465.cc:22:5: error: ambiguous overload for ‘operator+=’ (operand types are
‘N::string’ and ‘N::string_view’)
22 | s += string_view();
| ~~^~~
100465.cc:15:8: note: candidate: ‘void N::string::operator+=(const T&) [with
T = N::string_view; = char; C = char]’
15 | void operator+=(const T&);
|^~~~
100465.cc:28:6: note: candidate: ‘void operator+=(T1&, const T2&) [with T1 =
N::string; T2 = N::string_view]’
28 | void operator+=(T1&, const T2&){}
| ^~~~
[Bug c++/100462] g++ fails to find a generated pre-compiled header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 --- Comment #4 from Marco Trevisan --- (In reply to Marco Trevisan from comment #3) > Created attachment 50775 [details] > strace.log > > This is crazy, as even according to strace the file isn't there... > > But it is and it's valid. > ❯ ls -lht _build/libgjs-jsapi.a.p > total 119M > -rw-rw-r-- 1 marco marco 119M mag 7 16:20 gjs_pch.hh.gch Ah, wait... The file isn't there of course, but it doesn't even try to load the precompiled `gjs_pch.hh.gch` file there...
[Bug c++/99686] ICE when using both concepts and full specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686 --- Comment #8 from Steven Sun --- under c++17 Step 4 needs `types_match == 1` [at 1] but, its value is zero, which is caused by `function_requirements_equivalent_p` [at 3] returns 0 [at 2] . [1] https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/cp/decl.c;h=316ad4c1426940bd4f51197a6297eefc24064fec;hb=HEAD#l1481 [2] https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/cp/decl.c;h=316ad4c1426940bd4f51197a6297eefc24064fec;hb=HEAD#l1052 [3] https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/cp/decl.c;h=316ad4c1426940bd4f51197a6297eefc24064fec;hb=HEAD#l944 [4] https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/cp/pt.c;h=36a8cb5df5d36337c18e1547e775b747f59a087f;hb=HEAD#l3510 In `function_requirements_equivalent_p` [at 3], the comparison is different for cxx20 and before. According to the comments, before c++20, only the combined constraints are compaired. -- By the way, for those two primary function templates in comment 1. Before cxx20, they are regard as equivalent heads [at 4] inequivalent requirements [at 3] Since cxx20, they are regard as inequivalent heads [at 4] equivalent requirements [at 3] If I change both [3], [4], forcing cxx17 using cxx20 standard, everything works. - Many invariants are broken here. They cause this bug together: A failure in requirements comparison caused no reregistration, which leads to overload between implicit instatntiation. The full specialzation is already parsed, leaving a null `cfun` state. Then it tries to instatiate the function body and everything crashes, They are all `by design` in a sense. How to fix it is not only a technical issue, but a design choice. If any senior gcc developer sees this, help me. - By the way, I don't think this bug would matter too much, since no one really uses concepts before c++20. I am just curious.
[Bug c++/100465] Overloading operator+= and including filesystem causes conflicting overload compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-05-07 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Jonathan Wakely --- The difference is this change from g:e7406c364496dae51ef294b5720923fe4a1dfccb @@ -1082,7 +1085,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 #endif if (__add_slash) __str += __slash; - __str += __elem._M_pathname; + __str += basic_string_view(__elem._M_pathname); __add_slash = __elem._M_type() == _Type::_Filename; } } Previously it was adding a std::string to a basic_string, Alloc>, which only worked if the Alloc was std::allocator. The change to use string_view is required, but results in this error. I'll try to reduce the testcase.
[Bug c++/100462] g++ fails to find a generated pre-compiled header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 --- Comment #3 from Marco Trevisan --- Created attachment 50775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50775=edit strace.log This is crazy, as even according to strace the file isn't there... But it is and it's valid. ❯ ls -lht _build/libgjs-jsapi.a.p total 119M -rw-rw-r-- 1 marco marco 119M mag 7 16:20 gjs_pch.hh.gch [pid 1168435] openat(AT_FDCWD, "./gjs_pch.hh", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory) [pid 1168435] openat(AT_FDCWD, "libgjs.so.0.0.0.p/gjs_pch.hh", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory) [pid 1168435] openat(AT_FDCWD, "../gjs_pch.hh", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory) [pid 1168435] openat(AT_FDCWD, "/opt/dev/GNOME/include/glib-2.0/gjs_pch.hh", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory) [pid 1168435] openat(AT_FDCWD, "/opt/dev/GNOME/lib/glib-2.0/include/gjs_pch.hh", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory) [pid 1168435] openat(AT_FDCWD, "/opt/dev/GNOME/include/gobject-introspection-1.0/gjs_pch.hh", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory) [pid 1168435] openat(AT_FDCWD, "/opt/dev/GNOME/include/pixman-1/gjs_pch.hh", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory) Same is also running manually (with CWD in _build directory): strace -f g++ -v -Ilibgjs-jsapi.a.p -I. -I.. -I/opt/dev/GNOME/include/glib-2.0 -I/opt/dev/GNOME/lib/glib-2.0/include -I/opt/dev/GNOME/include/gobject-introspection-1.0 -I/opt/dev/GNOME/include/pixman-1 -I/usr/include/cairo -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -std=c++17 -fno-rtti -g -fno-strict-aliasing -Wno-variadic-macros -Wno-missing-field-initializers -fno-semantic-interposition -fPIC -pthread -isystem/opt/dev/GNOME/include/sysprof-4 -include /usr/include/mozjs-78/js/RequiredDefines.h -isystem /usr/include/mozjs-78 -DGJS_COMPILATION '-DGJS_JS_DIR="/usr/local/share/gjs-1.0"' '-DPKGLIBDIR="/usr/local/lib/x86_64-linux-gnu/gjs"' '-DG_LOG_DOMAIN="Gjs"' -fpch-preprocess -include gjs_pch.hh -MD -MQ libgjs-jsapi.a.p/gjs_jsapi-dynamic-class.cpp.o -MF libgjs-jsapi.a.p/gjs_jsapi-dynamic-class.cpp.o.d -o libgjs-jsapi.a.p/gjs_jsapi-dynamic-class.cpp.o -c ../gjs/jsapi-dynamic-class.cpp
[Bug c++/100465] Overloading operator+= and including filesystem causes conflicting overload compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465 --- Comment #2 from Jonathan Wakely --- Maybe another case of PR 51577 but I haven't looked into it yet. I will say that a templated operator in the global namespace with absolutely no constraints to limit what it accepts is a very bad idea.
[Bug target/99808] [8/9/10/11 Regression] ICE in as_a, at machmode.h:365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99808 --- Comment #14 from CVS Commits --- The releases/gcc-8 branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:bcc4f85667c88f9be098f2671b01831d4b8d9f7c commit r8-10957-gbcc4f85667c88f9be098f2671b01831d4b8d9f7c Author: Kyrylo Tkachov Date: Tue Mar 30 14:07:50 2021 +0100 aarch64: Fix gcc.target/aarch64/pr99808.c for ILP32 Fix test for -mabi=ilp32 gcc/testsuite/ChangeLog: PR target/99808 * gcc.target/aarch64/pr99808.c: Use ULL constant suffix.
[Bug target/99808] [8/9/10/11 Regression] ICE in as_a, at machmode.h:365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99808 --- Comment #13 from CVS Commits --- The releases/gcc-9 branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:c9c429cf986c885cf90259866186849de44e1e1f commit r9-9520-gc9c429cf986c885cf90259866186849de44e1e1f Author: Kyrylo Tkachov Date: Tue Mar 30 14:07:50 2021 +0100 aarch64: Fix gcc.target/aarch64/pr99808.c for ILP32 Fix test for -mabi=ilp32 gcc/testsuite/ChangeLog: PR target/99808 * gcc.target/aarch64/pr99808.c: Use ULL constant suffix.
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #34 from Jonathan Wakely --- (In reply to Niall Douglas from comment #33) > Re: your original point, I cannot say anything about _Atomic. However, for > std::atomic<__int128>, as __int128 is not an integral type it seems That depends whether you use -std=c++NN or -std=gnu++NN > reasonable to me that its specialisation tell the compiler to not store it > in read only memory. Mark it with attribute section, give it a non-trivial > destructor, or whatever it needs. std::atomic requires T to have a trivial destructor, so the destructor is always trivial. > Perhaps I ought to open a separate issue here, as my specific problem is > that std::atomic<__int128>::compare_exchange_weak() is not using cmpxchg16b? Isn't that covered by PR 94649? std::atomic just calls the relevant __atomic built-in for all operations. What the built-in does is not up to libstdc++.
[Bug testsuite/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467 --- Comment #2 from Bernd Edlinger --- > so it is not possible to debug those functions Aehm, i meant of course it is _now_ possible
[Bug c/100473] New: O2 vs optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473 Bug ID: 100473 Summary: O2 vs optimization flags Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: stanislav.simek at siemens dot com Target Milestone: --- Hi all, May I ask you, why the object file created with option -O2 is different than with all flags (for O1 + O2) mentioned here: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html Eq. Why object generated with -O2 is different (in assembly) than object generated with: === O1 part=== -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse -fforward-propagate -fguess-branch-probability -fif-conversion -fif-conversion2 -finline-functions-called-once -fipa-modref -fipa-profile -fipa-pure-const -fipa-reference -fipa-reference-addressable -fmerge-constants -fmove-loop-invariants -fomit-frame-pointer -freorder-blocks -fshrink-wrap -fshrink-wrap-separate -fsplit-wide-types -fssa-backprop -fssa-phiopt -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-pta -ftree-scev-cprop -ftree-sink -ftree-slsr -ftree-sra -ftree-ter -funit-at-a-time === O2 part === -falign-functions -falign-jumps -falign-labels -falign-loops -fcaller-saves -fcode-hoisting -fcrossjumping -fcse-follow-jumps -fcse-skip-blocks -fdelete-null-pointer-checks -fdevirtualize -fdevirtualize-speculatively -fexpensive-optimizations -ffinite-loops -fgcse -fgcse-lm -fhoist-adjacent-loads -finline-functions -finline-small-functions -findirect-inlining -fipa-bit-cp -fipa-cp -fipa-icf -fipa-ra -fipa-sra -fipa-vrp -fisolate-erroneous-paths-dereference -flra-remat -foptimize-sibling-calls -foptimize-strlen -fpartial-inlining -fpeephole2 -freorder-blocks-algorithm=stc -freorder-blocks-and-partition -freorder-functions -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fstore-merging -fstrict-aliasing -fthread-jumps -ftree-builtin-call-dce -ftree-pre -ftree-switch-conversion -ftree-tail-merge -ftree-vrp
[Bug testsuite/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
Bernd Edlinger changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-05-07
--- Comment #1 from Bernd Edlinger ---
confirmed, I did not try to test with --target_board=unix/-m32
and the test case is unsupported on x86_64.
I'm not sure what to here,
the test case says
// Test that we don't add the x86 PC thunk to .debug_ranges
but my patch does emit a line number (if there is any) for thunks,
and of course include them in debug_ranges and debug_aranges,
so it is not possible to debug those functions where it was
previously not possible.
intersting that the LFB3 increase from 5 to 9 when I tried this:
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
b/gcc/testsuite/g++.dg/d
index 304cf45..3d5f301 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
@@ -1,9 +1,9 @@
-// Test that we don't add the x86 PC thunk to .debug_ranges
+// Test that we do add the x86 PC thunk to .debug_ranges
// { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } }
// { dg-require-effective-target fpic }
// { dg-skip-if "darwin doesn't use the thunk for PIC" { *-*-darwin* } }
// { dg-options "-g -fpic -fno-dwarf2-cfi-asm" }
-// { dg-final { scan-assembler-times "LFB3" 5 } }
+// { dg-final { scan-assembler-times "LFB3" 9 } }
template void f(T t) { }
[Bug tree-optimization/100464] [11/12 Regression] emitted binary code changes when -g is enabled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464 --- Comment #9 from Chengnian Sun --- Thanks for the tip. We will use that flag.
[Bug tree-optimization/100464] [11/12 Regression] emitted binary code changes when -g is enabled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464 --- Comment #8 from Jakub Jelinek --- gcc has the -fcompare-debug option, which compiles twice, once with -g and once with -g -gtoggle and compares result, anything that fails with that option with an error about debug vs. non-debug differences or potential differences is a bug.
[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347 --- Comment #16 from Iain Sandoe --- (In reply to Erik Schnetter from comment #15) > One thing that e.g. changed is that there is now a newer version of Apple > Clang. XCode 12.5 is broken, with compare-debug error : see PR100340 (already reported to Apple, waiting for a response) If it's something else, please let me know how to reproduce it and we can take that up with Apple too.
[Bug tree-optimization/100464] [11/12 Regression] emitted binary code changes when -g is enabled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464 --- Comment #7 from Chengnian Sun --- (In reply to Jakub Jelinek from comment #6) > Yes. Great. Thanks. We have a bunch of such test programs. I will report them shortly.
[Bug tree-optimization/100464] [11/12 Regression] emitted binary code changes when -g is enabled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464 --- Comment #6 from Jakub Jelinek --- Yes.
[Bug tree-optimization/100464] [11/12 Regression] emitted binary code changes when -g is enabled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464 --- Comment #5 from Chengnian Sun --- I have a question. If the test program has undefined behaviors, is GCC still expected to emit the same binary code for compilation with and without debug symbols? Thanks.
[Bug c++/99686] ICE when using both concepts and full specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #7 from Steven Sun ---
After digging for two days, I think I may know what's happening inside.
Under std=c++20 and my code in comment 1, the flow when parsing a full function
specialization would be
1. Found a full specialization of function.
2. Instantiate all possible primary function templates.
3. Find the most suitable instantiation (here, the concept constrained is
chosen)
4. Then replace it with full specialization. (this is done in
`reregister_specialization` in `gcc/cp/pt.c`)
So when performing overloading in the main function, there would be one
instantiation and one full specialization to choose. (To be specific, those two
are in the hash table `decl_specialization` defined in `gcc/cp/pt.c`)
While in the c++17 mode, step 4 is broken. So there will be 2 implicit
instantiation to choose when overloading.
Step 4 is performed in the function `duplicate_decls` defined in
`gcc/cp/decl.c`.
Certain conditions must be satisfied to replace the instantiation.
The one failed here is:
"the compiler thinks the full specialization has a different concepts
constraint with primary template (because the primary template has contraints
but the full specialization doesn't)"
So the reregistration is never triggered. This is the source of the bug.
After getting the whole picture, I simplify the test case as
https://godbolt.org/z/9MM6rEf77
--- std=c++17 -fconcepts
template
requires requires(T t) { ++t; }
void func(T &)
{
}
template <>
void func(int&& arg)
{
}
int main()
{
func(1);
}
---
I'll give more details in the next comment in case any developer would like to
fix it.
[Bug middle-end/100471] #pragma omp taskloop with custom reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471 --- Comment #2 from Tom Vander Aa --- Thanks Jakub. Let me know when I can do something. -Wno-pedantic, Tom
[Bug c++/97420] [8/9/10/11/12 Regression] NTTP function reference cannot bind to noexcept function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97420 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/97420] [8/9/10/11/12 Regression] NTTP function reference cannot bind to noexcept function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97420 Patrick Palka changed: What|Removed |Added CC||frankhb1989 at gmail dot com --- Comment #4 from Patrick Palka --- *** Bug 100472 has been marked as a duplicate of this bug. ***
[Bug c++/100472] [C++17] Wrong template non-type argument handling on function reference to noexcept functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100472 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Patrick Palka --- Dup of PR97420 *** This bug has been marked as a duplicate of bug 97420 ***
[Bug c++/100472] New: [C++17] Wrong template non-type argument handling on function reference to noexcept functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100472
Bug ID: 100472
Summary: [C++17] Wrong template non-type argument handling on
function reference to noexcept functions
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
template
void h()
{}
void f() noexcept
{}
int main()
{
h();
}
g++ prog.cc -Wall -Wextra -std=c++17
prog.cc: In function 'int main()':
prog.cc:10:7: error: no matching function for call to 'h()'
10 | h();
| ^
prog.cc:2:6: note: candidate: 'template)()> void h()'
2 | void h()
| ^
prog.cc:2:6: note: template argument deduction/substitution failed:
prog.cc:10:7: error: '(void (&)())f' is not a valid template argument for type
'void (&)()'
10 | h();
| ^
prog.cc:10:7: note: it must be the name of a function with external linkage
Removing `noexcept` makes all errors disappeared. So, the real failure is from
the initialization of the template non-type parameter. This should not fail as
per the rules in [temp.arg.nontype], [dcl.init.ref] and [expr.const] (see also
N4268). Even if the conversion should have been failed, the last diagnostic
message is clearly wrong and confusing. This message comes from the conversion
performed on the template non-type argument as I see in
convert_nontype_argument_function in pt.c, and it should not occur since the
[temp.arg.nontype] changes in C++11.
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #33 from Niall Douglas ---
(In reply to Andrew Pinski from comment #31)
>
> Again the problem is stuff like:
> static const _Atomic __int128_t t = 2000;
>
> __int128_t g(void)
> {
> return t;
> }
>
> DOES NOT WORK if you use CAS (or ldaxp/stlxp).
I think we are talking about different things here. You are talking about
calling convention. I'm talking about
std::atomic<__int128>::compare_exchange_weak() i.e. that the specific member
function compare_exchange_weak() is not generating cmpxchg16b if compiled with
GCC, but does with clang.
Re: your original point, I cannot say anything about _Atomic. However, for
std::atomic<__int128>, as __int128 is not an integral type it seems reasonable
to me that its specialisation tell the compiler to not store it in read only
memory. Mark it with attribute section, give it a non-trivial destructor, or
whatever it needs.
Perhaps I ought to open a separate issue here, as my specific problem is that
std::atomic<__int128>::compare_exchange_weak() is not using cmpxchg16b? Mr.
Wakely your thoughts?
[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347 --- Comment #15 from Erik Schnetter --- When I try to rebuild GCC 10.3 or 10.2, they end up having the same problem. Also, when I enable bootstrapping, bootstrapping fails with differences in many files. Given that this used to work on a previous version of the OS, the problem isn't caused by GCC. One thing that e.g. changed is that there is now a newer version of Apple Clang. Thank you for the help and suggestions.
[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461 --- Comment #5 from H.J. Lu --- (In reply to Daniel Starke from comment #4) > Created attachment 50772 [details] > rdtsc.c > > Please find attached the mingw-w64 file. Please change #if !__has_builtin(__rdtsc) to #if !__has_builtin(__rdtsc) && !defined __rdtsc
[Bug middle-end/100471] #pragma omp taskloop with custom reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Pedantically, your testcase has UB and therefore anything can happen, because
aa variable is uninitialized and it is being incremented.
But it crashes even after fixing that (= {}), so I'll have a look.
[Bug debug/100304] [11/12 Regression] -fcompare-debug failure (length) with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100304 --- Comment #4 from Zdenek Sojka --- I can't reproduce this anymore on r12-581 ; but it still reproduces for me on the 11-branch.
[Bug target/100441] [8/9 Regression] ICE in output_constant_pool_2, at varasm.c:3955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441 Alex Coplan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Alex Coplan --- Thanks Kyrill, I can confirm it's fixed on the 8 and 9 branches for the reduced testcase.
[Bug middle-end/100471] New: #pragma omp taskloop with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471
Bug ID: 100471
Summary: #pragma omp taskloop with
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tom.vanderaa at gmail dot com
Target Milestone: ---
Created attachment 50774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50774=edit
Preprocessed source code
Code in attach contains a #pragma omp taskloop with a custom reduction
operator.
#pragma omp taskloop default(none) shared(c) reduction(ArrayPlus: aa)
It seems that the code generated for the #pragma omp is incorrect, as the code
segfaults at
0x13cea <+187>: movq %rbx, %rdx
-> 0x13ced <+190>: movzbl 0x28(%rdx), %eax
with the #pragma line above as source ref in my debugger.
Looing at taskloop_customreduce.c.007t.omplower output I'm GUESSING(!!) this
corresponds to this line (marked --->):
#pragma omp taskloop _reductemp_(D.2068) _looptemp_(D.2067)
_looptemp_(D.2066) firstprivate(D.2062) reduction(aa) default(none) private(j)
[child fn: taskloop_reduce._omp_fn.0 (.omp_data_o.2)]
{
.omp_data_i = (struct & restrict) &.omp_data_o.2;
D.2074 = .omp_data_i->D.2073;
D.2076 = .omp_data_i->D.2075;
D.2078 = .omp_data_i->D.2077;
D.2080 = .omp_data_i->D.2079;
D.2099 = __builtin_omp_get_thread_num ();
D.2100 = (sizetype) D.2099;
D.2101 = D.2100 * 64;
D.2102 = MEM[(unsigned long *)D.2074 + 16B];
D.2103 = (void *) D.2102;
D.2104 = D.2103 + D.2101;
D.2105 = D.2104;
D.2106 = D.2105 + 40;
->D.2107 = *D.2106;
if (D.2107 != 0) goto ; else goto ;
Tracing back this load through the gimple tree does not seem to lead to correct
struct.
Compile command:
gcc -v -save-temps -fdump-tree-all -O0 -g -fopenmp -o taskloop_customreduce
taskloop_customreduce.c
Tested with gcc 10.2.0 on macOS.
Tested with 9.3.0, 10.3.0 and 11.1.0 on Linux
[Bug libstdc++/100470] New: std::is_nothrow_move_constructible incorrect behavior for explicitly defaulted members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100470
Bug ID: 100470
Summary: std::is_nothrow_move_constructible incorrect behavior
for explicitly defaulted members
Product: gcc
Version: 11.1.0
URL: https://godbolt.org/z/hqeh4E3M8
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: oleksandr.koval.dev at gmail dot com
Target Milestone: ---
Explicit exception specification should be the actual one, hence, S2 should NOT
be nothrow-constructible.
#include
struct S1{
S1(S1&&) noexcept(false);
};
struct S2{
S2(S2&&) noexcept(false) = default;
};
struct S3{
S3(S3&&) noexcept(false){}
};
struct S4{
S4(S4&&) = default;
};
static_assert(!std::is_nothrow_move_constructible_v); // OK
static_assert(!std::is_nothrow_move_constructible_v); // failed
static_assert(!std::is_nothrow_move_constructible_v); // OK
static_assert(std::is_nothrow_move_constructible_v); // OK
[Bug c++/100468] set_up_extended_ref_temp via extend_ref_init_temps_1 drops TREE_ADDRESSABLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100468
--- Comment #5 from Jakub Jelinek ---
Though it is static and what you're talking about is making automatic into
static. So guess we would need automatic temporary with something like { 1, 2,
3 } initializer and have reference bind to that temporary.
My C++-fu is limited.
[Bug c++/100468] set_up_extended_ref_temp via extend_ref_init_temps_1 drops TREE_ADDRESSABLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100468
--- Comment #4 from Jakub Jelinek ---
I meant something like
struct S { constexpr S () : s (0), t (0), u(0) {} constexpr S (int x, int y,
int z) : s (x), t (y), u (z) {} int s, t, u; };
constexpr S bar () { return S (0, 1, 2); }
bool
foo (void)
{
constexpr static const S&& a = bar ();
constexpr static const S&& b = bar ();
return ==
}
int
main ()
{
if (foo ())
__builtin_abort ();
}
but haven't tried your patch to see if it triggers.
I certainly see
static const struct S & a = (const struct S &) &_ZGRZ3foovE1a_;
static struct S _ZGRZ3foovE1a_ = {.s=0, .t=1, .u=2};
static const struct S & b = (const struct S &) &_ZGRZ3foovE1b_;
static struct S _ZGRZ3foovE1b_ = {.s=0, .t=1, .u=2};
in the gimple dump and I believe the _ZGRZ3foovE1*_ vars are DECL_ARTIFICIAL.
[Bug debug/100469] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-tree-dse -fno-tree-forwprop -fno-tree-tail-merge --param=sccvn-max-alias-queries-per-access=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100469 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-05-07 Target Milestone|--- |11.2 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with my r11-7448-gff92ede8d269375f800e1b347a48f4698874b4a3 I'll have a look.
[Bug c++/100468] set_up_extended_ref_temp via extend_ref_init_temps_1 drops TREE_ADDRESSABLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100468 --- Comment #3 from rguenther at suse dot de --- On Fri, 7 May 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100468 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #2 from Jakub Jelinek --- > What I fear is that we have some temporary with a const initializer, extend > its > lifetime by taking a reference, have another temporary with the same const > initializer, extend its lifetime by taking a reference and compare the > addresses of those two references. As those are different temporaries, their > addresses should be different, shouldn't they? If you're thinking of a specific case maybe you can come up with a testcase we can add? The testsuite comes out clean with the suggested change.
