[Bug bootstrap/93214] Ada LTO bootstrap fails with undefined reference to __gnat_debug_raise_assert_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93214 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-10 CC||ebotcazou at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I can confirm that.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #7 from Martin Liška --- (In reply to Peter Bergner from comment #6) > (In reply to Peter Bergner from comment #5) > > (In reply to Martin Liška from comment #4) > > > Yep, I can still reproduce it with the current master in a cross compiler. > > > > Ok, thanks. I'll see if I can recreate it with a cross since I cannot get > > it to fail with a native build. > > I still cannot reproduce this even in a cross. What GCC and binutils > configure options did you use? I'll note, that I don't have ppc header > files to build against, so I cannot do a full bootstrap build, but I do get > far enough to get a cc1/xgcc to compile the test case with. I built it like this: $ ~/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/ppc64le-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/home/marxin/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/ppc64le-linux-gnu-gcc COLLECT_LTO_WRAPPER=/home/marxin/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/../libexec/gcc/ppc64le-linux-gnu/10.0.0/lto-wrapper Target: ppc64le-linux-gnu Configured with: /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/configure --enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer --disable-multilib --enable-checking=release --prefix=/dev/shm/buildbot/install/gcc --target=ppc64le-linux-gnu --with-as=/usr/bin/powerpc64le-suse-linux-as Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.0 20200109 (experimental) 51ad584fdbea7291b52f8b93d351ab3b51d405c9 (GCC) $ /usr/bin/powerpc64le-suse-linux-as --version GNU assembler (GNU Binutils; openSUSE Tumbleweed) 2.33.1.20191023-2
[Bug debug/93220] New: DWARF line info file name table "incomplete"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93220
Bug ID: 93220
Summary: DWARF line info file name table "incomplete"
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For
> cat t.h
1, 2, 3,
4, 5, 6
> cat t.c
int a[] = {
#include "t.h"
};
> gcc -c t.c -g
the DWARF line info doesn't mention t.h at all (somewhat understandably
since no DWARF entity or attribute refers to it). It has been requested
to include it nevertheless to make tools (rpm find-debuginfo) "find"
t.h when building debug sources. With .debug_line built from .loc
directives that's of course a bit more painful.
I'll also note that even for
> cat t.c
int main()
{
int a[] = {
#include "t.h"
};
}
t.h isn't mentioned because the instructions initializing a[] do not refer
to the initializer either.
Not sure if this is a non-bug of course (I suggested so to the reporter).
[Bug analyzer/93212] internal compiler error: in make_region_for_type, at analyzer/region-model.cc:5961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93212 --- Comment #3 from David Malcolm --- Patch pushed to the dmalcolm/analyzer branch on the GCC git mirror: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00514.html Will close this if/once the analyzer is on trunk and this fix is committed there.
[Bug libgomp/93219] unused return value in affinity-fmt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219 --- Comment #1 from Roland Illig --- In similar bulk builds on NetBSD 8, NetBSD 9, Darwin 10.15, the code either compiled fine or must have been skipped. Current pkgsrc bulk build results for various platforms are available from https://mail-index.netbsd.org/pkgsrc-bulk/tindex.html. Visit report.html from the mails and search for gcc9.
[Bug libgomp/93219] New: unused return value in affinity-fmt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219 Bug ID: 93219 Summary: unused return value in affinity-fmt.c Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: jakub at gcc dot gnu.org Target Milestone: --- From a pkgsrc bulk build on RedHat EL 6 on x86_64: ../../../gcc-9.2.0/libgomp/affinity-fmt.c: In function 'gomp_print_string': ../../../gcc-9.2.0/libgomp/affinity-fmt.c:43:3: error: ignoring return value of 'fwrite', declared with attribute warn_unused_result [-Werror=unused-result] 43 | fwrite (str, 1, len, stderr); | ^~~~ echo timestamp > stamp-pb cc1: all warnings being treated as errors
[Bug rtl-optimization/93165] avoidable 2x penalty on unpredicted overwrite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165 --- Comment #7 from ncm at cantrip dot org --- (In reply to Richard Biener from comment #6) > (In reply to Andrew Pinski from comment #4) > > (In reply to Alexander Monakov from comment #3) > > > So perhaps an unpopular opinion, but I'd say a > > > __builtin_branchless_select(c, a, b) (guaranteed to live throughout > > > optimization pipeline as a non-branchy COND_EXPR) is badly missing. > > > > I am going to say otherwise. Many of the time conditional move is faster > > than using a branch; even if the branch is predictable (there are a few > > exceptions) on most non-Intel/AMD targets. This is because the conditional > > move is just one cycle and only a "predictable" branch is one cy`le too. > > The issue with a conditional move is that it adds a data dependence while > branches are usually speculated and thus have zero overhead in the execution > stage. The extra dependence can easily slow things down dependent on the > (three!) instructions feeding the conditional move (condition, first and > second source). This is why well-predicted branches are often so much > faster. > > > It is even worse when doing things like: > > if (a && b) > > where on aarch64, this can be done using only one cmp followed by one ccmp. > > NOTE on PowerPC, you could use in theory crand/cror (though this is not done > > currently and I don't know if they are profitable in any recent design). > > > > Plus aarch64 has conditional add and a few other things which improve the > > idea of a conditional move. > > I can see conditional moves are almost always a win on less > pipelined/speculative implementations. Nobody wants a change that makes code slower on our pipelined/ speculative targets, but this is a concrete case where code is already made slower. If the code before optimization has no branch, as in the case of "a = (m & b)|(~m & c)", we can be certain that replacing it with a cmov does not introduce any new data dependence. Anyway, for the case of ?:, where cmov would replace a branch, Gcc is already happy to substitute a cmov instruction. Gcc just refuses to put in a second cmov, after it, for no apparent reason.
Re: Re: Happy New Year (5)
_ ___ https://is.gd/EdQot8 697099 153911 56 vywg 5gehc5j 1v3 o6 b r1 55vtem ebioz 2mhv6 j7jg a2 ukccs 3t3 y9iabgs l8u5i ke 2b9wb7q
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Joseph S. Myers --- Test done.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #1 from CVS Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3b2b821c3f1bac2ac6dd2481f461ec33a13eac9b commit 3b2b821c3f1bac2ac6dd2481f461ec33a13eac9b Author: Joseph Myers Date: Thu Jan 9 21:44:05 2020 + Test git hooks interaction with Bugzilla. PR c/93218 * Test git hooks interaction with Bugzilla.
[Bug c/93218] New: Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 Bug ID: 93218 Summary: Test bug for testing git email integration Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org Target Milestone: --- This is for testing email integration from GCC git hooks, not a real bug.
[Bug ipa/93217] New: [10 regression] 29_atomics/atomic_ref/float.cc fails after r280040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93217 Bug ID: 93217 Summary: [10 regression] 29_atomics/atomic_ref/float.cc fails after r280040 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Looks like it is getting a bad value when it runs. Executing on host: /home/seurer/gcc/build/gcc-test2/./gcc/xg++ -shared-libgcc -B/home/seurer/gcc/build/gcc-test2/./gcc -nostdinc++ -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/sys-include -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util /home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/29_atomics/atomic_ref/float.cc -std=gnu++2a -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o ./float.exe(timeout = 600) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/./gcc/xg++ -shared-libgcc -B/home/seurer/gcc/build/gcc-test2/./gcc -nostdinc++ -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/sys-include -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util /home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/29_atomics/atomic_ref/float.cc -std=gnu++2a -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o ./float.exe PASS: 29_atomics/atomic_ref/float.cc (test for excess errors) Setting LD_LIBRARY_PATH to
[Bug c++/93143] [10 Regression] Multiple calls to static constexpr member function gives wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93143 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947 Jonathan Wakely changed: What|Removed |Added Target Milestone|10.0|9.3
[Bug libstdc++/90295] Please define ~exception_ptr inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90295 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libstdc++/81091] libstdc++ not built with large file support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091 Jonathan Wakely changed: What|Removed |Added Target Milestone|10.0|9.3
[Bug libstdc++/93205] std::discrete_distribution's operator>> causes OOM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93205 --- Comment #4 from Jonathan Wakely --- Fixed on trunk so far, but I plan to backport it to gcc-8 and gcc-9 too.
[Bug fortran/65428] ICE on nest array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65428 --- Comment #7 from Thomas Koenig --- Author: tkoenig Date: Thu Jan 9 20:57:33 2020 New Revision: 280063 URL: https://gcc.gnu.org/viewcvs?rev=280063=gcc=rev Log: Save typespec for empty array constructor. 2020-01-09 Thomas Koenig PR fortran/65428 * array.c (empty_constructor): New variable. (empty_ts): New variable. (expand_constructor): Save typespec in empty_ts. Unset empty_constructor if there is an element. (gfc_expand_constructor): Initialize empty_constructor and empty_ts. If there was no explicit constructor type and the constructor is empty, take the type from empty_ts. 2020-01-09 Thomas Koenig PR fortran/65428 * gfortran.dg/zero_sized_11.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/zero_sized_11.f90 trunk/gcc/testsuite/gfortran.dg/zero_sized_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog
[Bug testsuite/93216] [10 regression] gcc.dg/optimize-bswaphi-1.c fails starting with r280034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93216 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #2 from Andrew Pinski --- This is related to PR 92979. I had found that the bswap pass is so fragile when it came to the limit due to that issue.
[Bug testsuite/93216] [10 regression] gcc.dg/optimize-bswaphi-1.c fails starting with r280034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93216 seurer at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64-linux-gnu CC||rguenth at gcc dot gnu.org Host||powerpc64-linux-gnu Build||powerpc64-linux-gnu --- Comment #1 from seurer at gcc dot gnu.org --- It looks like this only happens on powerpc64 BE
[Bug testsuite/93216] New: [10 regression] gcc.dg/optimize-bswaphi-1.c fails starting with r280034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93216 Bug ID: 93216 Summary: [10 regression] gcc.dg/optimize-bswaphi-1.c fails starting with r280034 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/optimize-bswaphi-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O2 -fdump-tree-bswap -S -o optimize-bswaphi-1.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/optimize-bswaphi-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O2 -fdump-tree-bswap -S -o optimize-bswaphi-1.s PASS: gcc.dg/optimize-bswaphi-1.c (test for excess errors) gcc.dg/optimize-bswaphi-1.c: pattern found 3 times FAIL: gcc.dg/optimize-bswaphi-1.c scan-tree-dump-times bswap "16 bit load in target endianness found at" 4 gcc.dg/optimize-bswaphi-1.c: pattern found 5 times FAIL: gcc.dg/optimize-bswaphi-1.c scan-tree-dump-times bswap "16 bit bswap implementation found at" 4 testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 1 seconds === gcc Summary === # of expected passes1 # of unexpected failures2
[Bug debug/93206] non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206 --- Comment #11 from Carl Love --- Created attachment 47626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47626=edit 311r.dwarf2 file for v4si and the v2di test case The attached file was generated with the #if in the test program set to 1 to include the test for v4si and the second test for the v2di case. This is dwarf2 file which contains note 149 which is incorrect.
[Bug debug/93206] non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206 --- Comment #10 from Carl Love --- Created attachment 47625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47625=edit 310r.nothrow for both tests v4si and v2di The attached file was generated with the #if in the test program set to 1 to include the test for V4si and the second test for the v2di case. This is the dump file preceeding the 311r.dwarf2 file which contains note 149 which is incorrect.
[Bug debug/93206] non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206 --- Comment #9 from Carl Love --- Created attachment 47624 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47624=edit 311r.dwarf2 file for just the v2di test case The attached file was generated with the #if in the test program set to 0 so only the second test for the v2di case is done. This is dwarf2 file which contains note 111 for UNSPEC_FOO which is incorrect.
[Bug debug/93206] non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206 --- Comment #8 from Carl Love --- Created attachment 47623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47623=edit 310r.nothrow for just the __builtin_vec_foo_v2di test case The attached file was generated with the #if in the test program set to 0 so only the second test for the v2di case is done. This is the dump file preceeding the 311r.dwarf2 file which contains note 111 for UNSPEC_FOO.
[Bug d/93215] If a label is created in an asm block in a templated function, then an error is reported if the function is instantiated multiple times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93215 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. THis is invalid for reasons explained in PR 20468 *** This bug has been marked as a duplicate of bug 20468 ***
[Bug inline-asm/20468] LABEL already defined in inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20468 Andrew Pinski changed: What|Removed |Added CC||elronnd at elronnd dot net --- Comment #8 from Andrew Pinski --- *** Bug 93215 has been marked as a duplicate of this bug. ***
[Bug d/93215] New: If a label is created in an asm block in a templated function, then an error is reported if the function is instantiated multiple times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93215
Bug ID: 93215
Summary: If a label is created in an asm block in a templated
function, then an error is reported if the function is
instantiated multiple times
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: elronnd at elronnd dot net
Target Milestone: ---
Basic POC:
void asm_test(int x)() {
asm {"
label:
jmp label
";};
}
void main() {
asm_test!5();
asm_test!6();
}
[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88580 --- Comment #3 from Zavadovsky Yan --- (In reply to Petr Filipsky from comment #0) > Sorry if this kind of error has been reported already (I know that there are > already several bugs reported regarding variadic template parameter > expansion but none of them seemed to me identical to this one). I also can't find similar bugs except this one created by you.
[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88580 --- Comment #2 from Zavadovsky Yan --- Created attachment 47622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47622=edit test.ii gcc --save-temps output
[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88580
--- Comment #1 from Zavadovsky Yan ---
Got same bug with all GCC version since (at least, doesn't check older
versions) 6.3.0 and newer.
Code:
struct Base
{
Base(void*) { }
virtual ~Base() { }
};
template< typename... Ts > struct Derived : public Ts...
{
template< typename... Us > Derived(Us... args) : Ts(args...)... { }
};
int main()
{
Derived d((void*)0);
return 0;
}
Clang++ compiles it.
GCC reports error:
test.cpp: In instantiation of ‘Derived::Derived(Us ...) [with Us = {void*};
Ts = {Base}]’:
test.cpp:14:26: required from here
test.cpp:9:62: error: no matching function for call to ‘Base::Base(bool)’
9 | template< typename... Us > Derived(Us... args) : Ts(args...)... { }
| ^~~
test.cpp:3:2: note: candidate: ‘Base::Base(void*)’
3 | Base(void*) { }
| ^~~~
test.cpp:3:7: note: no known conversion for argument 1 from ‘bool’ to ‘void*’
3 | Base(void*) { }
| ^
test.cpp:1:8: note: candidate: ‘constexpr Base::Base(const Base&)’
1 | struct Base
|^~~~
test.cpp:1:8: note: no known conversion for argument 1 from ‘bool’ to ‘const
Base&’
Compilation command: g++ -std=c++14 -c test.cpp
GCC version:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #6 from Peter Bergner --- (In reply to Peter Bergner from comment #5) > (In reply to Martin Liška from comment #4) > > Yep, I can still reproduce it with the current master in a cross compiler. > > Ok, thanks. I'll see if I can recreate it with a cross since I cannot get > it to fail with a native build. I still cannot reproduce this even in a cross. What GCC and binutils configure options did you use? I'll note, that I don't have ppc header files to build against, so I cannot do a full bootstrap build, but I do get far enough to get a cc1/xgcc to compile the test case with.
[Bug bootstrap/56593] LTO profiledbootstrap fails for Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56593 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED CC||jamborm at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Martin Jambor --- At least r279561 can be bootstrapped on an x86_64-linux (the subsequent r279563 breaks normal Ada LTO bootstrapped, see PR 93214) so I believe this old bug should be marked as fixed.
[Bug debug/93206] non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206 --- Comment #7 from Jakub Jelinek --- Please attach RTL dumps then, at least the one from right before var-tracking and the var-tracking one.
[Bug debug/93206] non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206 --- Comment #6 from Bill Schmidt --- (In reply to Jakub Jelinek from comment #4) > There is no error, it is a note and if some variable at some point, even > short one, can't be described using just registers or memory, but needs the > value of the UNSPEC to describe it, there is no var-tracking bug, it just > tries to build debug info from the UNSPEC and finds out it can't. But there *is* a register that describes the variable. It's wrongly using the UNSPEC instead. I contend that this is indeed a bug.
[Bug bootstrap/93214] New: Ada LTO bootstrap fails with undefined reference to __gnat_debug_raise_assert_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93214 Bug ID: 93214 Summary: Ada LTO bootstrap fails with undefined reference to __gnat_debug_raise_assert_failure Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux Target: x86_64-linux Since r279563, Ada LTO bootstrap fails because of undefined reference to __gnat_debug_raise_assert_failure, undefined reference to __gnat_debug_raise_exception and undefined reference to __gnat_unhandled_exception. (Note that in the past I incorrectly claimed this was happening only with an old system compiler but that was a mistake). This is reproducible for example also on compile farms gcc67, just configure with --enable-languages=c,c++,ada --disable-werror --with-build-config=bootstrap-lto and run make. In the run up to the failure, there is also a number of -Wlto-type-mismatch warnings about various types not matching their "original declarations."
[Bug libstdc++/93205] std::discrete_distribution's operator>> causes OOM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93205 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Thu Jan 9 16:50:51 2020 New Revision: 280061 URL: https://gcc.gnu.org/viewcvs?rev=280061=gcc=rev Log: libstdc++: Fix undefined behaviour in random dist serialization (PR93205) The deserialization functions for random number distributions fail to check the stream state before using the extracted values. In some cases this leads to using indeterminate values to resize a vector, and then filling that vector with indeterminate values. No values that affect control flow should be used without checking that a good value was read from the stream. Additionally, where reasonable to do so, defer modifying any state in the distribution until all values have been successfully read, to avoid modifying some of the distribution's parameters and leaving others unchanged. PR libstdc++/93205 * include/bits/random.h (operator>>): Check stream operation succeeds. * include/bits/random.tcc (operator<<): Remove redundant __ostream_type typedefs. (operator>>): Remove redundant __istream_type typedefs. Check stream operations succeed. (__extract_params): New function to fill a vector from a stream. * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/include/bits/random.tcc trunk/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc
[Bug lto/93166] [10 Regression] ICE in get_info_about_necessary_edges, at ipa-cp.c:4137 since r278893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93166 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #1 from Jeffrey A. Law --- Just to pile on, I'm seeing this as well in the code-editor package builds.
[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151 --- Comment #3 from Jonathan Wakely --- POSIX doesn't allow that. If such systems exist, they should provide their own config/os/*/error_constants.h header with the correct set of constants. The generic/error_constants.h file should assume POSIX.
[Bug lto/89358] [8 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 --- Comment #18 from Martin Liška --- @Honza: Are you planning to backport it to GCC 8 or may I close it?
[Bug ipa/89762] [8 Regression] Mixing optimization levels with ostream gives lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:2098
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89762 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- I'm closing that as we're not planning to backport that.
[Bug lto/92600] [9/10 Regression] ICE: symtab_node::verify failed, building 523.xalancbmk_r with -flto -fno-inline since r267359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92600
--- Comment #5 from Martin Liška ---
Created attachment 47621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47621=edit
Clean up test-case
So the now the diff of the source file is minimal:
$ diff -u 1.ii 2.ii
--- 1.ii2020-01-09 17:14:33.000405474 +0100
+++ 2.ii2020-01-09 17:14:33.000405474 +0100
@@ -79,7 +79,6 @@
class ErrorHandler;
class XMLEntityResolver;
class XercesDOMParser : AbstractDOMParser {
- virtual void error_that_causes_ice();
bool expandSystemId(const unsigned short *, XMLBuffer &);
EntityResolver *fEntityResolver;
XMLEntityResolver *fXMLEntityResolver;
@@ -87,10 +86,4 @@
};
inline bool XercesDOMParser::expandSystemId(const unsigned short *,
XMLBuffer &) { return false; }
-int *SGXMLScanner::resolveSystemId() {
- unsigned short a;
- XMLBuffer b;
- fEntityHandler->expandSystemId(, b);
- return 0;
-}
} // namespace xercesc_2_7
Honza, does it explain now better?
[Bug debug/93206] non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206 --- Comment #5 from Carl Love --- I am puzzled. When we have both test cases included which are identical other then the data size, the notes are correct for second test case but not the first test case. When we remove the first test case, then all of the sudden the the notes are no longer correct for the second case. This seems very inconsistent to me. We should either not be able to get the notes correct for both cases or neither case. This really seems like something isn't working right and could be fixed.
[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151 --- Comment #2 from Marc Glisse --- (In reply to Jonathan Wakely from comment #1) > I don't know what the advantage of testing for them at configure time is. Strange systems that define them as enum values and not macros?
[Bug debug/93206] non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206 --- Comment #4 from Jakub Jelinek --- There is no error, it is a note and if some variable at some point, even short one, can't be described using just registers or memory, but needs the value of the UNSPEC to describe it, there is no var-tracking bug, it just tries to build debug info from the UNSPEC and finds out it can't.
[Bug fortran/58334] preprocessor behavior diffs under line continuation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58334 --- Comment #3 from markeggleston at gcc dot gnu.org --- Looks like macro expansion is performed in libcpp/traditional.c by the routine _cpp_scan_out_logical_line called by _cpp_read_logical_line_trad. I'm pretty sure that C style continuations are handled by _cpp_scan_out_logical_line. Fortran continuations are different (further complicated depending on whether it is free form or fixed form) so the continuation is treated as a new logical line and it assumed that that is no open quote thus the macro is expanded inside a string.
[Bug debug/93206] non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206 --- Comment #3 from Carl Love --- The initial bug report states that the bug moves around depending on the test case. If the test case only consists of the test for the V2DI case, you get the error that Bill was specifically stating, i.e. UNSPEC_FOO. This is done by setting the #if define in the test case to 0. If you set the #if define to 1 to include both test cases, then the bug moves to UNSPEC_VSX_SET. Perhaps this was not as clear as it could have been in the initial post. I tried to describe this behaviour in the hope it might help to find and fix the bug correctly in all cases.
[Bug c++/93210] Sub-optimal code optimization on struct/combound constexpr (gcc vs. clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93210 --- Comment #3 from Jakub Jelinek --- Ah, we already do have native_encode_initializer, so perhaps we should move it over from dwarf2out.c to fold-const.c and tweak to handle the 4 arguments instead of 3 and possibly NULL ptr.
[Bug c++/93210] Sub-optimal code optimization on struct/combound constexpr (gcc vs. clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93210 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-09 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Apparently it isn't related to anonymous aggregates at all. And, before r273435 aka https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00893.html (so e.g. in GCC 9 and earlier) we weren't simplifying the u.b case either). Since r273435 fold_array_ctor_reference can handle extraction from multiple fields, but fold_nonarray_ctor_reference still doesn't, so this PR could be fixed by teaching it to handle it. It might be also worth to either add CONSTRUCTOR support to native_encode_expr, or add a wrapper to that function for fold*ctor_reference that would handle that and perform native encoding of a whole CONSTRUCTOR (provided that its ultimate elements are only what native_encode_expr supports), but first clearing the whole range of the buffer and then just recursing in there.
[Bug analyzer/93212] internal compiler error: in make_region_for_type, at analyzer/region-model.cc:5961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93212
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malcolm ---
This fixes it, though to do this "properly" would also need DejaGnu
infrastructure for adding C++ testcases.
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 7a863e020e23..1366987512e5 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -5997,7 +5997,7 @@ make_region_for_type (region_id parent_rid, tree type)
if (TREE_CODE (type) == UNION_TYPE)
return new union_region (parent_rid, type);
- if (TREE_CODE (type) == FUNCTION_TYPE)
+ if (FUNC_OR_METHOD_TYPE_P (type))
return new function_region (parent_rid, type);
/* If we have a void *, make a new symbolic region. */
diff --git a/gcc/analyzer/region-model.h b/gcc/analyzer/region-model.h
index cdce812d7d22..1e4e9c5a47c9 100644
--- a/gcc/analyzer/region-model.h
+++ b/gcc/analyzer/region-model.h
@@ -1233,7 +1233,7 @@ public:
function_region (region_id parent_rid, tree type)
: map_region (parent_rid, type)
{
-gcc_assert (TREE_CODE (type) == FUNCTION_TYPE);
+gcc_assert (FUNC_OR_METHOD_TYPE_P (type));
}
function_region (const function_region )
: map_region (other)
[Bug analyzer/93212] internal compiler error: in make_region_for_type, at analyzer/region-model.cc:5961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93212 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-09 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. make_region_for_type doesn't know how to handle a METHOD_TYPE and hits a gcc_unreachable. Note that C++ support is out-of-scope for the analyzer for GCC 10.
[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90576 --- Comment #7 from Maxim Kuvyrkov --- Apologies for delay. Kicked off SPEC2k6 builds, and will report results tomorrow.
[Bug tree-optimization/92429] [10 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10918
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92429 --- Comment #5 from avieira at gcc dot gnu.org --- Hi Martin, Sorry about that, forgot to check it after I got back from holidays. I wrote up a patch, actually going with solution 2) (fixes both issues locally). Just running more tests now to make sure I didn't break anything else.
[Bug rtl-optimization/93159] [10 Regression] ICE (segfault) during RTL pass on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93159 Matthias Klose changed: What|Removed |Added CC||doko at ubuntu dot com --- Comment #2 from Matthias Klose --- it's reproducible, but not with the auto retires. Still need to look at that.
[Bug tree-optimization/93199] [8/9/10 Regression] Compile time hog in sink_clobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93199 --- Comment #10 from Richard Biener --- Still tree eh: 509.70 ( 97%) 1.58 ( 69%) 511.32 ( 97%) 9776324 kB ( 98%) bah. Something else ruins things. Will figure tomorrow.
[Bug tree-optimization/93213] New: [10 Regression] wrong code with -Og -foptimize-strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93213
Bug ID: 93213
Summary: [10 Regression] wrong code with -Og -foptimize-strlen
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Created attachment 47620
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47620=edit
reduced testcase
Output:
$ x86_64-pc-linux-gnu-gcc -Og -foptimize-strlen testcase.c
$ ./a.out
Aborted
At the assembly level:
...
mov WORD PTR [rsp+14], -1 # u16_1,
# testcase.c:11: __builtin_memmove (_1, _1, 1);
mov BYTE PTR [rsp+14], -1 # MEM[(char * {ref-all})_1],
...
the first memove (which woudl set u16_1 = 0) is removed
Might be related to PR92765 and PR92956.
Still observed at r280046
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-280046-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-280046-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20200109 (experimental) (GCC)
[Bug testsuite/93058] FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058 --- Comment #2 from Martin Sebor --- Suppressing the warning for the whole test should definitely work and seems to me like a reasonable way to deal with the failure. The alloc_size attribute the warning relies on doesn't provide for the rounding pvalloc does and GCC doesn't know about the function, so these (valid) use cases will trigger it. We could teach GCC about the pvalloc property but since the function is deprecated and I'm guessing rarely used it's probably not worth the trouble.
[Bug tree-optimization/93199] [8/9/10 Regression] Compile time hog in sink_clobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93199 --- Comment #9 from Richard Biener --- Created attachment 47619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47619=edit patch fixing the quadraticness Like this for the quadraticness. Still runs into other slowness. pass_lower_eh_dispatch::execute takes less than 10 seconds now.
[Bug libstdc++/93205] std::discrete_distribution's operator>> causes OOM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93205 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |8.4 --- Comment #2 from Jonathan Wakely --- The same problem exists for other operator>> overloads. It looks like all the istream reads in that file are unchecked, so full of undefined behaviour. Ouch.
[Bug c/93160] ICE: in expand_expr_addr_expr_1, at expr.c:8070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93160 --- Comment #2 from joseph at codesourcery dot com --- Yes, I think this should be rejected.
[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 Tobias Burnus changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Tobias Burnus --- (In reply to Martin Sebor from comment #16) > I would expect r280041 to suppress the warnings but I haven't tested it. > Thomas or Tobias, can one of you please verify they are gone and resolve the > bug if appropriate? I can confirm that without a slightly older GCC I still see the issue (of comment 0, with nvptx) – and after "svn up" + build, the issue is gone. Hence: FIXED. Thanks for the patch!
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 92956, which changed state. Bug 92956 Summary: [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug lto/92600] [9/10 Regression] ICE: symtab_node::verify failed, building 523.xalancbmk_r with -flto -fno-inline since r267359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92600
Martin Liška changed:
What|Removed |Added
Known to work||8.3.0
Target Milestone|--- |9.3
Summary|ICE: symtab_node::verify|[9/10 Regression] ICE:
|failed, building|symtab_node::verify failed,
|523.xalancbmk_r with -flto |building 523.xalancbmk_r
|-fno-inline |with -flto -fno-inline
||since r267359
Known to fail||10.0, 9.2.0
--- Comment #4 from Martin Liška ---
(In reply to Martin Liška from comment #3)
> It's related to PR92599. It's also an ODR violation that leads to the ICE.
So it must be something different. There are source files which do not violate
ODR:
$ cat 1.ii
unsigned short a;
namespace xercesc_2_7 {
class MemoryManager;
class XMemory {};
class XMLErrorReporter {
virtual void resetErrors();
};
class XMLBuffer {};
class XMLBufferMgr {
unsigned fBufCount;
MemoryManager *fMemoryManager;
XMLBuffer **fBufList;
};
template class RefVectorOf;
class XMLStringPool;
class GrammarResolver;
class XMLValidator;
template class ValueStackOf;
class XMLEntityHandler;
class ErrorHandler;
class XMLScanner {
public:
XMLEntityHandler *fEntityHandler;
};
class SGXMLScanner : XMLScanner {
int *resolveSystemId();
};
class XMLDocumentHandler {
virtual void endEntityReference();
};
class XMLEntityHandler {
public:
virtual bool expandSystemId(const unsigned short *, XMLBuffer &);
};
class PSVIHandler {
virtual void handleElementPSVI();
};
class DOMNode;
class DOMEntity;
class DocTypeHandler {
virtual void startIntSubset();
};
class DOMDocumentImpl;
class DOMDocumentTypeImpl;
class XMLGrammarPool;
class AbstractDOMParser : XMemory,
XMLDocumentHandler,
XMLErrorReporter,
XMLEntityHandler,
DocTypeHandler,
PSVIHandler {
bool fCreateEntityReferenceNodes;
bool fIncludeIgnorableWhitespace;
bool fWithinElement;
bool fParseInProgress;
bool fCreateCommentNodes;
bool fDocumentAdoptedByUser;
bool fCreateSchemaInfo;
XMLScanner *fScanner;
unsigned short *fImplementationFeatures;
DOMNode *fCurrentParent;
DOMNode *fCurrentNode;
DOMEntity *fCurrentEntity;
DOMDocumentImpl *fDocument;
ValueStackOf *fNodeStack;
DOMDocumentTypeImpl *fDocumentType;
RefVectorOf *fDocumentVector;
GrammarResolver *fGrammarResolver;
XMLStringPool *fURIStringPool;
XMLValidator *fValidator;
MemoryManager *fMemoryManager;
XMLGrammarPool *fGrammarPool;
XMLBufferMgr fBufMgr;
XMLBuffer
PSVIHandler *fPSVIHandler;
};
class EntityResolver;
class XMLEntityResolver;
class XercesDOMParser : AbstractDOMParser {
virtual void error();
bool expandSystemId(const unsigned short *, XMLBuffer &);
EntityResolver *fEntityResolver;
XMLEntityResolver *fXMLEntityResolver;
ErrorHandler *fErrorHandler;
};
inline bool XercesDOMParser::expandSystemId(const unsigned short *,
XMLBuffer &) { return false; }
int *SGXMLScanner::resolveSystemId() {
XMLBuffer b;
fEntityHandler->expandSystemId(, b);
return 0;
}
} // namespace xercesc_2_7
$ cat 2.ii
namespace xercesc_2_7 {
class DOMNode;
class DOMEntity;
class MemoryManager;
class XMemory {};
class XMLErrorReporter {
public:
virtual ~XMLErrorReporter();
};
template class RefVectorOf;
class XMLDocumentHandler {
virtual void XMLDecl();
};
class XMLBuffer;
class XMLEntityHandler {
virtual bool expandSystemId(const unsigned short *, XMLBuffer &);
};
template class ValueStackOf;
class GrammarResolver;
class XMLStringPool;
class DocTypeHandler {
public:
virtual ~DocTypeHandler();
};
class XMLBufferMgr {
unsigned fBufCount;
MemoryManager *fMemoryManager;
XMLBuffer **fBufList;
};
class PSVIHandler {
virtual void handlePartialElementPSVI();
};
class XMLScanner;
class XMLValidator;
class DOMDocumentImpl;
class DOMDocumentTypeImpl;
class XMLGrammarPool;
class AbstractDOMParser : XMemory,
XMLDocumentHandler,
XMLErrorReporter,
XMLEntityHandler,
DocTypeHandler,
PSVIHandler {
bool fCreateEntityReferenceNodes;
bool fIncludeIgnorableWhitespace;
bool fWithinElement;
bool fParseInProgress;
bool fCreateCommentNodes;
bool fDocumentAdoptedByUser;
bool fCreateSchemaInfo;
XMLScanner *fScanner;
unsigned short *fImplementationFeatures;
DOMNode *fCurrentParent;
DOMNode *fCurrentNode;
DOMEntity *fCurrentEntity;
DOMDocumentImpl *fDocument;
ValueStackOf *fNodeStack;
DOMDocumentTypeImpl *fDocumentType;
RefVectorOf *fDocumentVector;
[Bug libstdc++/93208] duplicated memory_resource, monotomic_buffer_resource vtable, type_info d/t all-inline virtual functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208 --- Comment #7 from Marc Mutz --- Thanks!
[Bug analyzer/93212] New: internal compiler error: in make_region_for_type, at analyzer/region-model.cc:5961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93212
Bug ID: 93212
Summary: internal compiler error: in make_region_for_type, at
analyzer/region-model.cc:5961
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Compiling
#include
auto lol()
{
int aha = 3;
return [] {
return aha;
};
}
int main()
{
auto lambda = lol();
std::cout << lambda() << std::endl;
return 0;
}
on the static analysis branch gives an ICE:
during IPA pass: analyzer
: In function 'int main(int, char**)':
:13:25: internal compiler error: in make_region_for_type, at
analyzer/region-model.cc:5961
13 | std::cout << lambda() << std::endl;
| ^
Thanks to Vaclav K. who found this bug.
[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151 --- Comment #1 from Jonathan Wakely --- The config/os/generic/error_constants.h file already uses these macros conditionally: #ifdef _GLIBCXX_HAVE_ENOTRECOVERABLE state_not_recoverable = ENOTRECOVERABLE, #endif The problem is that we use those config macros, which are fixed when libstdc++ is built and don't match the set of available macros when preprocessing the header. We should either do: #if defined _GLIBCXX_HAVE_ENOTRECOVERABLE && defined ENOTRECOVERABLE state_not_recoverable = ENOTRECOVERABLE, #endif or simply: #ifdef ENOTRECOVERABLE state_not_recoverable = ENOTRECOVERABLE, #endif I don't know what the advantage of testing for them at configure time is.
[Bug c++/93211] New: equivalence of dependent function calls doesn't check if the call is eligible for ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93211
Bug ID: 93211
Summary: equivalence of dependent function calls doesn't check
if the call is eligible for ADL
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
Consider this code:
// https://gcc.godbolt.org/z/3U2TTd
#include
template
void g(T);
template
void f() {} // (1)
template
void f() {} // (2)
Question is whether (1) and (2) are (re)definition of the same function or
definitions of two different functions. Currently GCC believes that this is a
redefinition of the same function.
I think (1) and (2) should be definitions of two different functions, because
"decltype(g(T{}))" and "decltype(::g(T{}))" are susceptible to different SFINAE
errors: the overload candidate set of (2) is fixed and the overload candidate
set of (1) can be extended arbitrary by ADL.
[Bug libstdc++/54043] [LWG 2221] cout << nullptr does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #18 from Jonathan Wakely --- This was fixed for GCC 9.1 by r267808
[Bug libstdc++/58605] [DR 2334] atomic::atomic() disobeys [atomics.types.operations.req]p4 for types with user-defined default constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58605 Jonathan Wakely changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #5 from Jonathan Wakely --- Issue 2334 has been resolved by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0883r2.pdf and the ridiculous "do magic init" requirement is gone. However, we do have some work to do, as the constructors now need to be constexpr for C++20 and the default constructor in the primary template should have a noexcept-specifier. Changing status to NEW so we do that.
[Bug target/93206] non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #2 from Bill Schmidt --- (In reply to Jakub Jelinek from comment #1) > note: non-delegitimized UNSPEC > is just a debugging note solely in non-release checking builds. Not all > UNSPECs need to be delegitimized, it is just a hint that it is something > that could be inspected, whether it can be easily delegitimized or not (see > rs6000_delegitimize_address). > As UNSPEC_FOO is not in upstream GCC, I fail to see the need for upstream PR. What may not be crystal clear here is that var-tracking is making a mistake. The original problem doesn't look quite like the obfuscated one here -- this came up while working on some future work where an UNSPEC does seem necessary. We get something like result = complex-thing-needing-UNSPEC result = expression-involving-result where both definitions of result get assigned to the same register, say r31. The first statement has a var_location note saying result is in r31. The second statement has a var_location note saying result is in the UNSPEC RTL generated from complex-thing-needing-UNSPEC. This is absolutely wrong, because result is once again in r31 at this point; it's a new lifetime of result, but that's where it is. That's the bug we're attempting to report here. Unfortunately, as the test was changed to hide stuff we can't disclose yet, the error message moved to a different place and another UNSPEC, which as you note is less obviously necessary as an UNSPEC anyway. But that's an unimportant detail. This var-tracking bug is making it hard to develop the code for this new feature. The original test was testing four versions of this instruction, each with a different mode. Only the V4DI version fails due to the var-tracking error. So the upstream PR is needed so development can proceed. > Anyway, I have to wonder why vsx.md uses so many UNSPECs, can't e.g. > UNSPEC_VSX_SET be just using vec_merge of vec_duplicate of the scalar > operand (what is inserted) and the vector operand, with the position as last > operand? > Is the reason the endian correction? There are too many unnecessary UNSPECs in the Power back end, yeah. We're rooting those out as we have time. But this bug shows up with a necessary UNSPEC originally, so that's not relevant for this report.
[Bug libstdc++/86852] [DR 3025] map and unordered_map wrong deduction guides for inilializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86852 Jonathan Wakely changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jonathan Wakely --- Issue 3025 has been resolved and the C++20 draft agrees with libstdc++ now, so I don't think there's any bug.
[Bug libstdc++/93208] duplicated memory_resource, monotomic_buffer_resource vtable, type_info d/t all-inline virtual functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.3 --- Comment #6 from Jonathan Wakely --- Fixed for 9.3
[Bug c++/93210] Sub-optimal code optimization on struct/combound constexpr (gcc vs. clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93210
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
>From C++ POV, Should when passed by reference to the operator== is odr-used and
therefore the static data member definition is required (unless C++17 or newer
where it is inline variable and the definition is already in the class
definition).
The rest is just a matter of optimization, where we for yet to be determined
reason punt in the anonymous struct in union case, as can be seen on C testcase
(but likewise with C++):
union U { int a[2]; long long b; };
static const union U u = { .a = { 1, 2 } };
union V { struct { int a, b; }; long long c; };
static const union V v = { { 1, 2 } };
void qux (const union U *, const union V *);
long long
foo (void)
{
if (sizeof (long long) == 2 * sizeof (int))
return u.b;
else
return -1;
}
long long
bar (void)
{
if (sizeof (long long) == 2 * sizeof (int))
return v.c;
else
return -1;
}
void
baz (void)
{
qux (, );
}
[Bug fortran/84135] [8/9/10 Regression] ICE in gfc_trans_array_cobounds, at fortran/trans-array.c:6033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84135 --- Comment #9 from Tobias Burnus --- Author: burnus Date: Thu Jan 9 13:43:59 2020 New Revision: 280046 URL: https://gcc.gnu.org/viewcvs?rev=280046=gcc=rev Log: Fortran] PR84135 fix merging dimension into codimension array spec PR fortran/84135 * array.c (gfc_set_array_spec): Fix shifting of codimensions when adding a dimension. * decl.c (merge_array_spec): Ditto. Fix using correct codimensions. PR fortran/84135 * gfortran.dg/coarray/codimension_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray/codimension_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/93208] duplicated memory_resource, monotomic_buffer_resource vtable, type_info d/t all-inline virtual functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Thu Jan 9 13:18:37 2020 New Revision: 280045 URL: https://gcc.gnu.org/viewcvs?rev=280045=gcc=rev Log: libstdc++: Define memory resource key functions non-inline (PR93208) This prevents the vtables and RTTI from being emitted in every object file that uses memory_resource and monotonic_buffer_resource. Objects compiled by GCC 9.1 or 9.2 will contain inline definitions of the destructors, vtable and RTTI, but this is harmless. The inline definitions have identical effects to the ones that are now defined in libstdc++.so so it doesn't matter if the inline ones are used instead of calling the symbols exported from the runtime library. PR libstdc++/93208 * config/abi/pre/gnu.ver: Add new exports. * include/std/memory_resource (memory_resource::~memory_resource()): Do not define inline. (monotonic_buffer_resource::~monotonic_buffer_resource()): Likewise. * src/c++17/memory_resource.cc (memory_resource::~memory_resource()): Define. (monotonic_buffer_resource::~monotonic_buffer_resource()): Define. * testsuite/20_util/monotonic_buffer_resource/93208.cc: New test. Added: branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/monotonic_buffer_resource/93208.cc Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/config/abi/pre/gnu.ver branches/gcc-9-branch/libstdc++-v3/include/std/memory_resource branches/gcc-9-branch/libstdc++-v3/src/c++17/memory_resource.cc
[Bug libstdc++/93208] duplicated memory_resource, monotomic_buffer_resource vtable, type_info d/t all-inline virtual functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Thu Jan 9 13:18:20 2020 New Revision: 280044 URL: https://gcc.gnu.org/viewcvs?rev=280044=gcc=rev Log: libstdc++: Define memory resource key functions non-inline (PR93208) This prevents the vtables and RTTI from being emitted in every object file that uses memory_resource and monotonic_buffer_resource. Objects compiled by GCC 9.1 or 9.2 will contain inline definitions of the destructors, vtable and RTTI, but this is harmless. The inline definitions have identical effects to the ones that are now defined in libstdc++.so so it doesn't matter if the inline ones are used instead of calling the symbols exported from the runtime library. PR libstdc++/93208 * config/abi/pre/gnu.ver: Add new exports. * include/std/memory_resource (memory_resource::~memory_resource()): Do not define inline. (monotonic_buffer_resource::~monotonic_buffer_resource()): Likewise. * src/c++17/memory_resource.cc (memory_resource::~memory_resource()): Define. (monotonic_buffer_resource::~monotonic_buffer_resource()): Define. * testsuite/20_util/monotonic_buffer_resource/93208.cc: New test. Added: trunk/libstdc++-v3/testsuite/20_util/monotonic_buffer_resource/93208.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/std/memory_resource trunk/libstdc++-v3/src/c++17/memory_resource.cc
[Bug driver/93196] GCC compiles c code, provides no executable output with option -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196
--- Comment #17 from xiehongbiao ---
(In reply to Andrew Pinski from comment #16)
> I don't see anything wrong with strace of the -O2 case. In fact I see:
> [pid 10270] stat("a.out", {st_mode=S_IFREG|0755, st_size=8592, ...}) = 0
> [pid 10270] lstat("a.out", {st_mode=S_IFREG|0755, st_size=8592, ...}) = 0
> [pid 10270] unlink("a.out") = 0
> [pid 10270] open("a.out", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
>
> ;; lots of writes
> [pid 10270] close(3)= 0
> [pid 10270] stat("a.out", {st_mode=S_IFREG|0644, st_size=8592, ...}) = 0
> [pid 10270] umask(0)= 022
> [pid 10270] umask(022) = 0
> [pid 10270] chmod("a.out", 0755)= 0
>
> The only thing I can think of is that the filesystem you are using has a
> race condition in it; in that the unlink happens after the open even though
> it was invoked first. I have seen this when this when using NFS servers
> sometimes.
>
> What file system are you using?
Thank you Andrew. It sounds reasonable. The filesystem is ext4.
Today I tried it in another PC. It's ubuntu16.04 as well. The gcc version I
tried is also 5.4.0 and 4.9. I don't know why but this problem can't be
reproduced on that mechine. The filesystem is also ext4
[Bug other/87695] Arduino: ICE with avr and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695 --- Comment #18 from Georg-Johann Lay --- I am inclined to close all these PRs as invalid because there is still no valid bug report, i.e. none of the reports enabled us to reproduce the issue AND it is against a version no more supported (the 1st report was actually filed 1 1/2 years after v5 support ended) AND we were not able to find out whether the problems are due to changes introduced by the distributor. Please report this problems to Microchip. Maybe someone knows the correct bug URL to report this to Microchip and can it post here. Thanks.
[Bug c++/93209] What is a bitfield's "underlying type"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93209 --- Comment #5 from John Adriaan --- @RichardBiener, By "it still happens", I meant that accesses to `s.i` still occur as described. Changing `s.b` to be of type `unsigned` changes its accesses to match those of `s.i` - in other words, the type mismatch is not a factor.
[Bug driver/93196] GCC compiles c code, provides no executable output with option -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196
--- Comment #16 from Andrew Pinski ---
I don't see anything wrong with strace of the -O2 case. In fact I see:
[pid 10270] stat("a.out", {st_mode=S_IFREG|0755, st_size=8592, ...}) = 0
[pid 10270] lstat("a.out", {st_mode=S_IFREG|0755, st_size=8592, ...}) = 0
[pid 10270] unlink("a.out") = 0
[pid 10270] open("a.out", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
;; lots of writes
[pid 10270] close(3)= 0
[pid 10270] stat("a.out", {st_mode=S_IFREG|0644, st_size=8592, ...}) = 0
[pid 10270] umask(0)= 022
[pid 10270] umask(022) = 0
[pid 10270] chmod("a.out", 0755)= 0
The only thing I can think of is that the filesystem you are using has a race
condition in it; in that the unlink happens after the open even though it was
invoked first. I have seen this when this when using NFS servers sometimes.
What file system are you using?
[Bug driver/93196] GCC compiles c code, provides no executable output with option -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196 --- Comment #15 from xiehongbiao --- (In reply to Martin Liška from comment #14) > (In reply to xiehongbiao from comment #13) > > (In reply to Martin Liška from comment #9) > > > Can you please attach output for strace -f -s512 of the problematic > > > execution? > > > > Please help check the strace log (attached). Thanks. > > You attached strace log for the configuration that produces a.out. I will > need the failing options. It contains 2 executions. -O2 and -O1. Please find the failing case from the beginning of the log.It ended at line 2220
[Bug driver/93196] GCC compiles c code, provides no executable output with option -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196 --- Comment #14 from Martin Liška --- (In reply to xiehongbiao from comment #13) > (In reply to Martin Liška from comment #9) > > Can you please attach output for strace -f -s512 of the problematic > > execution? > > Please help check the strace log (attached). Thanks. You attached strace log for the configuration that produces a.out. I will need the failing options.
[Bug driver/93196] GCC compiles c code, provides no executable output with option -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196 --- Comment #13 from xiehongbiao --- (In reply to Martin Liška from comment #9) > Can you please attach output for strace -f -s512 of the problematic > execution? Please help check the strace log (attached). Thanks.
[Bug driver/93196] GCC compiles c code, provides no executable output with option -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196 --- Comment #12 from xiehongbiao --- Created attachment 47618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47618=edit strace log
[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90576 --- Comment #6 from Martin Liška --- (In reply to Martin Liška from comment #5) > @Maxim: Can you please retest it? PING
[Bug rtl-optimization/93159] [10 Regression] ICE (segfault) during RTL pass on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93159 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The bug is not reproducible, so it is likely a hardware or OS problem. so, is it random or reproduceable? If the latter, can you please attach preprocessed source and full cc1plus command line?
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 90004, which changed state. Bug 90004 Summary: [graphite] ICE: Segmentation fault (in scop_get_dependences(scop*)) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90004 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/93134] [graphite] ICE: Segmentation fault in ISL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93134 --- Comment #11 from Arseny Solokha --- *** Bug 90004 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/90004] [graphite] ICE: Segmentation fault (in scop_get_dependences(scop*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90004 Arseny Solokha changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Arseny Solokha --- Patch [1] fixes all three ICEs in this PR. [1] https://groups.google.com/forum/#!original/isl-development/Otz1QKZDpzA/71GkTvqkCAAJ *** This bug has been marked as a duplicate of bug 93134 ***
[Bug driver/93196] GCC compiles c code, provides no executable output with option -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196 --- Comment #11 from Martin Liška --- (In reply to xiehongbiao from comment #10) > (In reply to Andrew Pinski from comment #8) > > Can you also add -Wl,-v ; this will cause collect2 to print it runs? > > It reports error :"gcc: error: unrecognized command line option ‘-Wl’". > Please let me know if I misunderstood. Thanks. Paste the details: > > > jiaojiancheng@jiaojiancheng:~/test_compile$ gcc -O1 -pedantic > -fomit-frame-pointer -m64 -Wl -v conftest.c It must be '-Wl,-v' not '-Wl -v'.
[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 --- Comment #16 from Martin Sebor --- I would expect r280041 to suppress the warnings but I haven't tested it. Thomas or Tobias, can one of you please verify they are gone and resolve the bug if appropriate?
[Bug driver/93196] GCC compiles c code, provides no executable output with option -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196 --- Comment #10 from xiehongbiao --- (In reply to Andrew Pinski from comment #8) > Can you also add -Wl,-v ; this will cause collect2 to print it runs? It reports error :"gcc: error: unrecognized command line option ‘-Wl’". Please let me know if I misunderstood. Thanks. Paste the details: jiaojiancheng@jiaojiancheng:~/test_compile$ gcc -O1 -pedantic -fomit-frame-pointer -m64 -Wl -v conftest.c Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper gcc: error: unrecognized command line option ‘-Wl’ Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.3-13ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.3 (Ubuntu 4.9.3-13ubuntu2)
[Bug tree-optimization/92429] [10 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10918
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92429 --- Comment #4 from Martin Liška --- @avieira: Any progress on this one please?
[Bug middle-end/93200] [10 Regression] spurious -Wstringop-overflow due to assignment vectorization to multiple members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93200 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Sebor --- The warning has been temporarily suppressed for these cases, until a longer term solution is put in place.
[Bug middle-end/93200] [10 Regression] spurious -Wstringop-overflow due to assignment vectorization to multiple members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93200 --- Comment #5 from Martin Sebor --- Author: msebor Date: Thu Jan 9 11:59:41 2020 New Revision: 280041 URL: https://gcc.gnu.org/viewcvs?rev=280041=gcc=rev Log: PR middle-end/93200 - spurious -Wstringop-overflow due to assignment vectorization to multiple members PR fortran/92956 - 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning gcc/testsuite/ChangeLog: PR middle-end/93200 * gcc.dg/Wstringop-overflow-30.c: New test. gcc/ChangeLog: PR middle-end/93200 PR fortran/92956 * builtins.c (compute_objsize): Avoid handling MEM_REFs of vector type. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-30.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 93200, which changed state. Bug 93200 Summary: [10 Regression] spurious -Wstringop-overflow due to assignment vectorization to multiple members https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93200 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 --- Comment #15 from Martin Sebor --- Author: msebor Date: Thu Jan 9 11:59:41 2020 New Revision: 280041 URL: https://gcc.gnu.org/viewcvs?rev=280041=gcc=rev Log: PR middle-end/93200 - spurious -Wstringop-overflow due to assignment vectorization to multiple members PR fortran/92956 - 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning gcc/testsuite/ChangeLog: PR middle-end/93200 * gcc.dg/Wstringop-overflow-30.c: New test. gcc/ChangeLog: PR middle-end/93200 PR fortran/92956 * builtins.c (compute_objsize): Avoid handling MEM_REFs of vector type. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-30.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/93144] [10 Regression] 459.GemsFDTD debug info size increase by 50% since r279563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93144 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from Martin Liška --- There's a small change in .text as well: ~/Programming/bloaty/bloaty /tmp/after/GemsFDTD -- /tmp/before/GemsFDTD VM SIZE FILE SIZE -- -- [ = ] 0 .debug_loc +181Ki +131% +6.0% +32.9Ki .text +32.9Ki +6.0% [ = ] 0 .debug_ranges +17.6Ki +58% [ = ] 0 .debug_info +1.77Ki +1.0% [ = ] 0 .debug_line +872 +1.9% [ = ] 0 .debug_abbrev+130 +1.4% +0.3% +64 .bss0 [ = ] +60% +12 [LOAD [RW]] 0 [ = ] -4.2% -12 .data -12 -4.2% -7.2% -32 .eh_frame_hdr -32 -7.2% -0.3% -48 .rodata -48 -0.3% [ = ] 0 .symtab -96 -0.4% [ = ] 0 .strtab -176 -1.5% [ = ] 0 .debug_str -239 -1.3% -7.9%-248 .eh_frame-248 -7.9% [ = ] 0 [Unmapped] -546 -7.0% +5.5% +32.6Ki TOTAL +232Ki +23% Looking at the gcc-patches discussion, before the patch, ipa_size_summary was wrongly set to 0 for clones. @Honza: Can we close this issue?
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #18 from Jakub Jelinek ---
Guess best would be to go through the ranges from first to last, check for the
pattern we are interested in (ranges[i].exp being SSA_NAME with BIT_AND_EXPR
def with constant where ranges[i].low == ranges[i].high is an integer, so is
the second operand of BIT_AND_EXPR, verify also the condition we've discussed
above ((CST1&~N) == 0) and whether ranges[i].in_p matches the kind of operation
(opcode and for opcode ERROR_MARK dig out the || vs. &&), push e.g. indexes of
those ranges into a vector, then have a gcc_sort_r callback that will put the
indexes for the same BIT_AND_EXPR first operand next to each other and then
just go through them, construct a new comparison for all the adjacent entries
for the same base var and nullify the rest.
Testcase showing why it is needed:
void bar (void);
int
f1 (int a)
{
return (a & 8) == 8 && (a & 2) == 2 && (a & 4) == 4;
}
int
f2 (int a)
{
int x = (a & 8) == 8;
int y = (a & 2) == 2;
int z = (a & 4) == 4;
return x && y && z;
}
int
f3 (int a)
{
return (a & (8 | 2 | 4)) == (8 | 2 | 4);
}
void
f4 (int a)
{
int x = (a & 8) == 8;
int y = (a & 2) == 2;
int z = (a & 4) == 4;
int u = (a & 16) == 16;
int v = (a & 64) == 64;
int w = (a & 256) == 256;
if (x && y && z && u && v && w)
bar ();
}
int
f5 (int a)
{
return (a & 8) != 8 || (a & 2) != 2 || (a & 4) != 4;
}
int
f6 (int a)
{
int x = (a & 8) != 8;
int y = (a & 2) != 2;
int z = (a & 4) != 4;
return x || y || z;
}
int
f7 (int a)
{
return (a & (8 | 2 | 4)) != (8 | 2 | 4);
}
void
f8 (int a)
{
int x = (a & 8) != 8;
int y = (a & 2) != 2;
int z = (a & 4) != 4;
int u = (a & 16) != 16;
int v = (a & 64) != 64;
int w = (a & 256) != 256;
if (x || y || z || u || v || w)
bar ();
}
[Bug ipa/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 --- Comment #7 from Georg-Johann Lay --- (In reply to Richard Biener from comment #6) > or whether the backend "forgets" to set DECL_SECTION_NAME or the like. That caused problems (don't remember which ones exactly, maybe to make -fdata-sections work). The section is set in TARGET_ASM_SELECT_SECTION so the middle-end knows the section (in principle). But presumably the middle-end concept is broken, because telling what section belongs to a decl is not enough to convince the middle-end that the section belongs to the decl... It's gcc after all. (Very) old versions did set DECL_SECTION_NAME in insert_attributes, but that's no more the case. Presumably to fix one of the 100s of FIXMEs in the avr backend. > Similarly address-spaces need to be honored (I bet avr would have one -- is > PROGMEM actually an address-space implementation-wise?) No, progmem is just an attribute and dates back to the times when there was no address-spaces in gcc. It's still supposed to be supported because old code should still work, and because g++ will never have address-spaces. > I see there's a 'progmem' target attribute but its effects might be hidden > completely from the middle-end. That's why I opened PR92932. As mentioned in comment #3, the bug also appears for address-space __flash.
