[Bug c/85487] Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85487 Baruch Burstein changed: What|Removed |Added CC||bmburstein at gmail dot com --- Comment #2 from Baruch Burstein --- This pragma is used by VSCode, too, which is commonly used with gcc as a compiler.
[Bug c++/97077] New: Missed loop unrolling with range for over initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97077
Bug ID: 97077
Summary: Missed loop unrolling with range for over initializer
list
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bmburstein at gmail dot com
Target Milestone: ---
In the following code:
#include
int foo(int);
int main() {
for(int i=0; i<5; ++i) {
foo(i);
}
for(int i : {0,1,2,3,4}) {
foo(i);
}
}
The 2 loops should probably produce identical output. However, the output I see
here https://godbolt.org/z/z1We36 (using the trunk from 2020-09-15) shows that
the first loop (the traditional one) is indeed unrolled as expected, but the
second one is not.
[Bug c++/87709] New: c++17 class template argument deduction not working in a very specific case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709 Bug ID: 87709 Summary: c++17 class template argument deduction not working in a very specific case Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bmburstein at gmail dot com Target Milestone: --- Created attachment 44883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44883&action=edit test case The test case is attached. It has no includes and so I am attaching the *.cpp file as per https://gcc.gnu.org/bugs/ I am compiling with -std=c++17 Output of g++ -v: # g++ -v Using built-in specs. COLLECT_GCC=C:\MyProgs\msys64\mingw64\bin\g++.exe COLLECT_LTO_WRAPPER=C:/MyProgs/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-8.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev3, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 8.2.0 (Rev3, Built by MSYS2 project) I tried with another build and got the same results. This one gave: # g++ -v Using built-in specs. COLLECT_GCC=/opt/wandbox/gcc-8.2.0/bin/g++ COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-8.2.0/configure --prefix=/opt/wandbox/gcc-8.2.0 --enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release --disable-nls LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-8.2.0/lib,-rpath,/opt/wandbox/gcc-8.2.0/lib64,-rpath,/opt/wandbox/gcc-8.2.0/lib32 --enable-lto Thread model: posix gcc version 8.2.0 (GCC)
[Bug c++/87709] c++17 class template argument deduction not working in a very specific case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709
--- Comment #4 from Baruch Burstein ---
There is a pretty good (speculative) analysis of this issue here:
https://stackoverflow.com/a/52986284/331785
I am copying it to here for completeness, but credit for this goes to the
author of that post:
There are two kinds of expressions that look similar but have vastly different
meaning:
(type) + expr
(expr) + expr
The first is a C-style cast expression, that converts the unary expression +
expr to type, the second is a binary expression that performs addition.
To disambiguate an expression of form (something) + expr, GCC first assumes
that something is a type and does a tentative parse. If that succeeds, then the
whole expression is treated as a cast expression, otherwise, something is
reparsed as an expression.
Now here's where I think the bug resides: during the tentative parse, GCC
wrongly believes that class template argument deduction (CTAD) cannot appear,
so it issues an error when it appears. But in fact, even though the tentative
parse will definitely fail in this case, something may still be a valid
function-style cast expression, and thus the reparse might be successful.
For cat((lit('b')), lit('d')), lit('b') + lit('d'), and (lit('b')), GCC is
clever enough to see that they can't be C-style cast expression, so it does not
do the tentative parse. For (lit('b')) + lit('d'), there's no CTAD in
lit('b'), so it is fine as well.
Prove of the above analysis:
If + is changed to / (or most operators other than -, * or &), no error occurs,
because (something) / expr can't be a valid cast expression.
Similar ambiguity exists in sizeof(something) (could be sizeof(type) or
sizeof(expr)), and as expected, sizeof(lit(0)) triggers a similar error.
[Bug c/85487] Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85487 --- Comment #15 from Baruch Burstein --- (In reply to Jonathan Wakely from comment #13) > (In reply to rsand...@gcc.gnu.org from comment #12) > > > I think the patch would need to wait for GCC 13 now though. > > Indeed. Now that GCC 13 is the main development trunk, can this patch be merged? If I understood the comments in this thread correctly, the patch already exists and was just waiting for GCC 12 to be branched.
