[Bug libstdc++/97311] New: Bug in std::seed_seq::generate() when integer type has more than 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311 Bug ID: 97311 Summary: Bug in std::seed_seq::generate() when integer type has more than 32 bits Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: kristian.spangsege at gmail dot com Target Milestone: --- As far as I can tell, std::seed_seq::generate() has a bug when _Type has more than 32 bits. The problem is that the following two additions can produce values greater than, or equal to 2**32: __begin[(__k + __p) % __n] += __r1; __begin[(__k + __q) % __n] += __r2; According to C++17 standard text, all operations must be performed modulo 2**32, so no generated value can be greater than, or equal to 2**32. It seems that a possible fix would be to change those two lines to something like this: __begin[(__k + __p) % __n] = __detail::__mod<_Type, __detail::_Shift<_Type, 32>::__value>(__begin[(__k + __p) % __n] + __r1)); __begin[(__k + __q) % __n] = __detail::__mod<_Type, __detail::_Shift<_Type, 32>::__value>(__begin[(__k + __q) % __n] + __r2));
[Bug bootstrap/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308 Thomas Koenig changed: What|Removed |Added Component|fortran |bootstrap --- Comment #7 from Thomas Koenig --- Not really a Fortran bug, I probably clicked on that out of habit. Regarding the original issue: I still think it is a bug to unconditionally use a gcc when that is too old, when a new version of clang is available which should work in principle (modulo the -lc issue).
[Bug libbacktrace/97310] New: new test case mtest_minidebug from r11-3196 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97310 Bug ID: 97310 Summary: new test case mtest_minidebug from r11-3196 fails on powerpc64 BE Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: ian at gcc dot gnu.org Target Milestone: --- g:05f40bc4c116ba48843728201bc7290a5e518598, r11-3196 Author: Ian Lance Taylor Date: Mon Sep 14 14:01:56 2020 -0700 libbacktrace: support MiniDebugInfo make check ... FAIL: mtest_minidebug ... Testsuite summary for package-unused version-unused ... # FAIL: 1 libbacktrace/mtest_minidebug.log shows: test1: [0]: syminfo did not find name test1: [1]: syminfo did not find name test1: [2]: syminfo did not find name test1: [0]: missing function name test1: [1]: missing function name test1: [2]: missing function name test3: [0]: NULL syminfo name test3: [1]: NULL syminfo name test3: [2]: NULL syminfo name FAIL: backtrace_full noinline FAIL: backtrace_simple noinline PASS: backtrace_syminfo variable FAIL mtest_minidebug (exit status: 1) This may be related to or the same as pr97082 but I am not certain of that.
[Bug go/92564] libgo regression in runtime test resulting in SIGSEGV on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92564 Alan Modra changed: What|Removed |Added CC|amodra at gcc dot gnu.org | --- Comment #2 from Alan Modra --- Did you try Ian's suggestion of -Wl,--split-stack-adjust-size=0x8000 or even larger?
[Bug analyzer/97116] Fix argument numbering in C++ member function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116 --- Comment #3 from David Malcolm --- is_method seems to be set by: if (TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE) so perhaps we can simply reimplement this logic
[Bug analyzer/97116] Fix argument numbering in C++ member function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116 --- Comment #2 from David Malcolm --- (using "i - is_method" as the value)
[Bug analyzer/97116] Fix argument numbering in C++ member function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116 --- Comment #1 from David Malcolm --- The C++ FE has %P for printing parm indices, with index < 0 printed as "this"; implemented in cp/error.c: parm_to_string as called from cp_printer.
[Bug middle-end/90861] OpenACC 'declare' not cleaning up for VLAs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861 Tobias Burnus changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Tobias Burnus --- (In reply to Thomas Schwinge from comment #8) > let's please also update 'c-c++-common/goacc/declare-pr90861.c' Well spotted – now FIXED. Thanks for spotting – and to Tom for fixing the actual issue.
[Bug c++/97297] typename wrongly required in out-of-class member function definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97297 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Marek Polacek --- Fixed in GCC 11. I could backport it if someone wants me to.
[Bug c++/97297] typename wrongly required in out-of-class member function definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97297
--- Comment #2 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:85307b4e938d42201d6c232f5d9259f91133a303
commit r11-3688-g85307b4e938d42201d6c232f5d9259f91133a303
Author: Marek Polacek
Date: Mon Oct 5 17:48:19 2020 -0400
c++: typename in out-of-class member function definitions [PR97297]
I was notified that our P0634R3 (Down with typename) implementation has
a flaw: when we have an out-of-class member function definition, we
still required 'typename' for its parameters. For example here:
template struct S {
int simple(T::type);
};
template
int S::simple(/* typename */T::type) { return 0; }
the 'typename' isn't necessary per [temp.res]/5.2.4. We have a qualified
name here ("S::simple") so we know it's already been declared so we
can look it up to see if it's a function template or a variable
template.
In this case, the P0634R3 code in cp_parser_direct_declarator wasn't
looking into uninstantiated templates and didn't find the member
function 'simple' -- cp_parser_lookup_name returned a SCOPE_REF which
means that the qualifying scope was dependent. With this fix, we find
the BASELINK for 'simple', don't clear CP_PARSER_FLAGS_TYPENAME_OPTIONAL
from the flags, and the typename is implicitly assumed.
gcc/cp/ChangeLog:
PR c++/97297
* parser.c (cp_parser_direct_declarator): When checking if a
name is a function template declaration for the P0634R3 case,
look in uninstantiated templates too.
gcc/testsuite/ChangeLog:
PR c++/97297
* g++.dg/cpp2a/typename18.C: New test.
[Bug middle-end/90861] OpenACC 'declare' not cleaning up for VLAs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861 --- Comment #9 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:a9802204603616df14ed47d05f1b86f1bd08d8fb commit r11-3687-ga9802204603616df14ed47d05f1b86f1bd08d8fb Author: Tobias Burnus Date: Tue Oct 6 23:34:21 2020 +0200 c-c++-common/goacc/declare-pr90861.c: Remove xfail gcc/testsuite/ChangeLog PR middle-end/90861 * c-c++-common/goacc/declare-pr90861.c: Remove xfail.
[Bug other/97309] Improve documentation of -fallow-store-data-races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309
--- Comment #1 from qinzhao at gcc dot gnu.org ---
proposed patch:
Subject: [PATCH] PR97309--improve documentation of -fallow-store-data-races
---
gcc/doc/invoke.texi | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7c81d7f41bd..926ee1ff28e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -11621,7 +11621,18 @@ Do not remove unused C++ allocations in dead code
elimination.
@item -fallow-store-data-races
@opindex fallow-store-data-races
-Allow the compiler to introduce new data races on stores.
+Allow the compiler to perform optimizations that may introduce new data races
+on stores, without proving that the variable cannot be concurrently accessed
+by other threads. Does not affect optimization of local data. It is safe to
+use this option if it is known that global data will not be accessed by
+multiple threads.
+
+Examples of optimizations enabled by @option{-fallow-store-data-races} include
+hoisting or if-conversions that may cause a value that was already in memory
+to be re-written with that same value. Such re-writing is safe in a single
+threaded context but may be unsafe in a multi-threaded context. Note that on
+some processors, if-conversions may be required in order to enable
+vectorization.
Enabled at level @option{-Ofast}.
--
2.11.0
[Bug fortran/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308 Thomas Koenig changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97304 --- Comment #6 from Thomas Koenig --- The failing config.log from libgomp contains ld: error: unable to find library -lc so this might be closely related to / a duplicate of PR 97304, which has the identical error message for a different BSD version with clang.
[Bug go/92564] libgo regression in runtime test resulting in SIGSEGV on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92564 boger at gcc dot gnu.org changed: What|Removed |Added CC||amodra at gcc dot gnu.org, ||amodra at gmail dot com --- Comment #1 from boger at gcc dot gnu.org --- More information on this bug has been added to https://github.com/golang/go/issues/36697. The problem appears to be due the use of split stack and possibly the gold linker is not handling the split stack functions correctly in libgcc generic-morestack.c.
[Bug fortran/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308 --- Comment #5 from Jonathan Wakely --- ld: error: unable to find library -lc Huh, not sure what causes that one.
[Bug fortran/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308 --- Comment #4 from Thomas Koenig --- Created attachment 49320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49320=edit config.log from failing libgomp OK, so that one isn't a bug. I hope you don't mind if I put in the next failure after bootstrapping with the system compiler, clang 8 (setting CC to cc and CXX to c++): gmake[4]: Leaving directory '/home/tkoenig/trunk-clang/x86_64-unknown-openbsd6.7/libgcc' gmake[3]: Leaving directory '/home/tkoenig/trunk-clang/x86_64-unknown-openbsd6.7/libgcc' mkdir x86_64-unknown-openbsd6.7/libgomp Checking multilib configuration for libgomp... Configuring stage 1 in x86_64-unknown-openbsd6.7/libgomp configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for --enable-generated-files-in-srcdir... no checking build system type... x86_64-unknown-openbsd6.7 checking host system type... x86_64-unknown-openbsd6.7 checking target system type... x86_64-unknown-openbsd6.7 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p checking for gawk... awk checking whether gmake sets $(MAKE)... yes checking whether gmake supports nested variables... yes checking for x86_64-unknown-openbsd6.7-gcc... /home/tkoenig/trunk-clang/./gcc/xgcc -B/home/tkoenig/trunk-clang/./gcc/ -B/home/tkoenig/x86_64-unknown-openbsd6.7/bin/ -B/home/tkoenig/x86_64-unknown-openbsd6.7/lib/ -isystem /home/tkoenig/x86_64-unknown-openbsd6.7/include -system /home/tkoenig/x86_64-unknown-openbsd6.7/sys-include -fno-checking checking whether the C compiler works... no configure: error: in `/home/tkoenig/trunk-clang/x86_64-unknown-openbsd6.7/libgomp': configure: error: C compiler cannot create executables See `config.log' for more details gmake[2]: *** [Makefile:24794: configure-stage1-target-libgomp] Error 77 gmake[2]: Leaving directory '/home/tkoenig/trunk-clang' gmake[1]: *** [Makefile:27002: stage1-bubble] Error 2 gmake[1]: Leaving directory '/home/tkoenig/trunk-clang' gmake: *** [Makefile:1004: all] Error 2 obsd$
[Bug other/97309] New: Improve documentation of -fallow-store-data-races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309 Bug ID: 97309 Summary: Improve documentation of -fallow-store-data-races Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: qinzhao at gcc dot gnu.org Target Milestone: --- As of GCC 10, the former --param allow-store-data-races is now -fallow-store-data-races. The default, in both cases, is not to allow them. For releases prior to GCC 10, the --param is documented as allow-store-data-races Allow optimizers to introduce new data races on stores. Set to 1 to allow, otherwise to 0. The description for GCC 10 is simply: -fallow-store-data-races Allow the compiler to introduce new data races on stores. Enabled at level -Ofast. There are three problems with this description. (1) The explanation is sparse - basically it just repeats the name of the switch. (2) It provides no context to explain the circumstances under which it may or may not be safe to use. (3) Because of the lack of clarity regarding safety, it may be questionable as to whether a SPEC CPU user is allowed to use -Ofast (http://www.spec.org/cpu2017/Docs/runrules.html#safe) Suggested improvement: Allow the compiler to perform optimizations that may introduce new data races on stores, without proving that the variable cannot be concurrently accessed by other threads. Does not affect optimization of local data. It is safe to use this option if it is known that global data will not be accessed by multiple threads. Examples of optimizations enabled by -fallow-store-data-races include hoisting or if-conversions that may cause a value that was already in memory to be re-written with that same value. Such re-writing is safe in a single threaded context but may be unsafe in a multi-threaded context. Note that on some processors, if-conversions may be required in order to enable vectorization.
[Bug fortran/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308 --- Comment #3 from Jonathan Wakely --- The /lib/cpp error is a bit misleading, because that's the last thing it tries to find as a C++ compiler, after exhausting g++ -std=c++11 and various other options that fail with: configure:19863: g++ -std=c++11 -E conftest.cpp cc1plus: error: unrecognized command line option "-std=c++11" As stated in the install docs, you need a C++11 compiler, and the system GCC on OpenBSD probably doesn't recognise the -std=c++11 option. This is not a bug.
[Bug fortran/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308 --- Comment #2 from Thomas Koenig --- Created attachment 49319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49319=edit config.log from gmp subdirectory Here it is. For what it is worth, I now tried bootstrapping with CC=cc and CXX=c++, and things seem to be working (so far).
[Bug fortran/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308 --- Comment #1 from Andreas Schwab --- You need to attach the config.log file in `/home/tkoenig/trunk-bin/gmp'.
[Bug fortran/97308] New: OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308 Bug ID: 97308 Summary: OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Created attachment 49318 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49318=edit config.log from failed attempt On gcc302.fsffrance.org, with ../trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran,lto and invoked with "gmake" Last output: checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes checking how to run the C++ preprocessor... /lib/cpp configure: error: in `/home/tkoenig/trunk-bin/gmp': configure: error: C++ preprocessor "/lib/cpp" fails sanity check See `config.log' for more details gmake[2]: *** [Makefile:5484: configure-stage1-gmp] Error 1 gmake[2]: Leaving directory '/home/tkoenig/trunk-bin' gmake[1]: *** [Makefile:27002: stage1-bubble] Error 2 gmake[1]: Leaving directory '/home/tkoenig/trunk-bin' gmake: *** [Makefile:1004: all] Error 2
[Bug libstdc++/90295] Please define ~exception_ptr inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90295 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jonathan Wakely --- .
[Bug c/97307] New: Optimization for pure vs. const function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307
Bug ID: 97307
Summary: Optimization for pure vs. const function
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: benjamin.meier70 at gmail dot com
Target Milestone: ---
This bug report is based on this stackoverflow post:
https://stackoverflow.com/q/64034889/916672
The source code I use in this post, is also available here:
https://gcc.godbolt.org/z/dGvxnv
Given this C source code:
> int pure_f(int a, int b) __attribute__((pure));
>
> int const_f(int a, int b) __attribute__((const));
>
> int my_f(int a, int b) {
> int x = pure_f(a, b);
> if (a > 0) {
> return x;
> }
> return a;
> }
If this is compiled with gcc with -O3, I would expect that the evaluation of
pure_f(a, b) is moved into the if. But it is not done:
> my_f(int, int):
> pushr12
> mov r12d, edi
> callpure_f(int, int)
> testr12d, r12d
> cmovg r12d, eax
> mov eax, r12d
> pop r12
> ret
On the other side, if const_f is called instead of pure_f, it is moved into the
if:
> my_f(int, int):
> testedi, edi
> jg .L4
> mov eax, edi
> ret
> .L4:
> jmp const_f(int, int)
Why isn't this optimization applied for a pure function? From my understanding,
this should also be possible and it seems to be beneficial.
[Bug libstdc++/90295] Please define ~exception_ptr inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90295 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > This optimizes to nothing now. ... even at -O1.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #3 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
>
> --- Comment #2 from Martin Liška ---
> Created attachment 49314
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49314=edit
> Debug counter patch
>
> First bad debug counter value is -fdbg-cnt=ipa_mod_ref:2793.
> Difference is for: TriaObjectAccessor<3, 3>::operator++():
>
> LTO stores:
> Limits: 32 bases, 16 refs
> Base 0:struct TriaObjectAccessor (alias set 172)
> Ref 0:int (alias set 6)
> access: Parm 0
> access: Parm 0 param offset:0 offset:0 size:32 max_size:32
>
> LTO stores:
> Limits: 32 bases, 16 refs
> Base 0:struct TriaObjectAccessor (alias set 172)
> Ref 0:int (alias set 6)
> access: Parm 0 param offset:0 offset:32 size:32 max_size:32
> access: Parm 0 param offset:0 offset:0 size:32 max_size:32
Thanks a lot for trakcing it down. At the first glance, the summary
looks correct. I hope this is just another manifestation of the bug
about mem_ref offsets, but I will take a lok.
Pehraps it would be more useful to add debug counter to the place
disambiguation is done (where we dump ipa-modref: in tree-ssa-alias.
That way we would have both the summary and the access.
Honza
>
> template
> inline
> void
> TriaObjectAccessor<3,dim>::operator ++ ()
> {
> ++this->present_index;
>// is index still in the range of
>// the vector?
> while (this->present_index
> >=
>
> static_cast(this->tria->levels[this->present_level]->hexes.hexes.size()))
> {
>// no -> go one level up
> ++this->present_level;
> this->present_index = 0;
>// highest level reached?
> if (this->present_level >= static_cast(this->tria->levels.size()))
> {
>// return with past the end pointer
> this->present_level = this->present_index = -1;
> return;
> };
> };
> }
>
> hope it helps.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> You are on the CC list for the bug.
[Bug libstdc++/92356] Missed optimization of std::find looking for item in array of items [0..n]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92356
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2020-10-06
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely ---
Please provide source, not jus a link to another site, as stated at
https://gcc.gnu.org/bugs/
The testcase is:
#include
#include
constexpr static int validValues[] = { 0, 1, 2 };
bool isValidValueWithRawLoop(int value) {
for (int i = 0; i < std::size(validValues); ++i) {
if (validValues[i] == value) {
return true;
}
}
return false;
}
bool isValidValueWithRangeForLoop(int value)
{
for (int item : validValues) {
if (item == value) {
return true;
}
}
return false;
}
bool isValidValueWithFind(int value)
{
return std::find(std::begin(validValues), std::end(validValues), value) !=
std::end(validValues);
}
Clang with libc++ compiles to the same code for all three functions:
cmp edi, 3
setbal
ret
GCC compiles the first one similarly:
cmp edi, 2
setbe al
ret
but generates much worse code for the range-based for loop and std::find.
Clang with libstdc++ also generates poor code, suggesting it's not just a
compiler issue. Presumably the manual unrolling we do in std::__find_if hurts
the optimizer.
The range-based for case is definitely a separate bug and should be filed
separately against component=c++ or component=tree-optimization.
[Bug libstdc++/90295] Please define ~exception_ptr inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90295 --- Comment #5 from Rafael Avila de Espindola --- > Fixed for GCC 11, and not plausible to backport. Thank you so much! Looking forward to GCC 11.
[Bug other/91084] download_prerequisites fails on OpenBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084 --- Comment #9 from Thomas Koenig --- WORKSFORME on OpenBSD 6.7.
[Bug middle-end/90861] OpenACC 'declare' not cleaning up for VLAs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861 Thomas Schwinge changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Resolution|FIXED |--- Status|RESOLVED|REOPENED CC||burnus at gcc dot gnu.org --- Comment #8 from Thomas Schwinge --- Tom, thanks for resolving this! Just one more item: let's please also update 'c-c++-common/goacc/declare-pr90861.c' (current XFAIL) to match reality.
[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 |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Jonathan Wakely ---
(In reply to Mathias Stearn from comment #2)
> Example showing significant codegen at -O3 which should all optimize away:
>
> #include
> bool test() {
> std::exception_ptr p1;
> std::exception_ptr p2 (p1);
> p1 = p2;
> swap(p1, p2);
> return p1 == nullptr && nullptr == p2 && p1 == p2;
> }
This optimizes to nothing now.
Fixed for GCC 11, and not plausible to backport.
[Bug libstdc++/90295] Please define ~exception_ptr inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90295 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1352ea192513e9a45808b8034df62b9434c674a7 commit r11-3682-g1352ea192513e9a45808b8034df62b9434c674a7 Author: Jonathan Wakely Date: Tue Oct 6 16:55:06 2020 +0100 libstdc++: Inline std::exception_ptr members [PR 90295] This inlines most members of std::exception_ptr so that all operations on a null exception_ptr can be optimized away. This benefits code like std::future and coroutines where an exception_ptr object is present to cope with exceptional cases, but is usually not used and remains null. Since those functions were previously non-inline we have to continue to export them from the library, for objects that were compiled against the old headers and expect to find definitions in the library. In order to inline the copy constructor and destructor we need to export the _M_addref() and _M_release() members that increment/decrement the reference count when copying/destroying a non-null exception_ptr. The copy ctor and dtor check for null and don't call _M_addref and _M_release unless they need to. The checks for null pointers in _M_addref and _M_release are still needed because old code might call them without checking for null first. But we can use __builtin_expect to predict that they are usually called for the non-null case. libstdc++-v3/ChangeLog: PR libstdc++/90295 * config/abi/pre/gnu.ver (CXXABI_1.3.13): New symbol version. (exception_ptr::_M_addref(), exception_ptr::_M_release()): Export symbols. * libsupc++/eh_ptr.cc (exception_ptr::exception_ptr()): Remove out-of-line definition. (exception_ptr::exception_ptr(const exception_ptr&)): Likewise. (exception_ptr::~exception_ptr()): Likewise. (exception_ptr::operator=(const exception_ptr&)): Likewise. (exception_ptr::swap(exception_ptr&)): Likewise. (exception_ptr::_M_addref()): Add branch prediction. * libsupc++/exception_ptr.h (exception_ptr::operator bool): Add noexcept. [!_GLIBCXX_EH_PTR_COMPAT] (operator==, operator!=): Define inline as hidden friends. Remove declarations at namespace scope. (exception_ptr::exception_ptr()): Define inline. (exception_ptr::exception_ptr(const exception_ptr&)): Likewise. (exception_ptr::~exception_ptr()): Likewise. (exception_ptr::operator=(const exception_ptr&)): Likewise. (exception_ptr::swap(exception_ptr&)): Likewise. * testsuite/util/testsuite_abi.cc: Add CXXABI_1.3.13. * testsuite/18_support/exception_ptr/90295.cc: New test.
[Bug testsuite/81690] libgomp.c/{target-32,thread-limit-2}.c fail for nvptx: missing usleep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81690 --- Comment #9 from Tom de Vries --- (In reply to Tobias Burnus from comment #4) > The omp_is_initial_device() is only resolved at run time - hence, I think > the linker still wants to see "usleep". > Well, yes, but that could be fixed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82251
[Bug middle-end/90861] OpenACC 'declare' not cleaning up for VLAs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861 Tom de Vries changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |11.0 --- Comment #7 from Tom de Vries --- Patch committed, marking resolved-fixed.
[Bug middle-end/90861] OpenACC 'declare' not cleaning up for VLAs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861
--- Comment #6 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:3f2e15c2e66af9cca1dfe24ad7e9692f511ebd06
commit r11-3680-g3f2e15c2e66af9cca1dfe24ad7e9692f511ebd06
Author: Tom de Vries
Date: Tue Oct 6 13:07:25 2020 +0200
[openacc] Fix acc declare for VLAs
Consider test-case test.c, with VLA A:
...
int main (void) {
int N = 1000;
int A[N];
#pragma acc declare copy(A)
return 0;
}
...
compiled using:
...
$ gcc test.c -fopenacc -S -fdump-tree-all
...
At original, we have:
...
#pragma acc declare map(tofrom:A);
...
but at gimple, we have a map (to:A.1), but not a map (from:A.1):
...
int[0:D.2074] * A.1;
{
int A[0:D.2074] [value-expr: *A.1];
saved_stack.2 = __builtin_stack_save ();
try
{
A.1 = __builtin_alloca_with_align (D.2078, 32);
#pragma omp target oacc_declare map(to:(*A.1) [len: D.2076])
}
finally
{
__builtin_stack_restore (saved_stack.2);
}
}
...
This is caused by the following incompatibility. When storing the desired
from clause in oacc_declare_returns, we use 'A.1' as the key:
...
10898 oacc_declare_returns->put (decl, c);
(gdb) call debug_generic_expr (decl)
A.1
(gdb) call debug_generic_expr (c)
map(from:(*A.1))
...
but when looking it up, we use 'A' as the key:
...
(gdb)
1471 tree *c = oacc_declare_returns->get (t);
(gdb) call debug_generic_expr (t)
A
...
Fix this by extracing the 'A.1' lookup key from 'A' using the decl-expr.
In addition, unshare the looked up value, to fix avoid running into
an "incorrect sharing of tree nodes" error.
Using these two fixes, we get our desired:
...
finally
{
+#pragma omp target oacc_declare map(from:(*A.1))
__builtin_stack_restore (saved_stack.2);
}
...
Build on x86_64-linux with nvptx accelerator, tested libgomp.
gcc/ChangeLog:
2020-10-06 Tom de Vries
PR middle-end/90861
* gimplify.c (gimplify_bind_expr): Handle lookup in
oacc_declare_returns using key with decl-expr.
libgomp/ChangeLog:
2020-10-06 Tom de Vries
PR middle-end/90861
* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: Remove xfail.
[Bug c++/97306] local extern decls & contexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97306 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-10-06 Ever confirmed|0 |1
[Bug c++/97306] New: local extern decls & contexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97306
Bug ID: 97306
Summary: local extern decls & contexpr
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
constexpr int *Foo (){
extern int i;
return
}
int i;
static_assert( == Foo());
This should work
[Bug middle-end/90861] OpenACC 'declare' not cleaning up for VLAs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861 --- Comment #5 from Tom de Vries --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555606.html
[Bug fortran/94625] documentation of _gfortran_set_options does not match implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94625 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |minor Last reconfirmed||2020-10-06
[Bug fortran/97084] Openmp + Allocatable String Crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97084 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-10-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- Confirmed from at least GG7 up to GCC10. With GCC11 the ICE is during GIMPLE pass: omplower pr97084.f90:9:0: 9 | !$omp parallel default(shared) | internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:163
[Bug middle-end/94527] RFE: Add an __attribute__ that marks a function as freeing an object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #9 from David Malcolm --- I hadn't seen this bug, but I've just posted: "[PATCH] RFC: add "deallocated_by" attribute for use by analyzer" https://gcc.gnu.org/pipermail/gcc-patches/2020-October/44.html which does some of the things requested in this RFE, but purely within -fanalyzer. -fanalyzer is read-only w.r.t. GCC's internal representation, i.e. it doesn't affect optimizations such as DSE. Though I suppose the same attribute could also be handled by optimization passes. That patch has some big limitations, as I noted. I attempted to use this to mark up: extern struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags); extern void usb_free_urb(struct urb *urb); as an acquire/release pair via: #define __deallocated_by(f) __attribute__((deallocated_by(f))); extern struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags) __deallocated_by(usb_free_urb); in order to detect CVE-2019-19078, a leak of struct urb in an error-handling path in linux <= 5.3.11 in drivers/net/wireless/ath/ath10k/usb.c, but I ran into issues where, without LTO, the analyzer knows nothing about calls to: usb_fill_bulk_urb usb_anchor_urb usb_unanchor_urb that occur along that path, and so it conservatively assumes it doesn't leak. (Caveat: I know nothing about those calls either; I'm a user-space developer with little knowledge of linux internals). I can get -fanalyzer to emit a leak warning on that code path with that patch if I hack out those calls. [To set expectations: I should mention that my initial implementation of -fanalyzer in gcc 10 had some major design flaws that mean it couldn't scale; I've fixed those flaws for gcc 11, and am working hard on scaling it up to be usable on real-world C when gcc 11 ships, but I don't feel it's there yet. In particular, I don't expect the current version in git to be usable with LTO other than on toy examples without some more fixes. The -fanalyzer option has found some bugs, including at least one CVE, but I don't recommend it yet other than to adventurous early adopters. As I said, I hope to have it in much better shape when GCC 11 actually ships in about 6 months time]
[Bug bootstrap/97305] options-save.c:8526:26: error: unused variable 'mask'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97305 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |11.0 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Component|other |bootstrap Last reconfirmed||2020-10-06
[Bug other/97305] New: options-save.c:8526:26: error: unused variable 'mask'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97305
Bug ID: 97305
Summary: options-save.c:8526:26: error: unused variable 'mask'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Host: hppa*-*-*
Target: hppa*-*-*
Build: hppa*-*-*
options-save.c: In function 'void cl_target_option_save(cl_target_option*,
gcc_o
ptions*, gcc_options*)':
options-save.c:8526:26: error: unused variable 'mask' [-Werror=unused-variable]
8526 | unsigned HOST_WIDE_INT mask = 0;
| ^~~~
options-save.c: In function 'void cl_target_option_restore(gcc_options*,
gcc_opt
ions*, cl_target_option*)':
options-save.c:8537:26: error: unused variable 'mask' [-Werror=unused-variable]
8537 | unsigned HOST_WIDE_INT mask;
| ^~~~
/* Save selected option variables into a structure. */
void
cl_target_option_save (struct cl_target_option *ptr, struct gcc_options *opts,
struct gcc_options *opts_set)
{
if (targetm.target_option.save)
targetm.target_option.save (ptr, opts, opts_set);
ptr->x_target_flags = opts->x_target_flags;
unsigned HOST_WIDE_INT mask = 0;
ptr->explicit_mask_target_flags = opts_set->x_target_flags;
}
[Bug tree-optimization/97236] [10 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/97043] latent wrong-code with SLP vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97043 Bug 97043 depends on bug 97236, which changed state. Bug 97236 Summary: [10 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/90861] OpenACC 'declare' not cleaning up for VLAs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861 Tom de Vries changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #4 from Tom de Vries --- Created attachment 49317 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49317=edit Tentative patch
[Bug target/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 Thomas Koenig changed: What|Removed |Added Component|bootstrap |target --- Comment #3 from Thomas Koenig --- Again, the files are on gcc303.fsffrance.org in /home/tkoenig .
[Bug tree-optimization/97236] [10 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Matthias Klose : https://gcc.gnu.org/g:1ab88985631dd2c5a5e3b5c0dce47cf8b6ed2f82 commit r10-8859-g1ab88985631dd2c5a5e3b5c0dce47cf8b6ed2f82 Author: Matthias Klose Date: Tue Oct 6 13:41:37 2020 +0200 Backport fix for PR/tree-optimization/97236 - fix bad use of VMAT_CONTIGUOUS This avoids using VMAT_CONTIGUOUS with single-element interleaving when using V1mode vectors. Instead keep VMAT_ELEMENTWISE but continue to avoid load-lanes and gathers. 2020-10-01 Richard Biener PR tree-optimization/97236 * tree-vect-stmts.c (get_group_load_store_type): Keep VMAT_ELEMENTWISE for single-element vectors. * gcc.dg/vect/pr97236.c: New testcase.
[Bug c++/31775] static object mangling conflicts with extern object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775 Nathan Sidwell changed: What|Removed |Added Status|RESOLVED|ASSIGNED CC||nathan at gcc dot gnu.org Assignee|geoffk at gcc dot gnu.org |nathan at gcc dot gnu.org Resolution|FIXED |--- --- Comment #10 from Nathan Sidwell --- the resolution of this report is incorrect.
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 --- Comment #6 from Eric Botcazou --- > Is there any workaround for this issue? Some gcc switch to disable the new > optimization which came in GCC 10? The optimization (-fdelayed-branch) has been there for years though and you can always pass the associated -fno-xxx switch.
[Bug rtl-optimization/97295] ICE on firefox built with lto+pgo: dist/include/mozilla/Casting.h:64:1: internal compiler error: in to_frequency, at profile-count.c:273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97295 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-10-06 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Thank you for the report. I can reproduce it but it would be handy to provide a pre-processed source files (-E option) for the 2 objects.
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 Petr Sumbera changed: What|Removed |Added CC||sumbera at volny dot cz --- Comment #5 from Petr Sumbera --- Is there any workaround for this issue? Some gcc switch to disable the new optimization which came in GCC 10? Thanks!
[Bug sanitizer/97294] ASAN "dynamic-stack-buffer-overflow" false positive with OpenMP reduction to std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97294 Martin Liška changed: What|Removed |Added Keywords||openmp Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-06 --- Comment #1 from Martin Liška --- Confirmed, it used to work with GCC 7. I bet it's related to a change in vector class. @Jakub: Will you take a look please?
[Bug target/95864] [11 Regression] GCN offloading execution regressions after commit f062c3f11505b70c5275e5bc0e52f3e441f8afbc "amdgcn: Switch to HSACO v3 binary format"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95864 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|ams at gcc dot gnu.org |jules at gcc dot gnu.org --- Comment #2 from Thomas Schwinge --- This apparently got fixed by Julian's commit r11-3057-g3aee3aaf48be2d3d81e381690ae9dd305d8b505f "openacc: Fix mkoffload SGPR/VGPR count parsing for HSACO v3".
[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 --- Comment #2 from Thomas Koenig --- Created attachment 49316 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49316=edit output from compilation that failed with -lc
[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 --- Comment #1 from Thomas Koenig --- Created attachment 49315 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49315=edit config.log from failed attempt
[Bug bootstrap/97304] New: Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 Bug ID: 97304 Summary: Boostrap failure on freebsd: ld: error: unable to find library -lc Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- With PR 97302 out of the way (fixed by Tobias' patch in that PR), compilation now fails with ld: error: unable to find library -lc
[Bug target/97302] FreeBSD build fails with contrib/download_prerequisites with missing gmp.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Tobias Burnus --- FIXED on mainline/GCC 11 + GCC 10 + GCC 9. Thanks for the report!
[Bug target/97302] FreeBSD build fails with contrib/download_prerequisites with missing gmp.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:96b32c86f507f5391512a9cb5ec536e604472ea2 commit r9-8977-g96b32c86f507f5391512a9cb5ec536e604472ea2 Author: Tobias Burnus Date: Tue Oct 6 11:49:34 2020 +0200 configure: Fix in-tree building of GMP on BSD [PR97302] ChangeLog: PR target/97302 * configure.ac: Only set with_gmp to /usr/local if not building in tree. * configure: Regenerate. (cherry picked from commit c0d0a722da8583f74a0c192041be2f379cf487c1)
[Bug target/97302] FreeBSD build fails with contrib/download_prerequisites with missing gmp.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:7cacf5a576675109f3b081cbd436d1fbadad776d commit r10-8858-g7cacf5a576675109f3b081cbd436d1fbadad776d Author: Tobias Burnus Date: Tue Oct 6 11:49:34 2020 +0200 configure: Fix in-tree building of GMP on BSD [PR97302] ChangeLog: PR target/97302 * configure.ac: Only set with_gmp to /usr/local if not building in tree. * configure: Regenerate. (cherry picked from commit c0d0a722da8583f74a0c192041be2f379cf487c1)
[Bug target/97302] FreeBSD build fails with contrib/download_prerequisites with missing gmp.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302 --- Comment #4 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c0d0a722da8583f74a0c192041be2f379cf487c1 commit r11-3675-gc0d0a722da8583f74a0c192041be2f379cf487c1 Author: Tobias Burnus Date: Tue Oct 6 11:49:34 2020 +0200 configure: Fix in-tree building of GMP on BSD [PR97302] ChangeLog: PR target/97302 * configure.ac: Only set with_gmp to /usr/local if not building in tree. * configure: Regenerate.
[Bug ipa/97301] [11 regression] gcc.target/powerpc/sse-movlps-1.c fails after r11-3434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97301 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Component|other |ipa CC||marxin at gcc dot gnu.org
[Bug ipa/97300] [11 regression] several test cases fail after r11-3308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97300 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |11.0
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Component|other |testsuite Ever confirmed|0 |1 Last reconfirmed||2020-10-06 Target Milestone|--- |11.0 --- Comment #1 from Richard Biener --- I will have a look.
[Bug rtl-optimization/97282] division done twice for modulo and divsion for 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bf510679bb3f9bfd6019666065016bb26a5b5466
commit r11-3671-gbf510679bb3f9bfd6019666065016bb26a5b5466
Author: Jakub Jelinek
Date: Tue Oct 6 10:32:22 2020 +0200
divmod: Match and expand DIVMOD even in some cases of constant divisor
[PR97282]
As written in the comment, tree-ssa-math-opts.c wouldn't create a DIVMOD
ifn call for division + modulo by constant for the fear that during
expansion we could generate better code for those cases.
If the divisoris a power of two, that is certainly the case always,
but otherwise expand_divmod can punt in many cases, e.g. if the division
type's precision is above HOST_BITS_PER_WIDE_INT, we don't even call
choose_multiplier, because it works on HOST_WIDE_INTs (true, something
we should fix eventually now that we have wide_ints), or if pre/post shift
is larger than BITS_PER_WORD.
So, the following patch recognizes DIVMOD with constant last argument even
when it is unclear if expand_divmod will be able to optimize it, and then
during DIVMOD expansion if the divisor is constant attempts to expand it as
division + modulo and if they actually don't contain any libcalls or
division/modulo, they are kept as is, otherwise that sequence is thrown
away
and divmod optab or libcall is used.
2020-10-06 Jakub Jelinek
PR rtl-optimization/97282
* tree-ssa-math-opts.c (divmod_candidate_p): Don't return false for
constant op2 if it is not a power of two and the type has precision
larger than HOST_BITS_PER_WIDE_INT or BITS_PER_WORD.
* internal-fn.c (contains_call_div_mod): New function.
(expand_DIVMOD): If last argument is a constant, try to expand it
as
TRUNC_DIV_EXPR followed by TRUNC_MOD_EXPR, but if the sequence
contains any calls or {,U}{DIV,MOD} rtxes, throw it away and use
divmod optab or divmod libfunc.
* gcc.target/i386/pr97282.c: New test.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #2 from Martin Liška ---
Created attachment 49314
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49314=edit
Debug counter patch
First bad debug counter value is -fdbg-cnt=ipa_mod_ref:2793.
Difference is for: TriaObjectAccessor<3, 3>::operator++():
LTO stores:
Limits: 32 bases, 16 refs
Base 0:struct TriaObjectAccessor (alias set 172)
Ref 0:int (alias set 6)
access: Parm 0
access: Parm 0 param offset:0 offset:0 size:32 max_size:32
LTO stores:
Limits: 32 bases, 16 refs
Base 0:struct TriaObjectAccessor (alias set 172)
Ref 0:int (alias set 6)
access: Parm 0 param offset:0 offset:32 size:32 max_size:32
access: Parm 0 param offset:0 offset:0 size:32 max_size:32
template
inline
void
TriaObjectAccessor<3,dim>::operator ++ ()
{
++this->present_index;
// is index still in the range of
// the vector?
while (this->present_index
>=
static_cast(this->tria->levels[this->present_level]->hexes.hexes.size()))
{
// no -> go one level up
++this->present_level;
this->present_index = 0;
// highest level reached?
if (this->present_level >= static_cast(this->tria->levels.size()))
{
// return with past the end pointer
this->present_level = this->present_index = -1;
return;
};
};
}
hope it helps.
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 --- Comment #6 from Christophe Lyon --- Thanks for the confirmation, I've just sent a patch to remove them: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/71.html
[Bug tree-optimization/97159] [11 Regression] segfault in modref_may_conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97159 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tom de Vries --- Marking resolved-fixed.
[Bug target/97302] FreeBSD build fails with contrib/download_prerequisites with missing gmp.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302 --- Comment #3 from Thomas Koenig --- Comment on attachment 49313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49313 configure.ac patch Seems to work, at least the compilation is proceeding now. Thanks for the quick fix!
[Bug tree-optimization/97008] [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97008 --- Comment #5 from Tom de Vries --- The openacc machinery is the only user of IFN_UNIQUE. Thomas, as openacc maintainer, is this change ok for you, or are reasons why you want to keep the IFN_UNIQUE as last stmt of the BB?
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P1 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Blocks||26163 Known to fail||11.0 Host||x86_64-linux-gnu Last reconfirmed||2020-10-06 Target Milestone|--- |11.0 Known to work||10.2.0 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Martin Liška --- Confirmed also on x86_64-linux-gnu. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug middle-end/97289] [11 Regression] ICE in get, at cgraph.h:446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97289 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:44e20dce597328f3cb00e997fa90b95a2b710d4c commit r11-3669-g44e20dce597328f3cb00e997fa90b95a2b710d4c Author: Jakub Jelinek Date: Tue Oct 6 09:25:00 2020 +0200 openmp: Fix ICE in omp_discover_declare_target_tgt_fn_r This ICEs because node->alias_target is (not yet) a FUNCTION_DECL, but IDENTIFIER_NODE. I guess we should retry the discovery before LTO streaming out, the reason to do it this early is that it can affect the gimplification and omp lowering. 2020-10-06 Jakub Jelinek PR middle-end/97289 * omp-offload.c (omp_discover_declare_target_tgt_fn_r): Only follow node->alias_target if it is a FUNCTION_DECL. * c-c++-common/gomp/pr97289.c: New test.
[Bug target/97302] FreeBSD build fails with contrib/download_prerequisites with missing gmp.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
Created attachment 49313
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49313=edit
configure.ac patch
I think there is an ordering problem in the top configure.ac:
*-*-freebsd*)
if test "x$with_gmp" = x && test "x$with_gmp_dir" = x \
&& test -f /usr/local/include/gmp.h; then
with_gmp=/usr/local
fi
;;
and later:
if test "x$with_gmp$with_gmp_include$with_gmp_lib" = x && test -d
${srcdir}/gmp; then
Thus, the in-tree-build check fails if with_gmp is set.
Can you try the attached patch? I currently do not have a BSD system at hand.
[Bug c++/97303] New: ICE during GIMPLE pass: *rebuild_cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97303
Bug ID: 97303
Summary: ICE during GIMPLE pass: *rebuild_cgraph_edges
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thekbrogamer at gmail dot com
Target Milestone: ---
Created attachment 49312
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49312=edit
code causing ice
On mingw32-g++ (MinGW.org Cross-GCC Build-20200531-1) 9.2.0 cross compiler when
compiling the following snippet
#include
#include
class test0
{
public:
virtual ~test0() {}
};
template
class test1 : public test0
{
public:
virtual bool doAnything() const = 0;
};
class test3_internal
{
public:
bool depart() { return true; }
};
template
class test3
{
public:
typedef T element_type;
explicit test3(T* ptr = NULL) {}
~test3() { depart(); }
void reset(T* ptr = NULL) { depart(); }
private:
void depart()
{
if (link_.depart())
delete value_;
}
T* value_;
test3_internal link_;
};
int main()
{
using doesNotCompile = long unsigned int(__attribute__((stdcall))*)(void*);
using type2 = test1;
// using compiles = long unsigned int(*)(void*);
// using type2 = test1;
test3 test;
test.reset();
return 0;
}
$ mingw32-g++ -S -masm=intel foo.cpp
during GIMPLE pass: *rebuild_cgraph_edges
foo.cpp: In member function 'void test3::depart() [with T = const test1]':
foo.cpp:55:1: internal compiler error: Segmentation fault
55 | }
| ^
0xbc5ecf crash_signal
../../src/gcc-9.2.0/gcc/toplev.c:326
0x9f077b obj_type_ref_class(tree_node const*)
../../src/gcc-9.2.0/gcc/ipa-devirt.c:2026
0xe10556 virtual_method_call_p(tree_node const*)
../../src/gcc-9.2.0/gcc/tree.c:13009
0x8489d1 cgraph_node::create_indirect_edge(gcall*, int, profile_count, bool)
../../src/gcc-9.2.0/gcc/cgraph.c:968
0x84dd1a cgraph_edge::rebuild_edges()
../../src/gcc-9.2.0/gcc/cgraphbuild.c:421
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/96456] [10/11 Regression] ICE in expand_insn, at optabs.c:7511 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96456 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Andreas Krebbel : https://gcc.gnu.org/g:537f9f4e5b12f4ef5ca363f89466c0470f3482bf commit r10-8856-g537f9f4e5b12f4ef5ca363f89466c0470f3482bf Author: Andreas Krebbel Date: Wed Aug 12 08:02:34 2020 +0200 IBM Z: Fix PR96456 The testcase failed because our backend refuses to generate vector compare instructions for signaling operators with -fno-trapping-math -fno-finite-math-only. gcc/ChangeLog: PR target/96456 * config/s390/s390.h (TARGET_NONSIGNALING_VECTOR_COMPARE_OK): New macro. * config/s390/vector.md (vcond_comparison_operator): Use new macro for the check. gcc/testsuite/ChangeLog: PR target/96456 * gcc.target/s390/pr96456.c: New test. (cherry picked from commit 1d17c38ac1d1d916abbce14e6b2e0d61517c6e9b)
[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47469 --- Comment #9 from Paul Thomas --- Tobias's original suggestion is certainly more concise, although equivalent to the present code. I will commit the change today or tomorrow as obvious. It happens that I am working on trans-expr.c at the moment and so will have to reset my tree to deal with this. Regards Paul
