[Bug c++/86921] New: do not remove input in bash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86921 Bug ID: 86921 Summary: do not remove input in bash Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yamirenk at ya dot ru Target Milestone: --- when the second line begins. symbols, entered in first line, does not remove(with backspace). for example: "cin >> init;"
[Bug fortran/86906] erroneous name clash with renaming in use statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86906 --- Comment #1 from Paul Thomas --- Author: pault Date: Sun Aug 12 10:55:13 2018 New Revision: 263494 URL: https://gcc.gnu.org/viewcvs?rev=263494&root=gcc&view=rev Log: 2018-08-12 Paul Thomas PR fortran/86906 * resolve.c (resolve_fl_variable_derived): Check if the derived type is use associated before checking for the host association error. 2018-08-12 Paul Thomas PR fortran/86906 * gfortran.dg/use_rename_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_rename_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/86906] erroneous name clash with renaming in use statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86906 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-12 CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Paul Thomas --- I will commit to 8-branch as well. Paul
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #16 from The Written Word --- Created attachment 44529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44529&action=edit stdlib.h long_double patch
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #17 from The Written Word --- (In reply to The Written Word from comment #16) > Created attachment 44529 [details] > stdlib.h long_double patch This is the patch I came up with. What do you think?
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #18 from dave.anglin at bell dot net --- On 2018-08-12 8:10 AM, bugzilla-gcc at thewrittenword dot com wrote: > This is the patch I came up with. What do you think? Did you check that "make check" in the fixincludes build directory works and there are no issues left? See README in fixincludes directory. If this works, please add a ChangeLog entry to the patch and send it to gcc-patches. CC Bruce Korb and myself. It would be good if you could post test results for 11.31 to gcc-testresults. This will help find further problems. Thanks, Dave
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #19 from The Written Word --- (In reply to dave.anglin from comment #18) > On 2018-08-12 8:10 AM, bugzilla-gcc at thewrittenword dot com wrote: > > This is the patch I came up with. What do you think? > > Did you check that "make check" in the fixincludes build directory works > and there are no issues left? See README in fixincludes directory. > > If this works, please add a ChangeLog entry to the patch and send it to > gcc-patches. > CC Bruce Korb and myself. > > It would be good if you could post test results for 11.31 to > gcc-testresults. This will > help find further problems. Ok, will take care of all of the above. Found one issue in my patch which I'm testing now. Once I have something that passes the above, will submit.
[Bug c++/86918] internal compiler error: unexpected expression 'v' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86918 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-12 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. Not a regression as far as I can see.
[Bug c++/86918] internal compiler error: unexpected expression 'v' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86918 --- Comment #2 from Marek Polacek --- Started with r223304. With r223301, there's an error.
[Bug c++/86918] internal compiler error: unexpected expression 'v' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86918 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #3 from Marek Polacek --- I guess invalid: $ clang++ -c 86918.C -std=c++17 86918.C:8:15: error: non-type template parameter conflicts with previous non-type template parameter pack template ^ 86918.C:3:21: note: previous non-type template parameter pack declared here template ^ 86918.C:13:23: error: implicit instantiation of undefined template 'S::X' static_assert(S::X::value); ^ 86918.C:4:12: note: template is declared here struct X; ^ 2 errors generated.
[Bug libstdc++/86910] std::filesystem::create_directories doesn't set error code or throw while violating postcondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86910 --- Comment #6 from Steffen Schuemann --- Yeah, I totally understand, that if the behaviour of create_directories was in conformance to the resolution to that defect, you don't feel like changing anything. And I definitely don't want to be pedantic. In the end, if this is, what is wanted, I have to accept the solution. Well, I might even feel pressed to adapt the behaviour of my own implementation to that. I guess, if I had seen the defect report in advance, I might not even have bothered you with this, even if I would have felt bad about that decision. But I'm really grateful, that you did forward that question, thank you for trying. The GCC version I was using was simply the GCC8 that my Ubuntu 18.04 virtual machine had available. I didn't want to build my own GCC on that vm as I have some disk space issues. Before filing the issue, I double checked against the head of the source, to make sure it is nothing changed in a later version. I additionally tested against the g++ on my macOS that is the 8.1.0 from homebrew. And just for the fun of it, I used some time to double check the source of libc++ and compiled myself a clang-8 from HEAD to run my tests with that one too, and it is just the other way around: create_directories fails/throws when a file with that name exists, and create_directory doesn't. :-) I guess there's some inconsistency too, but this is the wrong issue tracker for that. In the end, I vote for consistency, either the more useful way with the postcondition, or the fixed way without. Whichever docs you use when calling them, they should behave consistently. Thanks again, for the help and work!
[Bug c++/86922] New: Invoking templated PTMF on subclass gives false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86922
Bug ID: 86922
Summary: Invoking templated PTMF on subclass gives false
strict-aliasing warning
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bmerry at gmail dot com
Target Milestone: ---
When using a pointer-to-member-function which is a template parameter on an
instance of a derived class, I get a warning about type-punned pointers
breaking strict aliasing. Warning message and sample code are below.
This doesn't seem to be a recent regression. I get essentially the same warning
(modulo formatting) from 4.8.5, 7.3.0 and Ubuntu's pre-release 8.0.1 (all on
Ubuntu 18.04, x86-64).
The code:
class A
{
public:
int a;
void foo() const;
};
class B : public A {};
template
class Wrapper
{
public:
void operator()(const B &obj) const
{
return (obj.*Ptr)();
}
};
void call()
{
Wrapper<&B::foo> wrapper;
wrapper(B());
}
Command line:
g++ -c strict.cpp -Wall -O2
Output:
with void (A::* Ptr)() const = &A::foo]’:
strict.cpp:23:16: required from here
strict.cpp:16:26: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
return (obj.*Ptr)();
~~^~
gcc version info:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-16ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as
--with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7
--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 --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --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 --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
Alternate version info:
Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20180414-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as
--with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-8
--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 --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --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 --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.1 20180414 (experimental) [trunk revision 259383] (Ubuntu
8-20180414-1ubuntu2)
[Bug fortran/86472] allocatable array, bound-procedure, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86472 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #7 from Paul Thomas --- > Everything goes through without error. I thought "Such specifications have > no effect." was not clear. The uncharacteristic entities should not be > specified in the interface. Hi Jim, I thought the wording to be very strange as well. I wondered if it is just a convenience to allow copy and paste of all the specification statements into an interface. I have marked the PR as RESOLVED/INVALID - if you have any problems with that, remark it as WAITING. Thanks for the report by the way :-) Paul
[Bug fortran/86906] erroneous name clash with renaming in use statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86906 --- Comment #3 from Paul Thomas --- Author: pault Date: Sun Aug 12 15:35:53 2018 New Revision: 263498 URL: https://gcc.gnu.org/viewcvs?rev=263498&root=gcc&view=rev Log: 2018-08-12 Paul Thomas PR fortran/86906 * resolve.c (resolve_fl_variable_derived): Check if the derived type is use associated before checking for the host association error. 2018-08-12 Paul Thomas PR fortran/86906 * gfortran.dg/use_rename_9.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/use_rename_9.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/86906] erroneous name clash with renaming in use statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86906 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Thomas --- Fixed on trunk and 8-branch Thanks for the report. Paul
[Bug fortran/66679] [OOP] ICE with class(*) and transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66679 --- Comment #4 from Paul Thomas --- Author: pault Date: Sun Aug 12 17:19:09 2018 New Revision: 263499 URL: https://gcc.gnu.org/viewcvs?rev=263499&root=gcc&view=rev Log: 2018-08-12 Paul Thomas PR fortran/66679 * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Class array elements are returned as references to the data element. Get the class expression by stripping back the references. Use this for the element size. 2018-08-12 Paul Thomas PR fortran/66679 * gfortran.dg/transfer_class_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_class_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66679] [OOP] ICE with class(*) and transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66679 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Fixed on trunk. Thanks for the report and sorry for the long delay in committing the fix. Paul
[Bug fortran/31237] [meta-bug] TRANSFER intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237 Bug 31237 depends on bug 66679, which changed state. Bug 66679 Summary: [OOP] ICE with class(*) and transfer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66679 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/86923] New: Missed optimization performing consecutive integer sum, loop not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86923
Bug ID: 86923
Summary: Missed optimization performing consecutive integer
sum, loop not removed
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
unsigned long f(unsigned int n) {
unsigned long total = 0;
for (unsigned int i = 0; i < n; ++i)
total += i;
return total;
}
It may not be terribly useful to report this, as I can (and arguably should)
write n(n-1)/2 manually, but clang does successfully transform this into:
lea eax, [rdi - 1]
add edi, -2
imulrdi, rax
shr rdi
add rdi, rax
whereas GCC tries instead to vectorize and process the loop as written.
Obviously, O(1) is preferable to O(n) here.
This applies to both C and C++.
[Bug tree-optimization/86924] New: tree-slp-vectorize may create unaligned memory access, causing segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86924 Bug ID: 86924 Summary: tree-slp-vectorize may create unaligned memory access, causing segmentation fault Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: contact at ligh dot de Target Milestone: --- Compiler version: 8.2.0 for Windows 64 bit, as released in MSYS2 / MinGW64 Windows 7 SP1, 64 bit $ gcc -v Using built-in specs. COLLECT_GCC=H:\development\media-autobuild_suite-master\msys64\mingw64\bin\gcc.exe COLLECT_LTO_WRAPPER=H:/development/media-autobuild_suite-master/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='Rev1, 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 (Rev1, Built by MSYS2 project) The AOMedia AV1 video encoder compiled with this version (but it is probably independent of the operating system) crashes while encoding. The following bug report in the Chromium bug tracker analyzed the problem, especially comment 7 went down to disassembly: https://bugs.chromium.org/p/aomedia/issues/detail?id=2055#c7 Summary by lupo...: + Bug appears in the compilation of https://aomedia.googlesource.com/aom/+/da17065690c185ae678d5db9466cf0a402ca6b6d/av1/encoder/encoder.c#3415 More precisely in the optimized and inlined lshift_bwd_ref_frames(cpi) inside update_reference_frames Disassembly listings to follow: cmake -G "MSYS Makefiles" -DCONFIG_LOWBITDEPTH=1 -DENABLE_DOCS=0 -DENABLE_TESTS=off ../aom loc_4D5CD2: mov edx, [rcx+35624Ch] movdqa xmm3, xmmword ptr [rcx+478E38h] mov [rcx+356248h], edx mov edx, [rcx+356254h] movaps xmmword ptr [rcx+478E28h], xmm3 movdqa xmm3, xmmword ptr [rcx+478E58h] mov [rcx+35624Ch], edx movaps xmmword ptr [rcx+478E38h], xmm3 mov [rcx+356254h], r11d jmp loc_4D58A0 cmake -G "MSYS Makefiles" -DCONFIG_LOWBITDEPTH=1 -DENABLE_DOCS=0 -DENABLE_TESTS=off -DAOM_EXTRA_C_FLAGS="-fno-tree-slp-vectorize" -DAOM_EXTRA_CXX_FLAGS="-fno-tree-slp-vectorize" ../aom loc_4D5DC2: mov edx, [rcx+35624Ch] movdqu xmm3, xmmword ptr [rcx+478E38h] movdqu xmm5, xmmword ptr [rcx+478E58h] mov [rcx+356248h], edx mov edx, [rcx+356254h] movups xmmword ptr [rcx+478E28h], xmm3 mov [rcx+35624Ch], edx movups xmmword ptr [rcx+478E38h], xmm5 mov [rcx+356254h], r11d jmp loc_4D5993 It all reduces to aligned vs unaligned memory access. By manually patching the faulty executable, changing movdqa to movdqu and movaps to movups, I have been able to finish an encode without problems. + Please excuse not providing all the details you requested in the "Reporting Bugs" guide. But I believe the linked bug report in the Chromium tracker is verbose enough to understand the issue.
[Bug c/86925] New: ice in get_predictor_value, at pre dict.c:2551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86925 Bug ID: 86925 Summary: ice in get_predictor_value, at pre dict.c:2551 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 44530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44530&action=edit C source code For the attached C code, compiled with flag -O2 and recent gcc trunk: ../results.263455/bin/gcc ../results.263471.ubsan/bin/gcc during GIMPLE pass: profile_estimate gstsystemclock.c: In function ‘gst_system_clock_id_wait_jitter_unlocked’: gstsystemclock.c:1026:1: internal compiler error: in get_predictor_value, at pre dict.c:2551 0x611f7d get_predictor_value ../../trunk/gcc/predict.c:2551 0x1bce7d3 tree_predict_by_opcode ../../trunk/gcc/predict.c:2586 0x1bce7d3 tree_estimate_probability_bb ../../trunk/gcc/predict.c:2969 0x1bffc99 tree_estimate_probability(bool) ../../trunk/gcc/predict.c:2997 So the problem seems to have started between revisions 263455 and 263471. I'll have a go at reducing the code.
[Bug c/86925] ice in get_predictor_value, at predict.c:2551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86925 David Binderman changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from David Binderman --- Revision 263466 may well be the culprit. Adding marxin for their advice.
[Bug c/86925] ice in get_predictor_value, at predict.c:2551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86925
--- Comment #2 from David Binderman ---
Reduced C code is:
typedef enum { a } b;
d() {
b c;
do
if (__builtin_expect(({
int e;
if (c == a)
e = 1;
else
e = 0;
e;
}),
0))
break;
while (__builtin_expect(({ ({ f(); }); }), 0));
if (__builtin_expect(({
int e;
if (c == a)
e = 1;
else
e = 0;
e;
}),
0))
g();
}
[Bug c/86925] ice in get_predictor_value, at predict.c:2551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86925 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-12 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Thanks for the report, I'm aware of it already by Jeff Law. I've got fix that I'll install tomorrow.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 85160, which changed state. Bug 85160 Summary: GCC generates mvn/and instructions instead of bic on aarch64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85160 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/85160] GCC generates mvn/and instructions instead of bic on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85160 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Segher Boessenkool --- This is fixed on trunk now.
[Bug c++/85457] enum and auto template parameter mixup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85457 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- This seems to have been fixed. Duplicate of bug 79092?
[Bug libstdc++/86910] std::filesystem::create_directories doesn't set error code or throw while violating postcondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86910 --- Comment #7 from Jonathan Wakely --- (In reply to Steffen Schuemann from comment #6) > And just for the fun of it, I used some time to double check the source of > libc++ and compiled myself a clang-8 from HEAD to run my tests with that one > too, and it is just the other way around: create_directories fails/throws > when a file with that name exists, and create_directory doesn't. :-) Ha! > In the end, I vote for consistency, either the more useful way with the > postcondition, or the fixed way without. Whichever docs you use when calling > them, they should behave consistently. Yes, I definitely agree. Once the committee finishes discussing it and decides to either revisit the DR, or reconfirm it's definitely what we want, then I'll change libstdc++.
[Bug c++/86921] do not remove input in bash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86921 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-12 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This is not a usable bug report. Please see https://gcc.gnu.org/bugs/
[Bug c++/85457] enum and auto template parameter mixup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85457 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- (In reply to ensadc from comment #1) > This seems to have been fixed. Duplicate of bug 79092? Yes, thanks *** This bug has been marked as a duplicate of bug 79092 ***
[Bug c++/79092] template: type ignored if value already instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092 Jonathan Wakely changed: What|Removed |Added CC||info at thinkmeta dot de --- Comment #8 from Jonathan Wakely --- *** Bug 85457 has been marked as a duplicate of this bug. ***
[Bug c++/86926] New: [Regression] ICE for a recursive generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86926
Bug ID: 86926
Summary: [Regression] ICE for a recursive generic lambda
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v.reshetnikov at gmail dot com
Target Milestone: ---
/* BEGIN SOURCE */
int main() {
constexpr auto f = [](auto self, auto n) {
if(n < 2) return n;
return self(self, n - 1) + self(self, n - 2);
};
constexpr auto fibonacci = [=](auto n) { return f(f, n); };
static_assert(fibonacci(7) == 13);
}
/** END SOURCE **/
Compile with -std=c++17.
EXPECTED: no errors.
ACTUAL:
: In instantiation of 'main():: [with auto:3 = int]':
:11:30: required from here
:9:54: internal compiler error: in build_over_call, at cp/call.c:8214
9 | constexpr auto fibonacci = [=](auto n) { return f(f, n); };
| ~^~
Tested with build 9.0.0 20180810 (experimental), appears to be a regression
from GCC 8.2. For comparison, the code also successfully compiles with Clang.
[Bug c++/86926] [Regression] ICE for a recursive generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86926 --- Comment #1 from Vladimir Reshetnikov --- Note: the error disappears if the variable `f` is not declared `constexpr`.
[Bug c++/86926] [8/9 Regression] ICE for a recursive generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86926 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-12 CC||mpolacek at gcc dot gnu.org Summary|[Regression] ICE for a |[8/9 Regression] ICE for a |recursive generic lambda|recursive generic lambda Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed.
[Bug c++/86926] [8/9 Regression] ICE for a recursive generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86926 --- Comment #3 from Marek Polacek --- Started with r261121.
[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251 Eric Gallager changed: What|Removed |Added Last reconfirmed|2017-07-20 00:00:00 |2018-8-12 CC||jeremyhu at macports dot org --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #4) > (In reply to Mike Stump from comment #3) > > I've been avoiding this bug for years by just removing the unwind.h header. > > :-( > > Confirming because I seem to remember solving a build issue like this in the > past, too. Just happened to me again because MacPorts reinstalled libunwind-headers on me even though I had deactivated it, reconfirming.
[Bug tree-optimization/86927] New: Gcc miscompiles at -O3 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86927
Bug ID: 86927
Summary: Gcc miscompiles at -O3 on valid code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
It appears to be a recent regression. And it happens at -O3 only.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180812 (experimental) [trunk revision 263494] (GCC)
$ gcc-trunk abc.c ; ./a.out
$ gcc-trunk -O2 abc.c ; ./a.out
$ gcc-trunk -O3 abc.c ; ./a.out
Aborted (core dumped)
$ cat abc.c
int a[28];
int b;
void abort();
int main() {
a[4] = 1;
int c = 1;
for (; b < 8; b++)
if (a[b])
c = 0;
if (c)
abort();
}
[Bug c++/81718] g++ segfault in tsubst_copy_and_build when creating type alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81718 --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > > I would have to rebuild my gcc with debug info to get a better backtrace. So I tried doing that but it crashed my debugger; I might need to open a separate bug for that...
[Bug middle-end/82798] Inconsistent descriptions for warning options in documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82798 --- Comment #3 from Eric Gallager --- (In reply to Julien ÉLIE from comment #2) > Other points: > > 6/ -Wsuggest-final-types and -Wsuggest-final-methods should be mentioned for > C++ (and maybe Objective-C++) only. > > 7/ -Wc++11-compat and -Wc++14-compat are present in the -Wall list but > without the mention for C++ and Objective-C++. I believe it should be > mentioned. Yeah those points probably fit in with bug 71283 too...
[Bug c++/71424] std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71424 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-13 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/86594] Crash on trying to capture 'this' in instantiation of generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86594 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-13 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 Eric Gallager changed: What|Removed |Added CC||dmalcolm at redhat dot com, ||per at bothner dot com --- Comment #20 from Eric Gallager --- (In reply to Jack Howarth from comment #16) > (In reply to howarth from comment #15) > > (In reply to howarth from comment #14) > > > Testing https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01334.html in case > > > correction of the overflow tests eliminates this bug. > > > > The proposed patch for correcting overflows doesn't eliminate this bug. > > With Jan's patch the failure still appears as... > > #0 0x7fff96238286 in __pthread_kill () > #1 0x7fff9488042f in pthread_kill () > #2 0x7fff8e9c1b53 in abort () > #3 0x000100f32170 in linemap_lookup (set=0x10175e0f0, line=651) at > ../../gcc-5-20150326/libcpp/line-map.c:806 Since the crash is in libcpp, cc-ing libcpp maintainers
[Bug ada/86916] 8.1.0 (x86_64-apple-darwin15) Constraint_Error erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86916 --- Comment #4 from Roger Mc Murtrie --- Simon Wright has determined the problem and notes that GNAT has failed to recognise the actual problem. (https://groups.google.com/forum/#!topic/comp.lang.ada/MdywAlMPQms) The problem is in the packages Morph.Mesh_Morph_Value_Pointers, Mesh_Morph_Weight_Pointers. You say package Mesh_Morph_Value_Pointers is new Interfaces.C.Pointers (Interfaces.C.unsigned, API_Morph_Value, API_Morph_Values_Array, API_Morph_Value'(others => <>)); but type API_Morph_Value is new Interfaces.C.unsigned; so others => <> isn't a legal expression for an API_Morph_Value; you should say API_Morph_Value'(0)); There is still a bug, which ought to be fixed, but it's that GNAT has failed to recognise the actual problem and has got fatally confused.
[Bug tree-optimization/84353] [8/9 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84353
--- Comment #8 from Arseny Solokha ---
(In reply to Richard Biener from comment #5)
> Getting more testcase for this is nice though.
int
dt (__int128 gg, int sn, int *b2)
{
int wt = 0, f4 = 0;
while (wt < sn)
{
f4 = !!(gg * 2 + sn) + (double) b2[wt];
++wt;
}
return f4;
}
% gcc-9.0.0-alpha20180805 -O2 -floop-nest-optimize -funswitch-loops -fwrapv
-fno-tree-loop-im -c inkukbsw.c
during GIMPLE pass: graphite
inkukbsw.c: In function 'dt':
inkukbsw.c:2:1: internal compiler error: in set_codegen_error, at
graphite-isl-ast-to-gimple.c:205
dt (__int128 gg, int sn, int *b2)
^~
0x736dc0 translate_isl_ast_to_gimple::set_codegen_error()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite-isl-ast-to-gimple.c:205
0x736e51 translate_isl_ast_to_gimple::set_codegen_error()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/tree.h:3237
0x736e51
translate_isl_ast_to_gimple::gcc_expression_from_isl_expr_int(tree_node*,
isl_ast_expr*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite-isl-ast-to-gimple.c:308
0x14a98ae translate_isl_ast_to_gimple::binary_op_to_tree(tree_node*,
isl_ast_expr*, std::map,
std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite-isl-ast-to-gimple.c:322
0x14a98ae translate_isl_ast_to_gimple::binary_op_to_tree(tree_node*,
isl_ast_expr*, std::map,
std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite-isl-ast-to-gimple.c:322
0x14a98eb translate_isl_ast_to_gimple::binary_op_to_tree(tree_node*,
isl_ast_expr*, std::map,
std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite-isl-ast-to-gimple.c:340
0x14aa1f4 translate_isl_ast_to_gimple::graphite_create_new_guard(edge_def*,
isl_ast_expr*, std::map,
std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite-isl-ast-to-gimple.c:873
0x14ab797 translate_isl_ast_to_gimple::translate_isl_ast_node_if(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite-isl-ast-to-gimple.c:892
0x14ab714 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite-isl-ast-to-gimple.c:859
0x14abaf7 graphite_regenerate_ast_isl(scop*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite-isl-ast-to-gimple.c:1505
0x14a7dec graphite_transform_loops()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite.c:413
0x14a81e0 graphite_transforms
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite.c:475
0x14a81e0 execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/graphite.c:552
(r263320)
[Bug rtl-optimization/86928] New: ICE in compute_live, at sel-sched.c:3097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928
Bug ID: 86928
Summary: ICE in compute_live, at sel-sched.c:3097
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu, powerpcspe-*-linux-gnu
gcc-9.0.0-alpha20180805 snapshot (r263320) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -fnon-call-exceptions -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops -fselective-scheduling -fno-if-conversion
-fno-tree-dce:
int kn;
void
gd (short int sk)
{
char *as;
while (sk < 1)
{
char *ci;
if (*ci == 0)
*as += ci;
for (kn = 0; kn < 18; ++kn)
{
}
++sk;
}
}
% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20180805 -O2 -fnon-call-exceptions
-fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
-fselective-scheduling -fno-if-conversion -fno-tree-dce -w -c opsr9okd.c
during RTL pass: sched1
opsr9okd.c: In function 'gd':
opsr9okd.c:21:1: internal compiler error: in compute_live, at sel-sched.c:3097
}
^
0xbe0aa2 compute_live(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:3097
0xbe0938 compute_live_after_bb
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:3074
0xbe0938 compute_live(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:3131
0xbe4058 code_motion_path_driver
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:6660
0xbe524d move_op
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:6714
0xbe524d move_exprs_to_boundary
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:5237
0xbe524d schedule_expr_on_boundary
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:5450
0xbe92a8 fill_insns
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:5592
0xbeb0de schedule_on_fences
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:7366
0xbeb0de sel_sched_region_2
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:7504
0xbec142 sel_sched_region_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:7546
0xbed735 sel_sched_region(int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:7647
0xbee079 run_selective_scheduling()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sel-sched.c:7733
0xbc5db4 rest_of_handle_sched
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sched-rgn.c:3718
0xbc5db4 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/sched-rgn.c:3828
[Bug c/86929] New: `-fstack-protector` results in wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86929
Bug ID: 86929
Summary: `-fstack-protector` results in wrong code
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Target: *-w64-mingw32
The following program:
```
void test(int n)
{
char str[50];
}
int main(void)
{
test(42);
}
```
, after being compiled with
```
x86_64-w64-mingw32-gcc -fstack-protector -O0 test.c
```
, results in assembly that references the FS segment register
```
test:
pushq %rbp
.seh_pushreg%rbp
movq%rsp, %rbp
.seh_setframe %rbp, 0
subq$96, %rsp
.seh_stackalloc 96
.seh_endprologue
movl%ecx, 16(%rbp)
movq%fs:0, %rax
```
, which causes crashes on x64, as on Windows this not the correct way to
reference native thread-local storage. At the moment, GCC should use emutls
instead.
Compiling this program with i686-w64-mingw32-gcc does not results in an
immediate segment fault, but the assembly code still references the GS segment
register, so it is still wrong.
Prior to GCC 8, stack protectors used static, non-thread-local pointers, which
were subject to data races, but didn't result in segment fault for
single-threaded programs.
[Bug c/86929] `-fstack-protector` results in wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86929 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- dup. *** This bug has been marked as a duplicate of bug 86832 ***
[Bug target/86832] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832 Andrew Pinski changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #2 from Andrew Pinski --- *** Bug 86929 has been marked as a duplicate of this bug. ***
[Bug target/85644] [8/9 Regression] -fstack-protector generates invalid read to %fs:0x0 on mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85644 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-13 Summary|-fstack-protector generates |[8/9 Regression] |invalid read to %fs:0x0 on |-fstack-protector generates |mac |invalid read to %fs:0x0 on ||mac Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- .
[Bug target/85644] [8/9 Regression] -fstack-protector generates invalid read to %fs:0x0 on mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85644 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.3
[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-13 Target Milestone|--- |8.3 Summary|GCC v8.2.0 tries to use |[8/9 Regression] GCC v8.2.0 |native TLS with |tries to use native TLS |-fstack-protector-strong on |with |Windows (mingw-w64) |-fstack-protector-strong on ||Windows (mingw-w64) Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- .
[Bug c/86929] `-fstack-protector` results in wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86929 --- Comment #2 from Liu Hao --- Oh didn't know it happens on macOS too. I didn't find the duplicate because I searched for 'mingw' only.
