[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #28 from Andrew Pinski --- I suspect this has now been fixed with the additional of full _Float128 support in the C++ front-end and the library work.
[Bug target/65139] Improve register allocation for aarch64_*_sisd_or_int3 patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65139 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed in GCC 6: r6-2459-gad7b853a10903e
[Bug middle-end/69976] Zero the local stack on function exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 --- Comment #14 from Andrew Pinski --- There is an option now to zero out the call used registers: https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Optimize-Options.html#index-fzero-call-used-regs But there is not one for zeroing of arrays.
[Bug tree-optimization/30334] [meta-bug] Request for -Wundefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334 Andrew Pinski changed: What|Removed |Added Assignee|gdr at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #19 from Andrew Pinski --- GDR has not been active in GCC development for years now.
[Bug libgomp/109875] New: [OpenMP] nteams-var / OMP_NUM_TEAMS → ICV not passed to the device / default value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109875
Bug ID: 109875
Summary: [OpenMP] nteams-var / OMP_NUM_TEAMS → ICV not passed
to the device / default value
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Related: https://github.com/SOLLVE/sollve_vv/pull/728 and
OpenMP Spec Issue 3619.
The following is with host fallback - and I might miss something because of
this.
However, I get only a single team with the following code;
even though max_num_teams == 3.
Replacing the set_num_teams by
OMP_NUM_TEAMS=7 OMP_NUM_TEAMS_DEV=8
will yield the expected 7 for max_teams.
But it will still execute with a single team. — Using num_teams(3) as clause
will have an effect, however.
TODO:
* Check whether TEAMS = 1 makes sense for host fallback
and what the result is with actual offloading.
EXPECTED:
* The value of the ICV is honored on the device side
* Possibly, the initial value should be not 0 but a different value,
but that depends on the OpenMP Spec Issue 3619.
NOTE: While the init value is now changed, as omp_get_max_teams()
is confusingly written, just changing the default is undetectable
inside the program as only omp_get_max_teams() or display-env can be
used to determine the value - and the values returned by the latter
is not really available for consumption inside of the program.
* On the host side, the default seems to be 3, given that there is:
libgomp/teams.c:num_teams = gomp_nteams_var ? gomp_nteams_var : 3;
It seems as if get_gomp_offload_icvs sets the ICV for the device but it does
not seem to get actually get used. – At least not for host fallback.
#include
int main ()
{
int num_teams;
#if 1 // set to 0 to test the environment variables
omp_set_num_teams(2);
#pragma omp target
omp_set_num_teams(3);
#endif
__builtin_printf("max_teams: %d\n", omp_get_max_teams());
#pragma omp target teams map(tofrom: num_teams) //num_teams(4)
{
if (omp_get_team_num() == 0) {
num_teams = omp_get_num_teams();
}
}
__builtin_printf("num_teams: %d\n", num_teams);
return 0;
}
[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.5
[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741 --- Comment #16 from Jonathan Wakely --- This should be fixed on trunk now.
[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741 --- Comment #15 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:94a311abf783de754f0f1b2d4c1f00a9788e795b commit r14-918-g94a311abf783de754f0f1b2d4c1f00a9788e795b Author: Jonathan Wakely Date: Tue May 16 15:09:20 2023 +0100 libstdc++: Disable cacheline alignment for DJGPP [PR109741] DJGPP (and maybe other targets) uses MAX_OFILE_ALIGNMENT=16 which means that globals (and static objects) can't have alignment greater than 16. This causes an error for the locks defined in src/c++11/shared_ptr.cc because we try to align them to the cacheline size, to avoid false sharing. Add a configure check for the increased alignment, and live with false sharing where we can't increase the alignment. libstdc++-v3/ChangeLog: PR libstdc++/109741 * acinclude.m4 (GLIBCXX_CHECK_ALIGNAS_CACHELINE): Define. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Use GLIBCXX_CHECK_ALIGNAS_CACHELINE. * src/c++11/shared_ptr.cc (__gnu_internal::get_mutex): Do not align lock table if not supported. use __GCC_DESTRUCTIVE_SIZE instead of hardcoded 64.
[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 --- Comment #2 from Jonathan Wakely --- Tony, this is just a meta-bug that has links to the real bugs. Please either add that as a comment to an existing bug (if it's the same as one of them) or file a new bug (and set "Blocks: 97048" so that it links back here). But since your one seems to be about -Wstringop-overflow not -Wstringop-overread I don't think it is actually related to this meta-bug at all. Maybe it's related to PR 97185 instead.
[Bug fortran/109873] internal compiler error: gfc_get_symbol_decl 内、位置 fortran/trans-decl.c:1587 0x6b4c13 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1587 0x6b7157 generate_local_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109873 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Ever confirmed|0 |1 Known to fail||7.5.0, 8.5.0 Status|UNCONFIRMED |WAITING Last reconfirmed||2023-05-16 Known to work||10.4.1, 11.3.1, 12.2.1, ||13.1.1, 14.0, 9.5.0 --- Comment #1 from anlauf at gcc dot gnu.org --- This seems to be fixed in all recent versions of gfortran, see known-to-work. Can you please check?
[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048
Tony Guilfoyle changed:
What|Removed |Added
CC||tonyguil at gmail dot com
--- Comment #1 from Tony Guilfoyle ---
Source file foo.cpp:
#include
struct T
{
void* p ;
std::vector a[10] ;
} ;
void f (T& t, const std::vector& u, int i)
{
std::vector& v = t.a[i] ;
std::vector w (u.begin(), u.end()) ;
v.resize (v.size() - w.size()) ; // <-- Warning generated here
}
Command line: g++ -std=c++20 -Wall -O3 -c -o foo.obj foo.cpp
g++ --version: g++.exe (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht
Sanders) 12.2.0
Problem: Spurious warning emitted:
specified bound between 9223372036854775808 and 18446744073709551614 exceeds
maximum object size 9223372036854775807 [-Wstringop-overflow=]
[Bug target/104338] RISC-V: Subword atomics result in library calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 Patrick O'Neill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Patrick O'Neill --- Closing this issue since the fix is on trunk and was backported to releases/gcc-13 to be included in the next release.
[Bug target/104338] RISC-V: Subword atomics result in library calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 --- Comment #16 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick O'Neill : https://gcc.gnu.org/g:55088cf384d4c43e280ec794217e32fab64070ba commit r13-7336-g55088cf384d4c43e280ec794217e32fab64070ba Author: Patrick O'Neill Date: Tue Apr 18 14:33:13 2023 -0700 RISCV: Inline subword atomic ops RISC-V has no support for subword atomic operations; code currently generates libatomic library calls. This patch changes the default behavior to inline subword atomic calls (using the same logic as the existing library call). Behavior can be specified using the -minline-atomics and -mno-inline-atomics command line flags. gcc/libgcc/config/riscv/atomic.c has the same logic implemented in asm. This will need to stay for backwards compatibility and the -mno-inline-atomics flag. 2023-05-03 Patrick O'Neill gcc/ChangeLog: PR target/104338 * config/riscv/riscv-protos.h: Add helper function stubs. * config/riscv/riscv.cc: Add helper functions for subword masking. * config/riscv/riscv.opt: Add command-line flags -minline-atomics and -mno-inline-atomics. * config/riscv/sync.md: Add masking logic and inline asm for fetch_and_op, fetch_and_nand, CAS, and exchange ops. * doc/invoke.texi: Add blurb regarding new command-line flags -minline-atomics and -mno-inline-atomics. libgcc/ChangeLog: PR target/104338 * config/riscv/atomic.c: Add reference to duplicate logic. gcc/testsuite/ChangeLog: PR target/104338 * gcc.target/riscv/inline-atomics-1.c: New test. * gcc.target/riscv/inline-atomics-2.c: New test. * gcc.target/riscv/inline-atomics-3.c: New test. * gcc.target/riscv/inline-atomics-4.c: New test. * gcc.target/riscv/inline-atomics-5.c: New test. * gcc.target/riscv/inline-atomics-6.c: New test. * gcc.target/riscv/inline-atomics-7.c: New test. * gcc.target/riscv/inline-atomics-8.c: New test. Signed-off-by: Patrick O'Neill Signed-off-by: Palmer Dabbelt
[Bug c++/109871] error: call of overloaded ... is ambiguous (std::vector vs designated initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109871 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.2 --- Comment #3 from Patrick Palka --- Fixed on trunk so far.
[Bug c++/109871] error: call of overloaded ... is ambiguous (std::vector vs designated initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109871 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d5e5007c4b534391c0a97be56f6024fde1a88682 commit r14-917-gd5e5007c4b534391c0a97be56f6024fde1a88682 Author: Patrick Palka Date: Tue May 16 12:39:16 2023 -0400 c++: desig init in presence of list ctor [PR109871] add_list_candidates has logic to reject designated initialization of a non-aggregate type, but this is inadvertently being suppressed if the type has a list constructor due to the order of case analysis, which in the below testcase leads to us incorrectly treating the initializer list as if it's non-designated. This patch fixes this by making us check for invalid designated initialization sooner. PR c++/109871 gcc/cp/ChangeLog: * call.cc (add_list_candidates): Check for invalid designated initialization sooner and even for types that have a list constructor. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/desig27.C: New test.
[Bug c++/109860] ICE: in make_typename_type with redudant template in requires with typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109860
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
The following adjusted test (added 'bool') started to ICE with
r6-2674-g971e17ff87337a:
commit 971e17ff87337ad533b51c2dff0bbdf607fa1faf
Author: Andrew Sutton
Date: Fri Aug 7 05:44:49 2015 +
Add C++ Concepts TS support.
namespace t {
template
struct tuple {};
}
template
bool concept C = requires {
typename t::template tuple;
};
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Jakub Jelinek changed: What|Removed |Added Attachment #55056|0 |1 is obsolete|| --- Comment #40 from Jakub Jelinek --- Created attachment 55094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55094&action=edit gcc14-bitint-wip.patch So, on IRC we've agreed with Richi that given the limits we have in the compiler (what wide_int/widest_int can represent at most without making the types have optional arbitrary length indirect payload, what INTEGER_CST can handle (right now 255 64-bit limbs) and TYPE_PRECISION limitation (max 65535 precision)) it would be best to first try to implement _BitInt support with small BITINT_MAXWIDTH (in particular, what fits into wide_int, which is e.g. on x86_64 575 bits) and only when the implementation of that is complete, attempt to lift up some of the limits (start with the wide_int/widest_int one, INTEGER_CST could be handled by bumping the 2 counters from 8-bit to 16-bit and killing the cache, with that we'd be at 65535 as BITINT_MAXWIDTH and whether we'd want to grow it further is a question). This patch implements some WIP, as the testcases show, it can already do something, but doesn't have any of the argument/return value passing code implemented, nor middle-end needed changes (promoting as much as possible to small INTEGER_TYPEs early for small BITINT_TYPEs and adding a lowering pass which will turn the larger ones into loops etc.). Also, wb/uwb constants aren't really done yet.
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #21 from Jonathan Wakely --- Should be fixed for 11.4 and 12.4 as well.
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801 --- Comment #20 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:23e12322bc03065557d9c0ee238b5b8d7b605c02 commit r11-10777-g23e12322bc03065557d9c0ee238b5b8d7b605c02 Author: Jonathan Wakely Date: Mon Nov 28 13:28:53 2022 + libstdc++: Fix src/c++17/memory_resource for H8 targets [PR107801] This fixes compilation failures for H8 multilibs. For the normal multilib (ILP16L32?), the chunk struct does not have the expected size, because uint32_t is type long and has alignment 4 (by default). This forces sizeof(chunk) to be 12 instead of the expected 10. We can fix that by using bitset::size_type instead of uint32_t, so that we only use a 16-bit size when size_t and pointers are 16-bit types. For the IL32P16 multilibs that use -mint32, int is wider than size_t and so arithmetic expressions involving size_t promote to int. This means we need some explicit casts back to size_t. libstdc++-v3/ChangeLog: PR libstdc++/107801 * src/c++17/memory_resource.cc (chunk::_M_bytes): Change type from uint32_t to bitset::size_type. Adjust static assertion. (__pool_resource::_Pool::replenish): Cast to size_t after multiplication instead of before. (__pool_resource::_M_alloc_pools): Ensure both arguments to std::max have type size_t. (cherry picked from commit 75e562d2c4303d3918be9d1563284b0c580c5e45)
[Bug target/36603] Use \r\n for generated *.s files on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36603 Andrew Pinski changed: What|Removed |Added Host||*-mingw* *-cygwin* Status|ASSIGNED|NEW Assignee|dannysmith at users dot sourceforg |unassigned at gcc dot gnu.org |e.net | --- Comment #3 from Andrew Pinski --- Danny has not been active in GCC work for a while.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #9 from GARY.WHITE at ColoState dot edu --- Another clue. I'm seeing the same bug in gfortran-13, except that I have to use -O0 for both cases of mc11ad.f90 in or out of the contains statement. Similarly, if I put the set of va09ad.f90 routines in a module, I have to use -O0 to get correct answers. -O3 causes a bug with va09ad.f90 in a module as well.
[Bug tree-optimization/109866] Sometimes using sub/test instead just test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109866 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|tree-optimization --- Comment #4 from Andrew Pinski --- So I think forwprop could/should do this. Right now it requires c to be single use but we should detect that somehow a-b use is reverse dominated by the first use of c. Anyways this might require a rewrite of parts of forwprop ...
[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #15 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #14) > Created attachment 55092 [details] > gcc14-pr109868.patch > > I think the FE shouldn't initialize those, rather than gimplifier fixing it > up later. > In fact, I think we shouldn't initialize any unnamed bitfields, but am not > changing that, because zero initialization is supposed to clear all padding > bytes and !CONSTRUCTOR_NO_CLEARING certainly doesn't guarantee that in the > middle-end, I think we need some other CONSTRUCTOR flag and middle-end > assurance > that the padding bits are then cleared. Yes this looks better.
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801 --- Comment #19 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e6baa800897728fac40fc7153facaf3c7541ff3f commit r12-9541-ge6baa800897728fac40fc7153facaf3c7541ff3f Author: Jonathan Wakely Date: Mon Nov 28 13:28:53 2022 + libstdc++: Fix src/c++17/memory_resource for H8 targets [PR107801] This fixes compilation failures for H8 multilibs. For the normal multilib (ILP16L32?), the chunk struct does not have the expected size, because uint32_t is type long and has alignment 4 (by default). This forces sizeof(chunk) to be 12 instead of the expected 10. We can fix that by using bitset::size_type instead of uint32_t, so that we only use a 16-bit size when size_t and pointers are 16-bit types. For the IL32P16 multilibs that use -mint32, int is wider than size_t and so arithmetic expressions involving size_t promote to int. This means we need some explicit casts back to size_t. libstdc++-v3/ChangeLog: PR libstdc++/107801 * src/c++17/memory_resource.cc (chunk::_M_bytes): Change type from uint32_t to bitset::size_type. Adjust static assertion. (__pool_resource::_Pool::replenish): Cast to size_t after multiplication instead of before. (__pool_resource::_M_alloc_pools): Ensure both arguments to std::max have type size_t. (cherry picked from commit 75e562d2c4303d3918be9d1563284b0c580c5e45)
[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 --- Comment #7 from Segher Boessenkool --- > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and > GENERAL_REGS(which is the case in PR109610), hope it can also fix this > regression. That sounds more reasonable. But, why use any heuristics like this? Can't you just look at the actual costs of using mem and regs?
[Bug modula2/108344] Many tests time out: isatty called in a tight loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108344 --- Comment #5 from Gaius Mulley --- On reflection I suspect it is doubtful this is the same bug. However it might reduce the timeouts when running the regression tests.
[Bug libstdc++/104875] libstdc++-v3/src/c++11/codecvt.cc:312:24: warning: left shift count >= width of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104875 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |11.4 Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- Fixed for 11.4 now as well. I'm not going to bother with gcc-10.
[Bug libstdc++/108118] std::weak_ptr lacks a self-usurp check on move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108118 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- Fixed for 11.4, 12.3 and 13.1
[Bug libstdc++/108265] chrono::hh_mm_ss can't be constructed from unsigned durations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108265 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jonathan Wakely --- And now for 11.4 too.
[Bug modula2/108344] Many tests time out: isatty called in a tight loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108344 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2023-05-16 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #4 from Gaius Mulley --- A patch has been applied which was created as a response to another bug (on the gm2 mailing list). [A request to not open /dev/tty by default].
[Bug modula2/108344] Many tests time out: isatty called in a tight loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108344 --- Comment #3 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:cf4dcfa6727b89362494bd49e2a28ebd10d767ce commit r14-912-gcf4dcfa6727b89362494bd49e2a28ebd10d767ce Author: Gaius Mulley Date: Tue May 16 15:51:53 2023 +0100 PR modula2/108344 disable default opening of /dev/tty This patch changes removes the static initialisation code for KeyBoardLEDs.cc. The module is only initialised if one of the exported functions is called. This is useful as the module will access /dev/tty which might not be available. TimerHandler.mod has also been changed to disable the scroll lock LED as a sign of life. gcc/m2/ChangeLog: PR modula2/108344 * gm2-libs-coroutines/TimerHandler.mod (EnableLED): New constant. (Timer): Test EnableLED before switching on the scroll LED. libgm2/ChangeLog: PR modula2/108344 * libm2cor/KeyBoardLEDs.cc (initialize_module): New function. (SwitchScroll): Call initialize_module. (SwitchNum): Call initialize_module. (SwitchCaps): Call initialize_module. (SwitchLEDs): Call initialize_module. (M2EXPORT): Remove initialization code. Signed-off-by: Gaius Mulley
[Bug c++/109871] error: call of overloaded ... is ambiguous (std::vector vs designated initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109871 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/109871] error: call of overloaded ... is ambiguous (std::vector vs designated initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109871
Patrick Palka changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-05-16
Ever confirmed|0 |1
CC||ppalka at gcc dot gnu.org
--- Comment #1 from Patrick Palka ---
Confirmed, this seems to reduce to the accepts-invalid testcase:
#include
struct vector {
vector(std::initializer_list); // #1
vector(int); // #2
};
void f(vector);
int main() {
f({.blah = 1}); // incorrectly accepted and resolves to #2
}
Not a regression.
[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 Scot Breitenfeld changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 --- Comment #6 from Scot Breitenfeld --- Thanks for the standard reference. That is indeed what I was looking for. I understand now that, in this case, the INTENT refers to whether C_PTR can be changed and does not relate to the INTENT state of the target. I should change all my usage cases to INTENT(IN) since none of the Fortran wrappers allow changes to the pointer itself.
[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982 --- Comment #11 from Scot Breitenfeld --- Thanks for the standard reference. That is indeed what I was looking for. I understand now that, in this case, the INTENT refers to whether C_PTR can be changed and does not relate to the INTENT state of the target. I should change all my usage cases to INTENT(IN) since none of the Fortran wrappers allow changes to the pointer itself.
[Bug libstdc++/109816] [13/14 Regression] r14-321 fix for PR108969 breaks NVPTX offloading due to __asm (".globl _ZSt21ios_base_library_initv")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Tobias Burnus --- FIXED on mainline (GCC 14) and on the GCC 13 branch (13.1.1). The issue also exists on previous branches, but only since GCC 13's 'asm' use on 'iostream' [PR108969], it became widely exposed to users. Hence, the fix was only applied to the such affected branches.
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801 --- Comment #18 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:047c0fae82ca1458339e7e9724d125d30b685898 commit r11-10776-g047c0fae82ca1458339e7e9724d125d30b685898 Author: Jonathan Wakely Date: Tue Nov 22 09:53:36 2022 + libstdc++: Fix pool resource build errors for H8 [PR107801] The array of pool sizes was previously adjusted to work for msp430-elf which has 16-bit int and either 16-bit size_t or 20-bit size_t. The largest pool sizes were disabled unless size_t has more than 20 bits. The H8 family has 16-bit int but 32-bit size_t, which means that the largest sizes are enabled, but 1<<15 produces a negative number that then cannot be narrowed to size_t. Replace the test for 32-bit size_t with a test for 32-bit int, which means we won't use the 4kiB to 4MiB pools for targets with 16-bit int even if they have a wider size_t. libstdc++-v3/ChangeLog: PR libstdc++/107801 * src/c++17/memory_resource.cc (pool_sizes): Disable large pools for targets with 16-bit int. (cherry picked from commit 0f9659e770304d3c44cfa0e793833a461bc487aa)
[Bug libstdc++/91456] std::function and std::is_invocable_r do not understand guaranteed elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91456 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5c02a8eca7bcbe0ee021eddd5f764e8bfcb13b03 commit r11-10775-g5c02a8eca7bcbe0ee021eddd5f764e8bfcb13b03 Author: Jonathan Wakely Date: Fri Sep 23 13:28:37 2022 +0100 libstdc++: Fix std::is_nothrow_invocable_r for uncopyable prvalues [PR91456] This is the last missing piece of PR 91456. This also removes the only use of the C++11 version of std::is_nothrow_invocable. libstdc++-v3/ChangeLog: PR libstdc++/91456 * include/std/type_traits (__is_nothrow_invocable): Remove. (__is_invocable_impl::__nothrow_type): New member type which checks if the conversion can throw. (__is_nt_invocable_impl): Replace class template with alias template to __is_nt_invocable_impl::__nothrow_type. * testsuite/20_util/is_nothrow_invocable/91456.cc: New test. * testsuite/20_util/is_nothrow_convertible/value.cc: Remove macro used by value_ext.cc test. * testsuite/20_util/is_nothrow_convertible/value_ext.cc: Remove test for non-standard __is_nothrow_invocable trait. (cherry picked from commit 71c828f84572d933979468baf2cf744180258ee4)
[Bug libstdc++/104875] libstdc++-v3/src/c++11/codecvt.cc:312:24: warning: left shift count >= width of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104875 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e4b0d0b84b719ea9cd3d0a7b0668cdd8055a07d2 commit r11-10770-ge4b0d0b84b719ea9cd3d0a7b0668cdd8055a07d2 Author: Jonathan Wakely Date: Fri Mar 11 14:52:38 2022 + libstdc++: Fix reading UTF-8 characters for 16-bit targets [PR104875] The current code in read_utf8_code_point assumes that integer promotion will create a 32-bit int, but that's not true for 16-bit targets like msp430 and avr. This changes the intermediate variables used for each octet from unsigned char to char32_t, so that (c << N) works correctly when N > 8. libstdc++-v3/ChangeLog: PR libstdc++/104875 * src/c++11/codecvt.cc (read_utf8_code_point): Use char32_t to hold octets that will be left-shifted. (cherry picked from commit 8f7b7c1495f92c72da154d32317943a2cc276ca8)
[Bug libstdc++/108265] chrono::hh_mm_ss can't be constructed from unsigned durations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108265 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:126ffcee89cf3f252c0c89125a64fbe1b0b9255e commit r11-10767-g126ffcee89cf3f252c0c89125a64fbe1b0b9255e Author: Jonathan Wakely Date: Wed Jan 4 16:43:51 2023 + libstdc++: Fix std::chrono::hh_mm_ss with unsigned rep [PR108265] libstdc++-v3/ChangeLog: PR libstdc++/108265 * include/std/chrono (hh_mm_ss): Do not use chrono::abs if duration rep is unsigned. Remove incorrect noexcept-specifier. * testsuite/std/time/hh_mm_ss/1.cc: Check unsigned rep. Check floating-point representations. Check default construction. (cherry picked from commit e36e57b032b2d70eaa1294d5921e4fd8ce12a74d)
[Bug libstdc++/108118] std::weak_ptr lacks a self-usurp check on move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108118 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9578570e305e77b8c105583506781158c137f743 commit r11-10768-g9578570e305e77b8c105583506781158c137f743 Author: Jonathan Wakely Date: Thu Dec 15 09:52:48 2022 + libstdc++: Fix self-move for std::weak_ptr [PR108118] I think an alternative fix would be something like: _M_ptr = std::exchange(rhs._M_ptr, nullptr); _M_refcount = std::move(rhs._M_refcount); The standard's move-and-swap implementation generates smaller code at all levels except -O0 and -Og, so it seems simplest to just do what the standard says. libstdc++-v3/ChangeLog: PR libstdc++/108118 * include/bits/shared_ptr_base.h (weak_ptr::operator=): Implement as move-and-swap exactly as specified in the standard. * testsuite/20_util/weak_ptr/cons/self_move.cc: New test. (cherry picked from commit 92eb0adc14a5f84acce7e5bc780b81b1544b24aa)
[Bug c++/109790] [11/12/13/14 Regression] internal compiler error in write_member_name, at cp/mangle.cc:2992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109790
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #6 from Patrick Palka ---
Here's a non-lambda version that ICEs in the same spot:
struct A {
template void operator+(T);
};
template
decltype(&A::operator+) f();
int main() {
f();
}
[Bug c++/109781] [11/12/13/14 Regression] erroneous error "lambda-expression in template parameter type" for tparam lambda returning a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109781 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.4 Summary|erroneous error |[11/12/13/14 Regression] |"lambda-expression in |erroneous error |template parameter type"|"lambda-expression in |for tparam lambda returning |template parameter type" |a lambda|for tparam lambda returning ||a lambda Known to work||10.3.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99478 CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Started with r11-8166-ge1666ebd9ad31d.
[Bug target/109874] [SH] GCC 13's -Os code is 50% bigger than GCC 4's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109874 --- Comment #1 from Marc Poulhiès --- Forcing GCC 13 to emit non-PIC (as gcc4) code shaves a few insns, down to 28. ``` _SetupCartCHRMapping: mov r4,r1 mov.l .L3,r2 shlr8 r1 shlr2 r1 add #-1,r1 mov.l r1,@r2 mov r4,r1 shlr8 r1 mov.l .L4,r2 shlrr1 shlr2 r1 add #-1,r1 mov.l r1,@r2 mov r4,r1 shlr8 r1 mov.l .L5,r2 shlr2 r1 shlr2 r1 shlr8 r4 add #-1,r1 shlr2 r4 mov.l r1,@r2 shlrr4 mov.l .L6,r1 shlr2 r4 add #-1,r4 rts mov.l r4,@r1 .L3: .long _CHRmask1 .L4: .long _CHRmask2 .L5: .long _CHRmask4 .L6: .long _CHRmask8 _CHRmask8: .zero 4 _CHRmask4: .zero 4 _CHRmask2: .zero 4 _CHRmask1: .zero 4 ```
[Bug libstdc++/109857] Debian stable's tzdata 2021a has bad data that cannot be parsed by libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > This would be bad in the Debian case, because they backport changes to the > DST rules from the upstream IANA database, but for Debian stable don't > change the "version" string in tzdata.zi. This means libstdc++ will always > think the system tzdata.zi version "2021a" is older than the bundled > "2023c", even though the system file might actually have newer rules > backported from upstream. If we automatically used the bundled 2023c data we > would actually be using older data. Another consequence of the Debian stable policy is that a long-running C++ process will think it always has the latest tzdb, even if the on-disk tzdata.zi has actually been updated by apt-get. i.e. std::chrono::reload_tzdb() will never do anything. Maybe I should report this as a bug to Debian, and ask them to append some discriminator to the version string, like "2021a.1", "2021a.2" etc.
[Bug libstdc++/109857] Debian stable's tzdata 2021a has bad data that cannot be parsed by libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > We should also consider ignoring the system tzdata files if the bundled copy > (currently 2023c) is newer. This would be bad in the Debian case, because they backport changes to the DST rules from the upstream IANA database, but for Debian stable don't change the "version" string in tzdata.zi. This means libstdc++ will always think the system tzdata.zi version "2021a" is older than the bundled "2023c", even though the system file might actually have newer rules backported from upstream. If we automatically used the bundled 2023c data we would actually be using older data. So let's just go with this: > Or at least try using the bundled one if the > parsing the system file fails, as in this case. i.e. only use the bundled one as a fallback if parsing the on-disk file fails.
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713
--- Comment #10 from James Addison ---
Hi folks,
Re-stating and confirming the bugreport details here: both gcc-11 (11.3.0) and
gcc-12 (12.2.0) emit bytecode instructions that aren't supported on all
i686-architecture CPUs.
This comment includes a demonstration/repro case to help verify the problem and
potential fixes, along with a suggested remediation approach that is a small
adjustment of Adrian's original suggestion.
As a recap, partly for my own understanding: the 'endbr32' instruction required
to implement Intel Control-flow Enforcement Technology (aka Intel CET) is a
renaming and repurposing of an existing long-NOP (aka NOPL) instruction that
was not documented in the original Pentium Pro specification and therefore is
not supported on all i686-class CPUs.
### Version information
$ gcc-11 --version
gcc-11 (Debian 11.3.0-12) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-12 --version
gcc-12 (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ objdump --version
GNU objdump (GNU Binutils for Debian) 2.40
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
### Replicating the problem
$ cat repro.c
int main() {}
$ for prot in full branch return none check; do gcc-11 -m32 -march=i686
-fcf-protection=$prot -c repro.c -o gcc-11-$prot.o; gcc-12 -m32 -march=i686
-fcf-protection=$prot -c repro.c -o gcc-12-$prot.o; done;
### Checking the results
$ for binary in gcc-*.o; do echo $binary; objdump -d $binary | grep -w endbr32
; done;
gcc-11-branch.o
0: f3 0f 1e fb endbr32
gcc-11-check.o
gcc-11-full.o
0: f3 0f 1e fb endbr32
gcc-11-none.o
gcc-11-return.o
gcc-12-branch.o
0: f3 0f 1e fb endbr32
gcc-12-check.o
gcc-12-full.o
0: f3 0f 1e fb endbr32
gcc-12-none.o
gcc-12-return.o
### Remedy
Please could GCC be updated to reject attempts to build binaries for the i686
architecture when fcf-protection is configured to -- or implied to include --
'branch' protection?
Values for the fcf-protection flag were sourced from the GCC documentation at:
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fcf-protection
(as noted: this does duplicate some of the original bugreport's suggestion, but
is intended to be slightly more granular because I believe it's important to
note that not all fcf-protection values are unsupported by the i686
architecture)
[Bug target/109874] New: [SH] GCC 13's -Os code is 50% bigger than GCC 4's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109874
Bug ID: 109874
Summary: [SH] GCC 13's -Os code is 50% bigger than GCC 4's
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: paul at crapouillou dot net
Target Milestone: ---
Using the following C code snippet:
--
unsigned int CHRmask1,CHRmask2,CHRmask4,CHRmask8;
void SetupCartCHRMapping(unsigned int size)
{
#if 0
CHRmask1 = (size >> 10) - 1;
CHRmask2 = (size >> 11) - 1;
CHRmask4 = (size >> 12) - 1;
CHRmask8 = (size >> 13) - 1;
#else
size >>= 10;
CHRmask1 = size - 1;
size >>= 1;
CHRmask2 = size - 1;
size >>= 1;
CHRmask4 = size - 1;
size >>= 1;
CHRmask8 = size - 1;
#endif
}
--
Compiling with -Os, GCC 13.1 will generate the exact same code for the two
cases, as it rightfully detects that they are functionally the same:
--
_SetupCartCHRMapping:
mov.l r12,@-r15
mova.L3,r0
mov.l .L3,r12
mov r4,r1
shlr8 r1
add r0,r12
mov.l .L4,r0
shlr2 r1
add #-1,r1
mov.l r1,@(r0,r12)
mov r4,r1
shlr8 r1
mov.l .L5,r0
shlrr1
shlr2 r1
add #-1,r1
mov.l r1,@(r0,r12)
mov r4,r1
shlr8 r1
mov.l .L6,r0
shlr2 r1
shlr2 r1
shlr8 r4
add #-1,r1
shlr2 r4
mov.l r1,@(r0,r12)
shlrr4
mov.l .L7,r0
shlr2 r4
add #-1,r4
mov.l r4,@(r0,r12)
rts
mov.l @r15+,r12
.L3:
.long _GLOBAL_OFFSET_TABLE_
.L4:
.long _CHRmask1@GOTOFF
.L5:
.long _CHRmask2@GOTOFF
.L6:
.long _CHRmask4@GOTOFF
.L7:
.long _CHRmask8@GOTOFF
_CHRmask8:
.zero 4
_CHRmask4:
.zero 4
_CHRmask2:
.zero 4
_CHRmask1:
.zero 4
--
The code part (excluding labels and data fields) is 33 instructions.
GCC 4.9.4 won't detect that the two versions of the code are equivalent, and
generate different machine code for them. The second version generates the
smallest code, at only 21 instructions:
--
_SetupCartCHRMapping:
shlr8 r4
shlr2 r4
mov.l .L2,r1
mov r4,r2
add #-1,r2
mov.l r2,@r1
mov r4,r1
mov.l .L3,r2
shlrr1
add #-1,r1
mov.l r1,@r2
shlr2 r4
mov.l .L4,r1
mov r4,r2
add #-1,r2
mov.l r2,@r1
shlrr4
mov.l .L5,r1
add #-1,r4
rts
mov.l r4,@r1
.L2:
.long _CHRmask1
.L3:
.long _CHRmask2
.L4:
.long _CHRmask4
.L5:
.long _CHRmask8
--
So GCC 13.1 at -Os generates code that is 50% bigger than what GCC 4 would
generate for a functionally equivalent algorithm.
[Bug rtl-optimization/109866] Sometimes using sub/test instead just test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109866
--- Comment #3 from Andrew Pinski ---
(In reply to Uroš Bizjak from comment #1)
> (In reply to Andrew Pinski from comment #0)
> > Take:
> > ```
> > int g(void); int h(void); int t(void);
> > int f(int a, int b)
> > {
> > int c = a - b;
> > if(c == 0)
> > return g();
> > if (c > 0)
> > return h();
> > return t();
> > }
> > ```
> > This is reduced from bzip2 in spec 2006, though I am not so sure any more.
> > On x86_64 GCC produces:
> > ```
> > subl%esi, %edi
> > testl %edi, %edi
> > je .L5
> > jle .L3
> > jmp h()
> > .L3:
> > jmp t()
> > .L5:
> > jmp g()
> > ```
> > But GCC should produce (likes clang/LLVM does):
> > ```
> > cmpl%esi, %edi
> > je .L5
> > jle .L3
> > jmp h()
> > .L3:
> > jmp t()
> > .L5:
> > jmp g()
> > ```
> >
> > Note a similar thing happens with aarch64 target too.
>
> These two assemblies are not equal as demonstrated by the following test:
>
> --cut here--
> #include
>
> _Bool
> __attribute__((noinline))
> foo (int a, int b)
> {
> _Bool r;
> int tmp;
>
> asm ("subl %3, %0; testl %0, %0"
>: "=r"(tmp), "=@cc" "le"(r)
>: "0"(a), "r"(b));
> return r;
> }
>
> _Bool
> __attribute__((noinline))
> bar (int a, int b)
> {
> _Bool r;
>
> asm ("cmpl %2, %1"
>: "=@cc" "le"(r)
>: "r"(a), "r"(b));
> return r;
> }
>
> int
> main ()
> {
> int a, b;
> _Bool ra, rb;
>
> a = 0x8000, b = 0x4000;
> ra = foo (a, b);
> rb = bar (a, b);
>
> printf ("%i %i\n", ra, rb);
> return 0;
> }
> --cut here--
>
> $ ./a.out
> 0 1
>
> The difference is in handling of overflow flag.
Right but 0x8000 - 0x4000 is undefined for signed integers ...
If this was unsigned subtraction then I would say it is they are different.
Note maybe RTL level is not the best place for this optimization as subtraction
already lost if it is undefined on overflow or not ...
[Bug analyzer/109570] detect fclose on unopened or NULL files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570 Xi Ruoyao changed: What|Removed |Added URL|https://sourceware.org/pipe |https://sourceware.org/git/ |rmail/libc-alpha/2023-April |?p=glibc.git;a=commit;h=71d |/147509.html|9e0fe766a3c22a730995b9d0249 ||60970670af --- Comment #3 from Xi Ruoyao --- With the Glibc change there should be an analyzer-null-argument warning now. I guess we can close it as MOVED.
[Bug c++/109241] [12/13/14 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241 Andrew Pinski changed: What|Removed |Added CC||lozko.roma at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 109872 has been marked as a duplicate of this bug. ***
[Bug c++/109872] [12 Regression] ICE on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109872 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Yes exact dup. *** This bug has been marked as a duplicate of bug 109241 ***
[Bug libstdc++/99417] [C++17] std::variant assignment fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99417 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Version|unknown |11.0 Target Milestone|--- |12.3 --- Comment #1 from Jonathan Wakely --- I don't think this was a bug, at least not when you reported this. It was the required behaviour prior to https://wg21.link/lwg3585 In the C++17 and C++20 standards variant::operator=(const Original&) is specified as: (13.1) — If *this holds a Tj, assigns std::forward(t) to the value contained in *this. (13.2) — Otherwise, if is_nothrow_constructible_v || !is_nothrow_move_constructible_v is true, equivalent to emplace(std::forward(t)). (13.3) — Otherwise, equivalent to operator=(variant(std::forward(t))). The second bullet is why the 'noexcept' on the move ctor matters, and it means that we use the third bullet, but that won't compile because variant is not move assignable, because C is not move assignable. So libc++ and MSVC were non-conforming in accepting this. LWG 3585 changed the third bullet so that move assignment isn't needed. That was implemented for libstdc++ by r13-5661-g1395415fdc2d60 and r12-9450-ga5a03ea09ddf09.
[Bug libstdc++/109816] [13/14 Regression] r14-321 fix for PR108969 breaks NVPTX offloading due to __asm (".globl _ZSt21ios_base_library_initv")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816 --- Comment #10 from CVS Commits --- The releases/gcc-13 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:7fb7d49b3c7129fa8a6b500f260abc642929361b commit r13-7335-g7fb7d49b3c7129fa8a6b500f260abc642929361b Author: Tobias Burnus Date: Fri May 12 16:27:40 2023 +0200 LTO: Fix writing of toplevel asm with offloading [PR109816] When offloading was enabled, top-level 'asm' were added to the offloading section, confusing assemblers which did not support the syntax. Additionally, with offloading and -flto, the top-level assembler code did not end up in the host files. As r14-321-g9a41d2cdbcd added top-level 'asm' to one libstdc++ header file, the issue became more apparent, causing fails with nvptx for some C++ testcases. PR libstdc++/109816 gcc/ChangeLog: * lto-cgraph.cc (output_symtab): Guard lto_output_toplevel_asms by '!lto_stream_offload_p'. libgomp/ChangeLog: * testsuite/libgomp.c++/target-map-class-1.C: New test. * testsuite/libgomp.c++/target-map-class-2.C: New test. (cherry picked from commit a835f046cdf017b9e8ad5576df4f10daaf8420d0)
[Bug c++/109872] [12 Regression] ICE on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109872 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Dup of PR109241 ?
[Bug fortran/109873] New: internal compiler error: gfc_get_symbol_decl 内、位置 fortran/trans-decl.c:1587 0x6b4c13 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1587 0x6b7157 generate_l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109873 Bug ID: 109873 Summary: internal compiler error: gfc_get_symbol_decl 内、位置 fortran/trans-decl.c:1587 0x6b4c13 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1587 0x6b7157 generate_local_decl ../../gcc/fortran/trans-decl.c:5145 0x68320b do_traverse_symtree ../. Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kasahara at icrr dot u-tokyo.ac.jp Target Milestone: --- Nag fortran page: https://www.nag-j.co.jp/fortran/tips/tips_InteroperabilityWithC.html#FcRa 19.9 Fortran から C を呼び出す例： 文字型スカラのポインタを C から得る19.9 Fortran から C を呼び出す例： 文字型スカラのポインタを C から得る program is scalar-char-ptr_f.f90 gfortran dies when it compiles the program shown above. ifort has no error. best
[Bug rtl-optimization/109866] Sometimes using sub/test instead just test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109866 --- Comment #2 from Uroš Bizjak --- A small improvement would be: subl%esi, %edi je .L5 testl %edi, %edi jle .L3 jmp h() .L3: jmp t() .L5: jmp g() Not to mention the unoptimal handling of tail calls...
[Bug c++/109872] New: [12 Regression] ICE on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109872 Bug ID: 109872 Summary: [12 Regression] ICE on valid C++ code Product: gcc Version: 12.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lozko.roma at gmail dot com Target Milestone: --- Created attachment 55093 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55093&action=edit bug reproducer ccache 4.8 fails to compile with GCC 12.3, I've reduced it to following code (also in attachments). https://godbolt.org/z/39d1c1EE3 Test case can be compiled with just `g++-12 -c test.cpp` to reproduce. GCC 13.1 seems not affected by this as well as GCC 12.2.
[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #14 from Jakub Jelinek --- Created attachment 55092 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55092&action=edit gcc14-pr109868.patch I think the FE shouldn't initialize those, rather than gimplifier fixing it up later. In fact, I think we shouldn't initialize any unnamed bitfields, but am not changing that, because zero initialization is supposed to clear all padding bytes and !CONSTRUCTOR_NO_CLEARING certainly doesn't guarantee that in the middle-end, I think we need some other CONSTRUCTOR flag and middle-end assurance that the padding bits are then cleared.
[Bug rtl-optimization/109866] Sometimes using sub/test instead just test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109866
--- Comment #1 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #0)
> Take:
> ```
> int g(void); int h(void); int t(void);
> int f(int a, int b)
> {
> int c = a - b;
> if(c == 0)
> return g();
> if (c > 0)
> return h();
> return t();
> }
> ```
> This is reduced from bzip2 in spec 2006, though I am not so sure any more.
> On x86_64 GCC produces:
> ```
> subl%esi, %edi
> testl %edi, %edi
> je .L5
> jle .L3
> jmp h()
> .L3:
> jmp t()
> .L5:
> jmp g()
> ```
> But GCC should produce (likes clang/LLVM does):
> ```
> cmpl%esi, %edi
> je .L5
> jle .L3
> jmp h()
> .L3:
> jmp t()
> .L5:
> jmp g()
> ```
>
> Note a similar thing happens with aarch64 target too.
These two assemblies are not equal as demonstrated by the following test:
--cut here--
#include
_Bool
__attribute__((noinline))
foo (int a, int b)
{
_Bool r;
int tmp;
asm ("subl %3, %0; testl %0, %0"
: "=r"(tmp), "=@cc" "le"(r)
: "0"(a), "r"(b));
return r;
}
_Bool
__attribute__((noinline))
bar (int a, int b)
{
_Bool r;
asm ("cmpl %2, %1"
: "=@cc" "le"(r)
: "r"(a), "r"(b));
return r;
}
int
main ()
{
int a, b;
_Bool ra, rb;
a = 0x8000, b = 0x4000;
ra = foo (a, b);
rb = bar (a, b);
printf ("%i %i\n", ra, rb);
return 0;
}
--cut here--
$ ./a.out
0 1
The difference is in handling of overflow flag.
[Bug testsuite/66005] libgomp make check time is excessive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #16 from Jakub Jelinek --- Another possibility would be pick up one runtest (e.g. the first one using O_EXCL which creates some file) and let it perform all executions from that point on instead of doing the compilations, where the other runtest would feed what needs to be executed and later deleted say through a pipe. The reading through pipe would ensure that it is able to wait if there is no immediate work for it. Of course we have dg-set-env-var which complicates things a little bit, probably those would need to be transfered to the execution job together with what program should run, what options should be passed to it, what LD_LIBRARY_PATH should be used etc. One issue is make sure all the executable names are unique even at all optimization levels, we can't have target1.exe created more than once.
[Bug testsuite/66005] libgomp make check time is excessive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #14 from Thomas Schwinge --- > (In reply to Eric Gallager from comment #12) >> Note that there's a gnulib module for flock: >> https://www.gnu.org/software/gnulib/manual/html_node/flock.html > > I'd see that one -- but it also says: "the replacement function does not > really > work", so I don't think that's useful? Besides, this only provides a replacement for the system call; we'd still have to implement flock(1) ourselves and I'd rather not see us go there. > (In reply to Jakub Jelinek from comment #13) >> And fcntl in tclx. > > Seen that, too -- but is TclX something that people actually have > available/installed? (Rainer?) It's not available in packaged form on any of the targets I mentioned (Solaris, macOS, AIX). Besides, adding something like this feels quite heavy-handed to me. >> Anyway, I think choosing between flock(1) and some >> python file locking would be better than using perl which is only needed in >> maintainer mode and not otherwise. > > Rainer, would a 'python3' variant work for you? Not really: python3 isn't available on older macOS systems, and again: adding a python requirement (even for python2 in such a limited case) seems to go overboard to me. While I personally don't have a problem with requiring perl (it's needed to support shared library versioning on Solaris), the same argument applies. My strong preference would be to use Tcl core means only, thus adding no additional requirement. I found a couple of suggestions on how to do this: https://wiki.tcl-lang.org/page/How+do+I+manage+lock+files+in+a+cross+platform+manner+in+Tcl https://wiki.tcl-lang.org/page/Serializing+things+via+file+locks effectively matching Jakub's suggestion.
[Bug c++/109871] New: error: call of overloaded ... ambiguous (std::vector vs designated initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109871
Bug ID: 109871
Summary: error: call of overloaded ... ambiguous (std::vector
vs designated initializers)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gnu.ojxq8 at dralias dot com
Target Milestone: ---
When calling an overloaded function or constructor that takes a std::vector, as
well as a struct that allows designated initializers, the code is incorrectly
rejected by all versions of GCC, but accepted by Clang.
Example:
#include
struct S {};
struct Options {
int opt{};
};
void A(std::vector) {}
void A(Options) {}
int main() { A({.opt = 1}); }
Error:
: In function 'int main()':
:8:15: error: call of overloaded 'A()'
is ambiguous
8 | int main() { A({.opt = 1}); }
| ~^~~~
:6:6: note: candidate: 'void A(std::vector)'
6 | void A(std::vector) {}
| ^
:7:6: note: candidate: 'void A(Options)'
7 | void A(Options) {}
| ^
Compiler returned: 1
There is PR 59389 and PR 86997, but they seem unrelated because they are not
about designated initializers.
