[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target||powerpc* --- Comment #2 from Richard Biener --- Likely the builtins are wrongly declared const or pure. novops, leaf, nothrow would be the correct choice here.
[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478 Richard Biener changed: What|Removed |Added Keywords||lto, needs-bisection CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Is this a new failure, thus can it be bisected somehow?
[Bug c++/91477] error messages do not show column numbers for large source files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91477 --- Comment #1 from Richard Biener --- This is due to limitations in the encoding space for locations which causes us to drop column numbers at some point.
[Bug c++/91476] [9/10 Regression] const reference variables sharing the same name in two anonymous namespaces cause a multiple definition error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91476 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||8.3.0 Keywords||ABI, link-failure, ||needs-bisection, wrong-code Last reconfirmed||2019-08-19 Ever confirmed|0 |1 Summary|const reference variables |[9/10 Regression] const |sharing the same name in|reference variables sharing |two anonymous namespaces|the same name in two |cause a multiple definition |anonymous namespaces cause |error |a multiple definition error Target Milestone|--- |9.3 Known to fail||9.1.0 --- Comment #1 from Richard Biener --- Confirmed.
[Bug target/91472] [8/9/10 Regression] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |8.4 Summary|gmp testsuite segfaults |[8/9/10 Regression] gmp |with gcc-8 and gcc-9, works |testsuite segfaults with |fine with gcc-7 |gcc-8 and gcc-9, works fine ||with gcc-7
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #1 from Thomas Koenig --- See also https://xkcd.com/221/
[Bug target/91441] ICE in asan_shadow_offset at asan.c:342 on riscv64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91441 kito at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kito at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from kito at gcc dot gnu.org --- Fixed
[Bug fortran/91485] [10 Regression] Erroneous conflict between variable x and operator(.x.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91485 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from kargl at gcc dot gnu.org --- Really close.
[Bug fortran/91485] [10 Regression] Erroneous conflict between variable x and operator(.x.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91485 kargl at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.3 --- Comment #3 from kargl at gcc dot gnu.org --- Fixed.
[Bug target/91441] ICE in asan_shadow_offset at asan.c:342 on riscv64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91441 --- Comment #2 from kito at gcc dot gnu.org --- Author: kito Date: Mon Aug 19 03:21:44 2019 New Revision: 274631 URL: https://gcc.gnu.org/viewcvs?rev=274631&root=gcc&view=rev Log: PR target/91441 - Turn off -fsanitize=kernel-address if TARGET_ASAN_SHADOW_OFFSET is not implemented. - -fsanitize=kernel-address will call targetm.asan_shadow_offset () at asan_shadow_offset, so it will crash if TARGET_ASAN_SHADOW_OFFSET is not implemented, that's mean -fsanitize=kernel-address is not supported for target without TARGET_ASAN_SHADOW_OFFSET implementation. gcc/ChangeLog: PR target/91441 * toplev.c (process_options): Check TARGET_ASAN_SHADOW_OFFSET is implemented for -fsanitize=kernel-address, and merge check logic with -fsanitize=address. testsuite/ChangeLog: PR target/91441 * gcc.target/riscv/pr91441.c: New. Added: trunk/gcc/testsuite/gcc.target/riscv/pr91441.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c
[Bug fortran/91485] [10 Regression] Erroneous conflict between variable x and operator(.x.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91485 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Aug 19 03:21:46 2019 New Revision: 274632 URL: https://gcc.gnu.org/viewcvs?rev=274632&root=gcc&view=rev Log: 2019-08-18 Steven G. Kargl PR fortran/91485 module.c (gfc_match_use): User defined operator cannot conflict with a rename symbol. 2019-08-18 Steven G. Kargl PR fortran/91485 * gfortran.dg/pr91485.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91485.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/module.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/91485] [10 Regression] Erroneous conflict between variable x and operator(.x.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91485 --- Comment #1 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Aug 19 03:00:54 2019 New Revision: 274630 URL: https://gcc.gnu.org/viewcvs?rev=274630&root=gcc&view=rev Log: 2019-08-18 Steven G. Kargl PR fortran/91485 module.c (gfc_match_use): User defined operator cannot conflict with a rename symbol. 2019-08-18 Steven G. Kargl PR fortran/91485 * gfortran.dg/pr91485.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr91485.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/91488] New: [9/10 Regression] char_traits::length causes "inlining failed in call to always_inline" error with -fgnu-tm -O2 -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91488
Bug ID: 91488
Summary: [9/10 Regression] char_traits::length causes "inlining
failed in call to always_inline" error with -fgnu-tm
-O2 -std=c++17
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Repro (https://gcc.godbolt.org/z/RO-2Ec):
#include
int main() {
auto z = std::char_traits::length("");
}
$ g++ -fgnu-tm -O2 -std=c++17
In file included from
/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/string:40,
from :1:
/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:
In static member function 'static constexpr std::size_t
std::char_traits::length(const char_type*)':
/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:231:5:
error: inlining failed in call to 'always_inline' 'constexpr bool
std::__constant_string_p(const _CharT*) [with _CharT = char]':
231 | __constant_string_p(const _CharT* __s)
| ^~~~~~~
/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:332:25:
note: called from here
332 | if (__constant_string_p(__s))
| ~~~^
/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:231:5:
error: inlining failed in call to 'always_inline' 'constexpr bool
std::__constant_string_p(const _CharT*) [with _CharT = char]':
231 | __constant_string_p(const _CharT* __s)
| ^~~
/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:332:25:
note: called from here
332 | if (__constant_string_p(__s))
| ~~~^
[Bug target/80834] PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80834 Li Jia He changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Li Jia He --- This issue has been resolved on the trunk.
[Bug target/80834] PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80834
Li Jia He changed:
What|Removed |Added
CC||helijia at gcc dot gnu.org
--- Comment #4 from Li Jia He ---
This question may not be as complicated as described. May only have a more
important relationship with the setting of the vect-cost-model value
(rs6000_builtin_vectorization_cost). And it has been vectorized on the current
trunk(subversion id 274560).
If we use the code that mike said(subversion id 248266), and compile option is
```
-mcpu=power9 -O3 -ffast-math -fdump-tree-vect-details-all
-fdump-tree-slp-details-all
```
We can see the following analysis of vect-cost-model
```
m_amatvec.c:114:5: note: density 96%, cost 87 exceeds threshold, penalizing
loop body cost by 10%m_amatvec.c:114:5: note: Cost model analysis:
Vector inside of loop cost: 92
Vector prologue cost: 5
Vector epilogue cost: 36
Scalar iteration cost: 36
Scalar outside cost: 1
Vector outside cost: 41
prologue iterations: 0
epilogue iterations: 1
m_amatvec.c:114:5: note: cost model: the vector iteration cost = 92 divided by
the scalar iteration cost = 36 is greater or equal to the vectorization factor
= 2.
m_amatvec.c:114:5: note: not vectorized: vectorization not profitable.
m_amatvec.c:114:5: note: not vectorized: vector version will never be
profitable.
```
We can see that the value of ‘Vector inside of loop cost’ is 92, however (92 /
36 = 2) >= 2, which causes vect-cost-model to think that vector version will
never be profitable.
If we use the current trunk code(subversion id 274560), and compile option is
```
-mcpu=power9 -O3 -ffast-math -fdump-tree-vect-details-all
-fdump-tree-slp-details-all
```
We can see the following analysis of vect-cost-model
```
m_amatvec.c:114:5: note: Cost model analysis:
Vector inside of loop cost: 60
Vector prologue cost: 5
Vector epilogue cost: 36
Scalar iteration cost: 36
Scalar outside cost: 1
Vector outside cost: 41
prologue iterations: 0
epilogue iterations: 1
Calculated minimum iters for profitability: 2
m_amatvec.c:114:5: note:Runtime profitability threshold = 2
m_amatvec.c:114:5: note:Static estimate profitability threshold = 2
```
At this point, we can see that the value of 'Vector inside of loop cost' is 60.
At this time (60 / 36 = 1) < 2, we think that vectorization can be profitable
at this time.
‘Vector inside of loop cost’ value change consists of 2 parts
(1) The value of unaligned_store is reduced by ((3-1)*12)=24.
(2) rs6000_density_test value is reduced by 8.
The change in the unaligned_store partial value fixed by the following patch.
```
commit 01cabe21e4ecae1e9c53fe12d7c0aa654143a3d2
Author: pthaugen
Date: Fri Oct 13 16:05:53 2017 +
* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost):
Remove
TARGET_P9_VECTOR code for unaligned_load case.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@253731
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fefac6e0c95..00be94fe349 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2017-10-13 Pat Haugen
+
+ * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Remove
+ TARGET_P9_VECTOR code for unaligned_load case.
+
2017-10-13 Jan Hubicka
* cfghooks.c (verify_flow_info): Check that edge probabilities are
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index e6e254ac041..b08cd316e68 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -5419,9 +5419,6 @@ rs6000_builtin_vectorization_cost (enum
vect_cost_for_stmt type_of_cost,
return 3;
case unaligned_load:
- if (TARGET_P9_VECTOR)
- return 3;
-
if (TARGET_EFFICIENT_UNALIGNED_VSX)
return 1;
```
The analysis of the changes in the rs6000_density_test part of the data is as
follows:
As the code below, the density penalty fixup **depends on** the vec_cost.
```
if (density_pct > DENSITY_PCT_THRESHOLD
&& vec_cost + not_vec_cost > DENSITY_SIZE_THRESHOLD)
{
data->cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
"density %d%%, cost %d exceeds threshold, penalizing "
"loop body cost by %d%%", density_pct,
vec_cost + not_vec_cost, DENSITY_PENALTY);
}
```
With the commit 253731, the vec_cost is reduced by 24 as you mentioned, the
`vec_cost + not_vec_cost` is less than DENSITY_SIZE_THRESHOLD, so it's fine.
(btw, not_vec_cost can be calculated as 3 from the previous dump.)
By the way, if we use this option -fvect-cost-model=unlimited, with the
‘unlimited’ model the vectorized code-path is assumed to be profitable while
with the ‘dynamic’ model a runt
[Bug c++/91487] New: [concepts] alias constraint not respected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91487
Bug ID: 91487
Summary: [concepts] alias constraint not respected
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frederik.engels24 at gmail dot com
Target Milestone: ---
The following should fail to compile since it doesn't pass the only_int
constraint.
https://godbolt.org/z/HrB1wz (gcc version 10.0.0 20190817)
#include
template
requires std::is_same_v
using only_int = T;
template
using forward = only_int;
int main()
{
forward f;
}
[Bug fortran/91485] [10 Regression] Erroneous conflict between variable x and operator(.x.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91485 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||kargl at gcc dot gnu.org Severity|normal |enhancement
[Bug libstdc++/91486] future::wait_for and shared_timed_mutex::wait_for do not work properly with float duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486 --- Comment #2 from John Salmon --- The same incorrect logic that was fixed in bug 68519 is present in the implementations of future::wait_for and shared_timed_mutex::wait_for. The fix should be the same: explicitly duration_cast the __rtime argument to __clock::duration before adding to __clock::now(). Fixes are required in shared_mutex and bits/atomic_futex.h. The attached code demonstrates the problem. wait_for either waits too long or too short. Output is: drdws0134$ garden with -m gcc/8.1.0-01c7/bin g++ -std=c++14 futurewait.cpp -pthread && ./a.out ERROR - future::wait_for took too short: t1 looping: 0 milliseconds 0 second t2 looping: 0 second ERROR - shared_timed_mutex::try_lock_shared took too short: 0 milliseconds t2 looping: 1 second t1 looping: 1 second t2 looping: 2 second t1 looping: 2 second t2 looping: 3 second t1 looping: 3 second t2 looping: 4 second t1 looping: 4 second
[Bug libstdc++/91486] future::wait_for and shared_timed_mutex::wait_for do not work properly with float duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486 --- Comment #1 from John Salmon --- Created attachment 46727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46727&action=edit demonstration code
[Bug libstdc++/91486] New: future::wait_for and shared_timed_mutex::wait_for do not work properly with float duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486 Bug ID: 91486 Summary: future::wait_for and shared_timed_mutex::wait_for do not work properly with float duration Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: john.salmon at deshaw dot com Target Milestone: ---
[Bug fortran/91390] treatment of extra parameter in a subroutine call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390 --- Comment #6 from Thomas Koenig --- Created attachment 46726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46726&action=edit Much better patch It a) does not try to do two things at once, and b) has passed regression-testing at least once.
[Bug fortran/91485] New: [10 Regression] Erroneous conflict between variable x and operator(.x.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91485 Bug ID: 91485 Summary: [10 Regression] Erroneous conflict between variable x and operator(.x.) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- Created attachment 46725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46725&action=edit Minimal reproducer The attached valid code suddenly fails with current 10-trunk: gfcbug155.f90:23:26: 23 | subroutine print_prod (x, y) | 1 24 | use foo, only: cartesian, operator(.x.) | 2 Error: Symbol 'x' at (1) conflicts with the symbol at (2) gfcbug155.f90:26:19: 26 | type(cartesian), intent(in) :: x, y | 1 Error: Derived type 'cartesian' at (1) is being used before it is defined gfcbug155.f90:23:26: 23 | subroutine print_prod (x, y) | 1 Error: Symbol 'x' at (1) has no IMPLICIT type gfcbug155.f90:23:29: 23 | subroutine print_prod (x, y) | 1 Error: Symbol 'y' at (1) has no IMPLICIT type The regression is most likely introduced in the last 2 days. Note that it is important that the USE statement is placed in the contained subroutine, not at module level.
[Bug sanitizer/87880] [9 regression] All macOS asan execution tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87880 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Iain Sandoe --- fixed for 9.3
[Bug sanitizer/87880] [9 regression] All macOS asan execution tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87880 --- Comment #15 from Iain Sandoe --- Author: iains Date: Sun Aug 18 19:11:29 2019 New Revision: 274625 URL: https://gcc.gnu.org/viewcvs?rev=274625&root=gcc&view=rev Log: Darwin, libsanitizer - remove reference to __cxa_rethrow_primary_exception. For some Darwin versions the absence of the rethrow_primary_exception symbol causes almost all sanitizer tests to fail. The symbol is not present in libstdc++ and, therefore is is correct to remove the reference to it for all platforms. We do this by adding a new guard "ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION". For the backported version, to avoid bumping the library version, this is only applied for Darwin (because of the way that symbol interposing works on Darwin, this does not alter the exported symbols list). libsanitizer/ 2019-08-18 Iain Sandoe Backport from mainline 2019-06-18 Iain Sandoe PR libsanitizer/87880 * asan/asan_interceptors.h: (ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION): New. * asan/Makefile.am (DEFS): Add (for Darwin only) ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION, defined to 0. * asan/Makefile.in: Regenerated. Modified: branches/gcc-9-branch/libsanitizer/ChangeLog branches/gcc-9-branch/libsanitizer/asan/Makefile.am branches/gcc-9-branch/libsanitizer/asan/Makefile.in branches/gcc-9-branch/libsanitizer/asan/asan_interceptors.h
[Bug target/83531] Build broken on macOS 10.13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |7.5 --- Comment #12 from Iain Sandoe --- so fixed for trunk so far.
[Bug target/83531] Build broken on macOS 10.13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531 --- Comment #11 from Iain Sandoe --- Author: iains Date: Sun Aug 18 18:54:13 2019 New Revision: 274624 URL: https://gcc.gnu.org/viewcvs?rev=274624&root=gcc&view=rev Log: [Darwin, fixincludes] Fix PR83531 There is no reasonable chance that the SDKs in question will be re- issued, so the only viable solution is a fixincludes. 2019-08-18 C.G. Dogan Iain Sandoe PR target/83531 * inclhack.def (darwin_api_availability): New, strip leading underscores from API_ defines. * fixincl.x: Regenerate. * tests/base/os/availability.h: New file. Added: trunk/fixincludes/tests/base/os/availability.h Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def
[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Eric Botcazou --- OK, I can reproduce, thanks.
[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #4 from Mikael Pettersson --- I can reproduce the SEGV with the gmp-6.1.2 release tarball and gcc-8.3 on sparc64-linux, making either a 32-bit or a 64-bit build of gmp, using gmp's defaults (not overriding CC or CFLAGS).
[Bug lto/64636] Bootstrapping gcc-4.9.2 fails if lto is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 --- Comment #5 from John Paul Adrian Glaubitz --- I can confirm that disabling LTO on sparc64 makes gcc build fine.
[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 --- Comment #3 from John Paul Adrian Glaubitz --- It can reproduced by simply cloning the gmp repo, building it and running the testsuite: $ hg clone https://gmplib.org/repo/gmp $ cd gmp $ ./.bootstrap && ./configure --enable-cxx --enable-fat --build sparc64-linux-gnu && make -j32 && make check Switching gcc versions can be achieved by just setting the CC variable, e.g.: $ export CC=gcc-8
[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-08-18 Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- We need a reproducer (or at least instructions to reproduce).
[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91480 --- Comment #2 from frankhb1989 at gmail dot com --- I agree the problem of 'L' is not likely found as a real issue in practice. Perhaps this could be forwarded as an issue of the standard which requires overspecified definitions. I don't find any intentional use cases about relying on the exactly specified type. (Despite the range limitation of int, the macro expansion results can be specified as "integer literal equal to the corresponding numerical values specified in the table" and a note about intentionally unspecified types.)
[Bug c++/91484] New: Error message: std::is_constructible with incomplete types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91484 Bug ID: 91484 Summary: Error message: std::is_constructible with incomplete types. Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: asschool at yandex dot ru Target Milestone: --- https://godbolt.org/z/BGkt7T https://godbolt.org/z/EyDV9s GCC correctly(i suppose) reports UB in the first example, but not in the second one. Real-life example: https://godbolt.org/z/gSkmMW
[Bug c++/91483] Poor diagnostic on trying to take constexpr reference to non-static object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91483 Marek Polacek changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-18 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Yup, that's true. I'll add it onto my list.
[Bug c++/91483] New: Poor diagnostic on trying to take constexpr reference to non-static object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91483
Bug ID: 91483
Summary: Poor diagnostic on trying to take constexpr reference
to non-static object
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider:
struct X {
int const& var;
};
void foo() {
constexpr int i = 42;
constexpr X x{i};
}
This is ill-formed because i doesn't have static storage duration. But the
error gcc provides is:
: In function 'void foo()':
:7:20: error: 'const X{i}' is not a constant expression
7 | constexpr X x{i};
|^
It would be a lot nicer if the diagnostic here explained the reason that this
isn't a constant expression.
[Bug rtl-optimization/91482] New: __builtin_assume_aligned should not break write combining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91482
Bug ID: 91482
Summary: __builtin_assume_aligned should not break write
combining
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msharov at users dot sourceforge.net
Target Milestone: ---
void write64 (void* p)
{
unsigned* p1 = (unsigned*) __builtin_assume_aligned (p, 8);
*p1++ = 0;
unsigned* p2 = (unsigned*) __builtin_assume_aligned (p1, 4);
*p2++ = 1;
}
When the two stores are written without __builtin_assume_aligned, they are
coalesced into a single movq store. The code above, however, results in two
movl stores, even though the new information provided by
__builtin_assume_aligned does not prevent combination.
[Bug target/91481] New: POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
Bug ID: 91481
Summary: POWER9 "DARN" RNG intrinsic produces repeated output
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lloyd at randombit dot net
Target Milestone: ---
The POWER9 ISA includes a hardware random number generator "DARN" which is
similar to x86 RDRAND/RDSEED. Using the GCC intrinsics and *any optimization
level* then `__builtin_darn()` and `__builtin_darn_raw()` produce repeated
output:
$ cat darn.c
#include
#include
int main()
{
uint64_t darn[32];
for(size_t i = 0; i != 32; ++i)
darn[i] = __builtin_darn(); // or __builtin_darn_raw()
for(size_t i = 0; i != 32; ++i)
printf("%016lX\n", darn[i]);
}
$ $HOME/opt/bin/powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/home/lloyd/opt/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/lloyd/opt/libexec/gcc/powerpc64le-unknown-linux-gnu/9.2.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc-9.2.0/configure --prefix=/home/lloyd/opt
--enable-languages=c,c++
Thread model: posix
gcc version 9.2.0 (GCC)
$ $HOME/opt/bin/powerpc64le-unknown-linux-gnu-gcc -mcpu=power9 -O -m64 darn.c
-o darn
$ ./darn
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
...
The binary produces a unique value each time it is executed, but the same value
repeats. If no optimization is used, then different values are produced. Since
these instructions are supposed to be used to seed cryptographic random number
generators, this is quite bad. I don't know PPC asm but my read of the
generated code when optimizations are enabled is that `darn` is invoked just
once and then the value is placed repeatedly into the array - maybe GCC has not
been taught that this instruction is volatile and produces a different output
each time it is used?
Originally observed with "gcc version 8.3.1 20190304 (Advance-Toolchain-at12.0)
[revision 269374] (GCC)" on gcc135, same behavior with stock GCC 9.2.0.
I don't think there is an issue with the hardware; if using inline asm instead
of the intrinsics, everything seems to work as expected.
[Bug fortran/91390] treatment of extra parameter in a subroutine call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390 --- Comment #5 from Thomas Koenig --- Created attachment 46724 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46724&action=edit Something that sort of works... and also extends the error message with a reference to where the mismatching procedure is defined.
[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91480 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-18 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The original macros in the Library Fundamentals TS were ints not longs, which is why some started that way. I've been gradually fixing them, but it's very, very low priority. Your example doesn't seem very realistic. The allocator traits one is a bug though.
[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242 --- Comment #24 from Dmitry G. Dyachenko --- r257061 optimize too gcc version 8.0.1 20180125 (experimental) [trunk revision 257061] (GCC)
[Bug fortran/91390] treatment of extra parameter in a subroutine call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390
Thomas Koenig changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
--- Comment #4 from Thomas Koenig ---
I'm currently working on this... finding a lot of interesting
cases in the test suite, in particular one where I am not sure
what to do.
The test case is gfortran.dg/goacc/acc_on_device-1.f95 , and the code is
! Have to enable optimizations, as otherwise builtins won't be expanded.
! { dg-additional-options "-O -fdump-rtl-expand" }
logical function f ()
implicit none
external acc_on_device
logical (4) acc_on_device
f = .false.
f = f .or. acc_on_device ()
f = f .or. acc_on_device (1, 2)
f = f .or. acc_on_device (3.14)
f = f .or. acc_on_device ("hello")
return
end function f
! Unsuitable to be handled as a builtin, so we're expecting four calls.
! { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]* acc_on_device" 4
"expand" } }
With my current patch, this would result in
/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95:12:12:
11 | f = f .or. acc_on_device ()
|2
12 | f = f .or. acc_on_device (1, 2)
|1
Error: More actual than formal arguments in procedure call at (1) for procedure
defined at (2)
/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95:13:12:
11 | f = f .or. acc_on_device ()
|2
12 | f = f .or. acc_on_device (1, 2)
13 | f = f .or. acc_on_device (3.14)
|1
Error: More actual than formal arguments in procedure call at (1) for procedure
defined at (2)
/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95:14:12:
11 | f = f .or. acc_on_device ()
|2
..
14 | f = f .or. acc_on_device ("hello")
|1
Error: More actual than formal arguments in procedure call at (1) for procedure
defined at (2)
where the warnings could be mitigated to a warning using -std=legacy.
Now, needless to say, this is illegal Fortran. Is the test case actually
a valid use case? Wouldn't it be better to make this into an intrinsic
with -fopenacc? Would it be acceptable to have to set -std=legacy on that
particular use case?
[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242 Dmitry G. Dyachenko changed: What|Removed |Added CC||dimhen at gmail dot com --- Comment #23 from Dmitry G. Dyachenko --- sounds like gcc10 r274581 optimize c#3 and c#4 c#3 gcc -O -S x.c f: .LFB0: .cfi_startproc leal2(%rdi,%rdi), %eax ret .cfi_endproc c#4 gcc -O -S y.c m: .LFB0: .cfi_startproc movl$0, %eax ret .cfi_endproc $ /usr/local/gcc_current/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc_current/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-pc-linux-gnu Configured with: /home/dimhen/src/gcc_current/configure --prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto --disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=native Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.0 20190816 (experimental) [trunk revision 274581] (GCC)
