[Bug lto/106700] [13 Regression] O_NONBLOCK does not exist for x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106700 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-August/ ||599959.html Status|UNCONFIRMED |NEW Last reconfirmed||2022-08-20 Ever confirmed|0 |1 Keywords||build, patch Target Milestone|--- |13.0 Component|bootstrap |lto Summary|O_NONBLOCK does not exist |[13 Regression] O_NONBLOCK |for x86_64-w64-mingw32 host |does not exist for ||x86_64-w64-mingw32 host --- Comment #1 from Andrew Pinski --- Patch to fix the issue was already submitted two days ago: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599959.html
[Bug tree-optimization/106698] `-O2 -flto` cause linker warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106698 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Component|ada |tree-optimization --- Comment #1 from Andrew Pinski --- I suspect the diagnostic code does not handle negative lower bounds arrays correctly.
[Bug bootstrap/106700] New: O_NONBLOCK does not exist for x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106700 Bug ID: 106700 Summary: O_NONBLOCK does not exist for x86_64-w64-mingw32 host Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- This breaks x86_64-w64-mingw32 host since windows does not provide O_NONBLOCK flag https://github.com/gcc-mirror/gcc/commit/3f1c2f89f6b8b8d23a9072f8549b0a2c1de06b03 It should be pipefd = open (pipe_path.c_str (), O_RDWR #if defined(O_NONBLOCK) | O_NONBLOCK #endif ); instead x86_64-w64-mingw32-g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../../../gcc/gcc -I../../../../../gcc/gcc/. -I../../../../../gcc/gcc/../include -I../../../../../gcc/gcc/../libcpp/include -I../../../../../gcc/gcc/../libcody -I/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-linux-gnu/gcc/./gmp -I/home/cqwrteur/toolchains_build/gcc/gmp -I/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-linux-gnu/gcc/./mpfr/src -I/home/cqwrteur/toolchains_build/gcc/mpfr/src -I/home/cqwrteur/toolchains_build/gcc/mpc/src -I../../../../../gcc/gcc/../libdecnumber -I../../../../../gcc/gcc/../libdecnumber/bid -I../libdecnumber -I../../../../../gcc/gcc/../libbacktrace -I/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-linux-gnu/gcc/./isl/include -I/home/cqwrteur/toolchains_build/gcc/isl/include -o vec.o -MT vec.o -MMD -MP -MF ./.deps/vec.TPo ../../../../../gcc/gcc/vec.cc ../../../../../gcc/gcc/opts-common.cc: In member function 'void jobserver_info::connect()': ../../../../../gcc/gcc/opts-common.cc:2067:49: error: 'O_NONBLOCK' was not declared in this scope 2067 | pipefd = open (pipe_path.c_str (), O_RDWR | O_NONBLOCK); | ^~ make[2]: *** [Makefile:1146: opts-common.o] Error 1 make[2]: *** Waiting for unfinished jobs rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod gcov.pod lto-dump.pod make[2]: Leaving directory '/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-linux-gnu/gcc/gcc' make[1]: *** [Makefile:4620: all-gcc] Error 2 make[1]: Leaving directory '/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-linux-gnu/gcc' make: *** [Makefile:1049: all] Error 2
[Bug libstdc++/106676] [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106676 --- Comment #1 from Egor --- I was told this is a wording defect. The `cpp17-forward-iterator` exposition-only concept in https://eel.is/c++draft/iterator.traits only permits lvalue references.
[Bug middle-end/99578] [11 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #43 from Yann Droneaud --- (In reply to Jakub Jelinek from comment #37) > Fixed on the trunk so far, temporarily by differentiating between < 4KB > addresses which are still handled like GCC 11 did for warning purposes, and > >= 4KB addresses where we won't warn anymore. As noted by Andrew Pinski in bug #106699, comment #1, one has "to use --param=min-pagesize=0 if the first 4k is valid memory" to inhibit warnings for addresses below 4096.
[Bug middle-end/99578] [11 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Andrew Pinski changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #42 from Andrew Pinski --- *** Bug 106699 has been marked as a duplicate of this bug. ***
[Bug c/106699] Since gcc 12, deferencing constant literal addresses triggers -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106699 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- You need to use --param=min-pagesize=0 if the first 4k is valid memory. See pr 99578. *** This bug has been marked as a duplicate of bug 99578 ***
[Bug c/106699] New: Since gcc 12, deferencing constant literal addresses triggers -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106699
Bug ID: 106699
Summary: Since gcc 12, deferencing constant literal addresses
triggers -Warray-bounds warning
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
Since GCC 12.1, compiling memtest86+ triggers the following warning:
In function 'find_rsdp',
inlined from 'acpi_init' at ../system/acpi.c:329:29:
../system/acpi.c:185:29: warning: array subscript 0 is outside array bounds of
'uint16_t[0]' {aka 'short unsigned int[]'} [-Warray-bounds]
185 | uintptr_t address = *(uint16_t *)0x40E << 4;
| ^~
../system/hwctrl.c: In function 'reboot':
../system/hwctrl.c:76:9: warning: array subscript 0 is outside array bounds of
'uint16_t[0]' {aka 'short unsigned int[]'} [-Warray-bounds]
76 | *((uint16_t *)0x472) = 0x1234;
| ^~~~
In function 'find_cpus_in_floating_mp_struct',
inlined from 'smp_init' at ../system/smp.c:543:39:
../system/smp.c:346:29: warning: array subscript 0 is outside array bounds of
'uint16_t[0]' {aka 'short unsigned int[]'} [-Warray-bounds]
346 | uintptr_t address = *(uint16_t *)0x40E << 4;
| ^~
Sure using integer literal as a pointer is a recipe for disaster in most cases.
But it's for a freestanding environment, a bootloader, a kernel.
So -Warray-bounds should not infer an address points to a empty array.
A minimal test case:
#include
void write(void) {
*((uint16_t *)0x472) = 0x1234;
}
uint16_t read(void) {
return *(uint16_t *)0x40E << 4;
}
https://godbolt.org/z/c9993xx41
[Bug fortran/46539] libquadmath: Add -static-libquadmath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46539
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:dd899c7de36d19ddf18e3bfab4a0c150096e2368
commit r13-2129-gdd899c7de36d19ddf18e3bfab4a0c150096e2368
Author: Jakub Jelinek
Date: Sat Aug 20 21:20:04 2022 +0200
fortran: Drop -static-lib{gfortran,quadmath} from f951 [PR46539]
As discussed earlier, all other -static-lib* options are Driver only,
these 2 are Driver in common.opt and Fortran in lang.opt.
The spec files never pass the -static-lib* options down to any compiler
(f951 etc.), so the 2 errors below are reported only when one
runs ./f951 -static-libgfortran by hand.
The following patch just removes f951 support of these options, the
gfortran driver behavior remains as before. For other -static-lib*
option (and even these because it is never passed to f951) we never
error if we can't support those options, and e.g. Darwin is actually
able to handle those options through other means.
2022-08-20 Jakub Jelinek
PR fortran/46539
* lang.opt (static-libgfortran, static-libquadmath): Change Fortran
to Driver.
* options.cc (gfc_handle_option): Don't handle
OPT_static_libgfortran
nor OPT_static_libquadmath here.
[Bug fortran/106557] nesting intrinsics ibset and transfer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106557 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-August/058077.html
[Bug ada/106698] New: `-O2 -flto` cause linker warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106698 Bug ID: 106698 Summary: `-O2 -flto` cause linker warning Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jesper.quorning at gmail dot com Target Milestone: --- Created attachment 53484 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53484=edit Minimal reproducer Building `program.ada` with optimisation -O2 or above: % gnatmake -O2 -flto main.adb Causes linker warning: ``` gcc -c -O2 -flto main.adb gcc -c -O2 -flto test.adb gnatbind -x main.ali gnatlink main.ali -O2 -flto test.adb: In function 'test__assign': test.adb:6:21: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 6 | The_Array (1) := A_Enum; | ^ test.ads:11:4: note: at offset -9223372036854775808 into destination object 'F' of size 4 11 |The_Array : T_Array; |^ ``` The program is essentially: type First_Enum is (A_Enum); subtype Second_Enum is First_Enum; type T_Array is array (Integer range -1 .. 2) of Second_Enum; -- Change 'First to something >= 0 and the warning disappears. -- Using the First_Enum instead of Second_Enum and the warning disappears. GNATMAKE 12.1.0 - cause warning GNATMAKE 11.2.0 - cause warning GNATMAKE 10.3.0 - cause no warning
[Bug fortran/106684] inconsistent array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- There is also the option to initialize the components of the derived type in the data statement, such as: data c%b, c%a / 1, 0., 1., 2., 3. / which may be less work to fix the code. Closing PR.
[Bug target/99161] Suboptimal SVE code for ld4/st4 MLA code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99161 --- Comment #1 from Andrew Pinski --- All of these patterns use ?& for the output operand but I get the feeling that the ? should be on the input operand instead.
[Bug target/106694] Redundant move instructions in ARM SVE intrinsics use cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694 Andrew Pinski changed: What|Removed |Added Depends on||99161 --- Comment #3 from Andrew Pinski --- And the same issue as PR 99161. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99161 [Bug 99161] Suboptimal SVE code for ld4/st4 MLA code
[Bug target/106694] Redundant move instructions in ARM SVE intrinsics use cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694 Andrew Pinski changed: What|Removed |Added Depends on||106146 --- Comment #2 from Andrew Pinski --- Most likely the same issue as PR 106146. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106146 [Bug 106146] a redundant movprfx insn compare to llvm
[Bug target/106694] Redundant move instructions in ARM SVE intrinsics use cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694
--- Comment #1 from Andrew Pinski ---
This is backend issue:
//(insn 27 31 28 (set (reg/v:VNx2DI 37 v5 [orig:98 v0 ] [98])
//(unspec:VNx2DI [
//(reg:VNx2BI 68 p0 [orig:105 pg ] [105])
//(plus:VNx2DI (mult:VNx2DI (reg/v:VNx2DI 37 v5 [orig:98 v0 ]
[98])
//(reg/v:VNx2DI 33 v1 [orig:96 v18 ] [96]))
//(reg/v:VNx2DI 32 v0 [orig:97 v19 ] [97]))
//(const_vector:VNx2DI repeat [
//(const_int 0 [0])
//])
//] UNSPEC_SEL)) "/app/example.c":15:14 7415 {*cond_fmavnx2di_any}
// (nil))
movprfx z5.d, p0/z, z5.d // 27 [c=4 l=8] *cond_fmavnx2di_any/2
mad z5.d, p0/m, z1.d, z0.d
[Bug target/106694] Redundant move instructions in ARM SVE intrinsics use cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694 Andrew Pinski changed: What|Removed |Added Keywords||ra Severity|normal |enhancement
[Bug c++/106648] [C++23] P2071 - Named universal character escapes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106648
Jakub Jelinek changed:
What|Removed |Added
Attachment #53478|0 |1
is obsolete||
Last reconfirmed||2022-08-20
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek ---
Created attachment 53483
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53483=edit
gcc13-pr106648.patch.xz
So far just lightly tested patch.
This handles did you mean hints using the Unicode UAX44-LM2 algorithm, but
doesn't offer fixits fot it (not sure if it is possible in libcpp) and doesn't
use spellcheck* stuff for fallback suggestions (the amount of strings and their
sizes are too huge to push them all into vector, but just walking all radix
tree nodes, computing current name as we go and at each codepoint (including
generated ones) compute Damerau-Levenshtein distance could work. But
spellcheck.{cc,h} are in gcc/ ...
[Bug c++/106567] [13 Regression] An array with a dependent type and initializer-deduced bound is treated as an array of unknown bound when captured in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567 Andrew Pinski changed: What|Removed |Added CC||johanneskauffmann at hotmail dot c ||om --- Comment #5 from Andrew Pinski --- *** Bug 106697 has been marked as a duplicate of this bug. ***
[Bug c++/106697] error: range-based 'for' expression of type 'const int []' has incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106697 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 106567. *** This bug has been marked as a duplicate of bug 106567 ***
[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94920 --- Comment #6 from Andrew Pinski --- (In reply to Paul Hua from comment #5) > > Yes, we should do. This also fails the ABS_EXPR scan-tree-dump on LoongArch. And on riscv32. I will look into that failure later this week.
[Bug c++/106696] Fallthrough between functions without proper return statement when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106696 --- Comment #4 from Andrew Pinski --- Undefined code at runtime means exactly that if you don't invoke undefined code you won't have a security issue. There are other bugs recording this same issue. Also the trunk changes behavior for -O0 to explicitly trapping so you can find the undefined code while debugging. Again also -fsanitize=undefined will detect it too.
[Bug c++/106696] Fallthrough between functions without proper return statement when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106696
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolution|FIXED |INVALID
--- Comment #3 from Jakub Jelinek ---
No, if code invokes undefined behavior, anything can happen, it is undefined
what exactly.
To help debugging, g++ 13 introduces -funreachable-traps and will emit a trap
instruction in such cases by default at -O0 or -Og (or when the user uses the
option).
Otherwise, such spots are internally handled as __builtin_unreachable, which is
a special builtin which says that it is UB to reach it. That can result in
optimizing code leading to it, e.g. if you have
void *foo (int x) { if (x < 35) return ""; }
then it can optimize away the comparison and always return "" (because anything
else is UB), similarly if a function has a switch which doesn't fall through
except for a few cases, it can assume those will not happen in a correct
program, etc.
Because of the C++ vs. C differences, -Wreturn-type warning is on by default in
C++ while it is only included in -Wall for C, users just shouldn't ignore this
warning unless it is really impossible to reach it at runtime.
[Bug c++/106696] Fallthrough between functions without proper return statement when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106696 Stefan Kneifel changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from Stefan Kneifel --- Well: the C++ frontend behaves different when it is optimizing and when it is not. IMHO this should be consistent, and it might be a security risk if arbitrary following functions are called which are coincidentally after a (maybe deliberately!) faulty one.
[Bug c++/106696] Fallthrough between functions without proper return statement when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106696 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|ipa |c++ Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- For c++ it is undefined if you fall throug out of the scope without a return if there is a non void return type. -fsanitize=undefined will detect this at runtime. In c, it is only undefined if the return value is used. After the call. This is why c and c++ frontend have different behaviors here.
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 Sven Hesse changed: What|Removed |Added CC||sven.hesse at drmccoy dot de --- Comment #17 from Sven Hesse --- I still get this with gcc 12.2.0 (Gentoo 12.2.0 p9), but only when compiling with (at least with) -O1 -fsanitize=address, in addition to any warning flag that enables -Wmaybe-uninitialized (like -Wall, -Wextra or -Wuninitialized). -O0 and/or no ASan, and the offending code compiles cleanly without any warnings. Somehow, the combination of enabling ASan and optimization (anything > -O0, but not -Os) triggers it again, it seems? I can observe this with the testcase attached here in this bug report.
[Bug c++/106697] New: error: range-based 'for' expression of type 'const int []' has incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106697
Bug ID: 106697
Summary: error: range-based 'for' expression of type 'const int
[]' has incomplete type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johanneskauffmann at hotmail dot com
Target Milestone: ---
Originally reported as https://bugreports.qt.io/browse/QTBUG-105227.
GCC 13 fails to compile this code, which was working fine in GCC 12 and 11:
```
#include
#include
#include
#include
class tst_ContainerApiSymmetry
{
public:
template
void ranged_ctor_non_associative_impl() const;
void ranged_ctor_std_vector_int() {
ranged_ctor_non_associative_impl>(); }
};
template
void tst_ContainerApiSymmetry::ranged_ctor_non_associative_impl() const
{
using V = typename Container::value_type;
const V values1[] = { V(0), V(1), V(2), V(0) };
const Container c5 = [&] {
{
std::stringstream ss;
for (auto : values1)
ss << v << ' ';
ss.seekg(0);
return Container(std::istream_iterator{ss},
std::istream_iterator{});
}
}();
}
int main() {
tst_ContainerApiSymmetry test;
test.ranged_ctor_std_vector_int();
return 0;
}
```
It fails with:
```
qttest.cpp: In instantiation of ‘void
tst_ContainerApiSymmetry::ranged_ctor_non_associative_impl() const [with
Container = std::vector]’:
qttest.cpp:12:91: required from here
qttest.cpp:24:13: error: range-based ‘for’ expression of type ‘const int []’
has incomplete type
24 | for (auto : values1)
| ^~~
```
Tested with:
```
Using built-in specs.
COLLECT_GCC=/opt/gcc-20220819/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc-20220819/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-src-git/configure --enable-languages=c,c++
--disable-multilib --enable-shared --prefix=/opt/gcc-20220819
--without-included-gettext --enable-threads=posix --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-cet --with-abi=m64
--without-cuda-driver --enable-lto --enable-ld=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220819 (experimental) (GCC)
```
It also wasn't working with GCC 13 20220627.
[Bug ipa/106696] New: Fallthrough between functions without proper return statement when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106696
Bug ID: 106696
Summary: Fallthrough between functions without proper return
statement when optimizing
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan.kneifel at bluewin dot ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64
Target: x86_64, aarch64
Consider the following incorrect code:
--
void* foo (void)
{
}
int bar (void)
{
return 42;
}
--
Compiling this as either plain C or without optimization gives the proper
warning (no return statement in function returning non-void), but returns from
foo. However, compiling this as C++ with optimization on (-O1 is sufficient),
the warning is emitted anyway, but the function body of foo is now eliminated
entirely (even the ret statement!) and a call to foo() falls through to a call
to bar(). For security reasons, I don't think this should be the case, even
when the input code is faulty.
[Bug libstdc++/106695] New: Regression 11,12: Explicit copy constructor does not work for a parameter passed via std::async
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106695
Bug ID: 106695
Summary: Regression 11,12: Explicit copy constructor does not
work for a parameter passed via std::async
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program:
```
#include
struct A {
A() = default;
explicit A(const A &) = default;
};
void foo(const A &) {}
int main() {
auto f = std::async(std::launch::async, foo, A{});
}
```
is accepted in GCC 10, MSVC and Clang with libc++, but not in GCC 11/12:
error: could not convert '{std::forward((* & __args#0)),
std::forward((* & __args#1))}' from '' to
'std::tuple'
1693 | _M_fn{{std::forward<_Args>(__args)...}}
Online demo: https://gcc.godbolt.org/z/nMn33PTbd
Related discussion: https://stackoverflow.com/q/73417828/7325599
[Bug target/106609] [12/13 Regression] sh3eb-elf cross compiler is being miscompiled since r12-1525-g3155d51bfd1de8b6c4645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 --- Comment #12 from Mikael Pettersson --- I tried compiling the gcc-13 cross compiler using the broken gcc-12 host compiler and -mtune-ctrl=^use_bt but that didn't help. I then tried rebuilding the broken gcc-12 host compiler with the new splitters disabled, one by one. Disabling the "*bt_setcqi" one did unbreak the gcc-13 cross-compiler: diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md index 48532eb7ddf..0780ba992f3 100644 --- a/gcc/config/i386/i386.md +++ b/gcc/config/i386/i386.md @@ -12830,7 +12830,7 @@ (const_int 1) (zero_extend:SI (match_operand:QI 2 "register_operand" (clobber (reg:CC FLAGS_REG))] - "TARGET_USE_BT && ix86_pre_reload_split ()" + "0 && TARGET_USE_BT && ix86_pre_reload_split ()" "#" "&& 1" [(set (reg:CCC FLAGS_REG)
[Bug c++/106645] [C++23] P2290R3 - Delimited escape sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106645 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e9dd050e0ccd644c3bb6d6538dc6187157f6b3e8 commit r13-2127-ge9dd050e0ccd644c3bb6d6538dc6187157f6b3e8 Author: Jakub Jelinek Date: Sat Aug 20 10:26:55 2022 +0200 libcpp: Implement C++23 P2290R3 - Delimited escape sequences [PR106645] The following patch implements the C++23 P2290R3 paper. 2022-08-20 Jakub Jelinek PR c++/106645 libcpp/ * include/cpplib.h (struct cpp_options): Implement P2290R3 - Delimited escape sequences. Add delimite_escape_seqs member. * init.cc (struct lang_flags): Likewise. (lang_defaults): Add delim column. (cpp_set_lang): Copy over delimite_escape_seqs. * charset.cc (extend_char_range): New function. (_cpp_valid_ucn): Use it. Handle delimited escape sequences. (convert_hex): Likewise. (convert_oct): Likewise. (convert_ucn): Use extend_char_range. (convert_escape): Call convert_oct even for \o. (_cpp_interpret_identifier): Handle delimited escape sequences. * lex.cc (get_bidi_ucn_1): Likewise. Add end argument, fill it in. (get_bidi_ucn): Adjust get_bidi_ucn_1 caller. Use end argument to compute num_bytes. gcc/testsuite/ * c-c++-common/cpp/delimited-escape-seq-1.c: New test. * c-c++-common/cpp/delimited-escape-seq-2.c: New test. * c-c++-common/cpp/delimited-escape-seq-3.c: New test. * c-c++-common/Wbidi-chars-24.c: New test. * gcc.dg/cpp/delimited-escape-seq-1.c: New test. * gcc.dg/cpp/delimited-escape-seq-2.c: New test. * g++.dg/cpp/delimited-escape-seq-1.C: New test. * g++.dg/cpp/delimited-escape-seq-2.C: New test.
[Bug middle-end/106692] [10/11/12/13 Regression] Cray pointer comparison wrongly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Sure, in the middle-end the assumption that REFERENCE_TYPE vars/parameters may never bind to NULL are correct. I'd say this is just a user error, but am not a Fortran language lawyer. It is hard to argue about Cray pointers when they aren't part of the official Fortran standard, but let's just use some wording about real Fortran POINTERs. zz1 is a normal dummy argument (real :: zz1). E.g. in J3/97-007R2, 12.4.1.1 says: "If the dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target." so, for POINTERs passed as actual arguments to normal non-pointer dummy arguments they have to be associated (aka not NULL), rather than disassociated (aka NULL) or undefined (aka uninitialized). I'd say it is the same thing with Cray pointers even when it doesn't give those special names, but passing a Cray pointee where the associated Cray pointer is uninitialized or pointing to absolute address where no object is present to a function that expects something it can access looks undefined behavior. If zz1 had the VALUE attribute, it would always crash already during the passing, like it would to just do zz1 = 0 in test_cray. As it doesn't have VALUE attribute in the testcase, it would also crash if shape_cray did whatever = zz1 or zz1 = 0 etc. I think one needs to use OPTIONAL if an argument might not be passed at all, or POINTER/ALLOCATABLE if a dummy argument is to be sometimes associated/allocated and sometimes is not, or make the dummy argument a Cray pointer. That would be subroutine shape_cray(ptrzz) and dropping the ptrzz=loc(zz1) line, and on the caller side call shape_cray(ptrzz1). Changing component to fortran, so that the Fortran maintainers can voice in. If it would be a compiler bug, it would be a FE bug, where it couldn't use REFERENCE_TYPE on types of objects that could through Cray pointers bind to NULL (perhaps with -fcray-pointers only).
[Bug c++/106689] gcc crash while compiling a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689 --- Comment #6 from Janez Zemva --- I have since changed the repo. You can still demonstrate the bug by uncommenting the line: //[, , ]() noexcept -> bool // uncomment for bug
[Bug debug/106263] BTF_KIND_FUNC type does not encode linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106263 --- Comment #2 from James Hilliard --- Should this be backported to the gcc 12 branch?
[Bug fortran/106684] inconsistent array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684 --- Comment #7 from Jorn Bruggeman --- None from me; thanks for the explanation!
