[Bug libquadmath/94756] New: strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
Bug ID: 94756
Summary: strtoflt128 assigns some subnormals incorrectly on MS
Windows
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: sisyphus359 at gmail dot com
Target Milestone: ---
Created attachment 48370
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48370&action=edit
Demo strtoflt128 error with some subnormals on Windows
Because this bug ( which could have ties to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204 ) was presenting itself only
on Windows, I originally posted it to the mingw-w64 bug tracker (
https://sourceforge.net/p/mingw-w64/bugs/728/ ).
Today, the mingw-w64 developers informed me that it's a libquadmath bug that
should be reported here.
AFAICT, the subnormals that are being mis-assigned by strtoflt128 are those
whose absolute values are in the ranges:
0x1p-16414 to 0x1.p-16414
or
0x1.0318p-16446 to 0x1.p-16446
For the first of those ranges, all numbers that I tested were mis-assigned.
For the latter range, approximately 19 in 20 of the values I tested were being
mis-assigned.
Attached is a simple demo script that takes the value 1e-4941 (which is within
the first range) and does:
__float128 f1 = strtoflt128("1e-4941", NULL);
__float128 f2 = 1e-4941Q;
It then (on Windows) prints out the 2 values as:
f1: 0x0.00014707e947d757fbf6f7p-16382
f2: 0x0.00014707e946d257f2f674b9p-16382
f2 is assigned correctly, f1 is not.
It's the same result for both 32-bit and 64-bit gcc-8.3.0 (and earlier).
I've seen reports showing that Cygwin is affected in the same way.
On Ubuntu, I found that both f1 and f2 were being assigned correctly.
Note the correlation between this output and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204, wrt that particular value
of 1e-4941.
Cheers,
Rob
[Bug c/94755] [9/10 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94755 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.4 Ever confirmed|0 |1 Summary|[10 Regression] internal|[9/10 Regression] internal |compiler error: |compiler error: |Segmentation fault |Segmentation fault Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org Last reconfirmed||2020-04-25
[Bug c/94755] [9/10 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94755 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 48371 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48371&action=edit gcc10-pr94755.patch Untested fix.
[Bug c++/94752] [coroutines] compiler ICE with coroutine with unnamed parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94752 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-04-25 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- Created attachment 48372 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48372&action=edit fix posted thanks for the report
[Bug tree-optimization/94757] New: GCC does not optimise unsigned multiplication known not to overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94757
Bug ID: 94757
Summary: GCC does not optimise unsigned multiplication known
not to overflow
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.von.s at posteo dot de
Target Milestone: ---
This code:
#include
unsigned f(unsigned x) {
if (x > UINT_MAX / 3)
__builtin_unreachable();
return (x * 3) / 3;
}
should be possible to optimise into the identity function, but (on x86_64) gcc
-O3 generates a multiplication (via LEA) then a division (via multiplication).
GCC knows that the multiplication cannot overflow, because replacing the
returned expression with __builtin_mul_overflow_p(x, 3, x) is makes it optimise
to returning constant 0.
[Bug c++/94752] [coroutines] compiler ICE with coroutine with unnamed parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94752 Iain Sandoe changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |10.0
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 --- Comment #10 from CVS Commits --- The master branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:cf3f7b309ffdd888fdd85048ac9b4bcdc2713a45 commit r10-7960-gcf3f7b309ffdd888fdd85048ac9b4bcdc2713a45 Author: Thomas König Date: Sat Apr 25 12:28:15 2020 +0200 Fix PR 94578. Our intrinsics do not handle spans on their return values (yet), so this creates a temporary for subref array pointers. 2020-04-25 Thomas Koenig PR fortran/94578 * trans-expr.c (arrayfunc_assign_needs_temporary): If the LHS is a subref pointer, we also need a temporary. 2020-04-25 Thomas Koenig PR fortran/94578 * gfortran.dg/pointer_assign_14.f90: New test. * gfortran.dg/pointer_assign_15.f90: New test.
[Bug target/94758] New: ICE: in extract_insn, at recog.c:2310 on hppa64 with __thread variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94758
Bug ID: 94758
Summary: ICE: in extract_insn, at recog.c:2310 on hppa64 with
__thread variable
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Tested with 7.5.0, 8.4.0, 9.2.1, and 10.0.1, all give out the same error.
---
__thread int x;
int main()
{
x = 0;
}
---
test.c: In function ‘main’:
test.c:6:1: error: unrecognisable insn:
6 | }
| ^
(insn 6 3 7 2 (set (reg:DI 69)
(unspec:SI [
(const_int 0 [0])
] UNSPEC_TP)) "test.c":5:7 -1
(nil))
during RTL pass: vregs
test.c:6:1: internal compiler error: in extract_insn, at recog.c:2294
0x6491e5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x649201 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:116
0x646e97 extract_insn(rtx_insn*)
../../gcc/recog.c:2294
0xa5afc3 instantiate_virtual_regs_in_insn
../../gcc/function.c:1607
0xa5afc3 instantiate_virtual_regs
../../gcc/function.c:1977
0xa5afc3 execute
../../gcc/function.c:2026
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/93924] ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-25 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- Confirmed.
[Bug fortran/93563] Wrong code makes the compiler hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93563 Thomas Koenig changed: What|Removed |Added Last reconfirmed||2020-04-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||tkoenig at gcc dot gnu.org Keywords||ice-on-invalid-code, ||memory-hog --- Comment #1 from Thomas Koenig --- Confirmed.
[Bug c++/94759] New: coroutines: rejects traits specialisation with non-class returns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94759
Bug ID: 94759
Summary: coroutines: rejects traits specialisation with
non-class returns.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48373
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48373&action=edit
fix under test
>From the standard:
The header defines the primary template coroutine_traits such that
if ArgTypes is a parameter pack of types and if the qualified-id
R::promise_type is valid and denotes a type, then
coroutine_traits has the following publicly accessible member:
using promise_type = typename R::promise_type;
this should not prevent more specialised cases and the following code should
be accepted, but is currently rejected with
error: coroutine return type ‘void’ is not a class
#include
template
struct std::coroutine_traits {
struct promise_type {
promise_type (HandleRef h, T ...args)
{ h = std::coroutine_handle::from_promise (*this);
PRINT ("Created Promise");
}
void get_return_object() {}
auto initial_suspend() {
return std::suspend_always{};
}
auto final_suspend() { return std::suspend_never{}; }
void return_void() {}
void unhandled_exception() {}
};
};
void
my_coro (std::coroutine_handle<>& h)
{
PRINT ("coro1: about to return");
co_return;
}
[Bug c++/94759] coroutines: rejects traits specialisation with non-class returns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94759 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||rejects-valid Last reconfirmed||2020-04-25
[Bug preprocessor/94753] -undef, c++20 and feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-04-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug libstdc++/81480] Assertion `ec' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81480 --- Comment #3 from Jonathan Wakely --- You're missing extra flags to set up the necessary include paths. Why not just run 'make check' instead?
[Bug fortran/93563] Wrong code makes the compiler hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93563 --- Comment #2 from Dominique d'Humieres --- Gfortran 6.5 gives the error: class(TreeNode_t), dimension(:), allocatable :: children 1 Error: Derived type at (1) has not been previously defined and so cannot appear in a derived type definition After revision 241089 I get an ICE.
[Bug libstdc++/94749] std::istream::ignore discards too many characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94749 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-25 Ever confirmed|0 |1
[Bug c++/94760] New: coroutines: mismatch between traits and promise parameter preview.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94760
Bug ID: 94760
Summary: coroutines: mismatch between traits and promise
parameter preview.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48374
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48374&action=edit
fix under test
There was considerable confusion about how the various implementations
had interpreted the passing of 'this' and lambda capture object
pointers to traits lookup and the promise methods (constructor and
allocator)
In response, we changed the argument passed to the promise parameter
preview to match a reference to *this. That has made things inconsistent
and we need to match it in the traits
the following code should compile, but fails unable to find a suitable
promise CTOR.
struct Fake {} ;
template
struct std::coroutine_traits {
struct promise_type {
promise_type (CallOp op, T ...args) {}
Fake get_return_object() { return {}; }
std::suspend_always initial_suspend() { return {}; }
std::suspend_never final_suspend() { return {}; }
void return_void() {}
void unhandled_exception() {}
};
};
struct Foo
{
Fake operator() (int a) {
co_return;
}
};
[Bug c++/94760] coroutines: mismatch between traits and promise parameter preview.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94760 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-25 Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug fortran/93924] ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #2 from Dominique d'Humieres --- Up to revion r242391 I get the error: function selector() result(f) 1 Error: CLASS variable 'f' at (1) must be dummy, allocatable or pointer pr93924.f90:29:19: function apply(f, x) result(y) 1 Error: CLASS variable 'f' at (1) must be dummy, allocatable or pointer pr93924.f90:51:4: use cs 1 Fatal Error: Can't open module file 'cs.mod' for reading at (1): No such file or directory compilation terminated. I see the ICE at revision r242749.
[Bug fortran/94737] [8/9/10 Regression] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 Thomas Koenig changed: What|Removed |Added Summary|BIND(C) names are not |[8/9/10 Regression] BIND(C) |always treated as case |names are not always |sensitive. Versions < 8|treated as case sensitive. |are ok. | Keywords||rejects-valid CC||tkoenig at gcc dot gnu.org Target Milestone|--- |8.5
[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Summary|[8/9/10 Regression] BIND(C) |BIND(C) names are not |names are not always|always treated as case |treated as case sensitive. |sensitive. Resolution|--- |INVALID --- Comment #2 from Thomas Koenig --- Correction, this is not a regression. F2018 has, in 19.2, paragraph 2 # The global identifier of an entity shall not be the same as the global # identifier of any other entity. Furthermore, a binding label shall not # be the same as the global identifier of any other global entity, # ignoring differences in case. So, the error message is correct, and you need to change your program accordingly.
[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739 --- Comment #2 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:8fc8bf801e46d0d478c50bddecf5d8edf9511849 commit r10-7961-g8fc8bf801e46d0d478c50bddecf5d8edf9511849 Author: H.J. Lu Date: Sat Apr 25 10:06:59 2020 -0700 Enable Intel CET in liblto_plugin.so on Intel CET enabled host Since ld is Intel CET enabled on Intel CET enabled host, dlopen fails on liblto_plugin.so if it isn't Intel CET enabled. Add GCC_CET_HOST_FLAGS to cet.m4, use it in libiberty and lto-plugin to always enable Intel CET in liblto_plugin.so on Intel CET enabled host. On Linux/x86 host, enable Intel CET by default if assembler and compiler support Intel CET so that the generated liblto_plugin.so can be used on both CET and non-CET machines. It is an error to disable Intel CET in liblto_plugin.so on Intel CET enabled host. config/ PR bootstrap/94739 * cet.m4 (GCC_CET_HOST_FLAGS): New. libiberty/ PR bootstrap/94739 * Makefile.in (COMPILE.c): Add @CET_HOST_FLAGS@. (configure_deps): Add $(srcdir)/../config/cet.m4 and $(srcdir)/../config/enable.m4. * aclocal.m4: Include ../config/cet.m4 and ../config/enable.m4. * configure.ac: Add GCC_CET_HOST_FLAGS(CET_HOST_FLAGS) and AC_SUBST(CET_HOST_FLAGS). * configure: Regenerated. lto-plugin/ PR bootstrap/94739 * Makefile.am (AM_CFLAGS): Add $(CET_HOST_FLAGS). * configure.ac: Add GCC_CET_HOST_FLAGS(CET_HOST_FLAGS) and AC_SUBST(CET_HOST_FLAGS). * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise.
[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739 H.J. Lu changed: What|Removed |Added Target Milestone|--- |10.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from H.J. Lu --- Fixed for GCC 10.
[Bug c/94761] New: host != target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94761 Bug ID: 94761 Summary: host != target Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.kokovic at gmail dot com Target Milestone: ---
[Bug bootstrap/94761] host != target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94761 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-04-25 Component|c |bootstrap --- Comment #1 from Andrew Pinski --- I build that all the time, though I don't build the target libraries with that compiler, I always skip that step and just copy them from the cross compiler. What is going wrong for you?
[Bug ipa/94762] New: ICE: Segmentation fault (in is_tm_irrevocable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94762
Bug ID: 94762
Summary: ICE: Segmentation fault (in is_tm_irrevocable)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, trans-mem
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-10.0.1-alpha20200419 snapshot (g:717e91dbc44c6bf55a498f45f6045191ceb10a11),
gcc 9.3, gcc 8.3, gcc 7.3 all ICE when compiling the following testcase,
reduced from
test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
from the libcxx 10.0.0 test suite, w/ -O1 -fgnu-tm:
_Bool __attribute__ ((transaction_safe))
g5 (int fh, int gf)
{
return __atomic_compare_exchange_n (&fh, &gf, 0, 0, 0, 0);
}
% x86_64-unknown-linux-gnu-gcc-10.0.1 -O1 -fgnu-tm -c gl8a6jtn.c
during IPA pass: tmipa
gl8a6jtn.c: In function 'g5':
gl8a6jtn.c:5:1: internal compiler error: Segmentation fault
5 | }
| ^
0xd9466f crash_signal
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/toplev.c:328
0xd9a5e0 is_tm_irrevocable
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/trans-mem.c:234
0xd9c20f ipa_tm_scan_irr_block
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/trans-mem.c:4377
0xd9c20f ipa_tm_scan_irr_blocks
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/trans-mem.c:4449
0xd9c9b5 ipa_tm_scan_irr_function
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/trans-mem.c:4611
0xd9ea1e ipa_tm_execute
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/trans-mem.c:5512
0xd9ea1e execute
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/trans-mem.c:5670
Citing Jakub's PR94106 comment 2: "Nobody really maintains the -fgnu-tm stuff
anymore".
I didn't test it but it looks like Marek's patch from PR68122 comment 8, even
if is not a right fix, works this ICE around.
[Bug testsuite/94763] New: UNRESOLVED scan assembler tests on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763 Bug ID: 94763 Summary: UNRESOLVED scan assembler tests on arm-none-eabi Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vvinayag at arm dot com Target Milestone: --- Many tests are UNRESOLVED on arm-none-eabi. UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++14 scan-assembler _Z1fB3barB3fooi UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++14 scan-assembler _Z1gB3baz1AB3bar UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++17 scan-assembler _Z1fB3barB3fooi UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++17 scan-assembler _Z1gB3baz1AB3bar UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++2a scan-assembler _Z1fB3barB3fooi UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++2a scan-assembler _Z1gB3baz1AB3bar UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++98 scan-assembler _Z1fB3barB3fooi UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++98 scan-assembler _Z1gB3baz1AB3bar UNRESOLVED: g++.dg/abi/abi-tag10.C -std=c++14 scan-assembler _ZNK4hashI12basic_stringB5cxx11Ic11char_traitsIcE9allocatorIcEEEclES5_ UNRESOLVED: g++.dg/abi/abi-tag10.C -std=c++17 scan-assembler _ZNK4hashI12basic_stringB5cxx11Ic11char_traitsIcE9allocatorIcEEEclES5_ UNRESOLVED: g++.dg/abi/abi-tag10.C -std=c++2a scan-assembler _ZNK4hashI12basic_stringB5cxx11Ic11char_traitsIcE9allocatorIcEEEclES5_ UNRESOLVED: g++.dg/abi/abi-tag10.C -std=c++98 scan-assembler _ZNK4hashI12basic_stringB5cxx11Ic11char_traitsIcE9allocatorIcEEEclES5_ UNRESOLVED: g++.dg/abi/abi-tag11.C -std=c++14 scan-assembler _Z1fSbB3fooIwSt11char_traitsIwESaIwEES3_ UNRESOLVED: g++.dg/abi/abi-tag11.C -std=c++17 scan-assembler _Z1fSbB3fooIwSt11char_traitsIwESaIwEES3_ UNRESOLVED: g++.dg/abi/abi-tag11.C -std=c++2a scan-assembler _Z1fSbB3fooIwSt11char_traitsIwESaIwEES3_ UNRESOLVED: g++.dg/abi/abi-tag11.C -std=c++98 scan-assembler _Z1fSbB3fooIwSt11char_traitsIwESaIwEES3_ UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++14 scan-assembler _Z1aB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++14 scan-assembler _Z1fB5cxx11v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++14 scan-assembler _Z1fPN7__cxx111AE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++14 scan-assembler _Z1gIN7__cxx111AEET_v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++14 scan-assembler _Z1vIN7__cxx111AEE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++17 scan-assembler _Z1aB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++17 scan-assembler _Z1fB5cxx11v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++17 scan-assembler _Z1fPN7__cxx111AE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++17 scan-assembler _Z1gIN7__cxx111AEET_v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++17 scan-assembler _Z1vIN7__cxx111AEE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++2a scan-assembler _Z1aB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++2a scan-assembler _Z1fB5cxx11v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++2a scan-assembler _Z1fPN7__cxx111AE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++2a scan-assembler _Z1gIN7__cxx111AEET_v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++2a scan-assembler _Z1vIN7__cxx111AEE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++98 scan-assembler _Z1aB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++98 scan-assembler _Z1fB5cxx11v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++98 scan-assembler _Z1fPN7__cxx111AE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++98 scan-assembler _Z1gIN7__cxx111AEET_v UNRESOLVED: g++.dg/abi/abi-tag16.C -std=gnu++14 scan-assembler _ZGVZN1N1FEvE4NameB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag16.C -std=gnu++17 scan-assembler _ZGVZN1N1FEvE4NameB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag16.C -std=gnu++2a scan-assembler _ZGVZN1N1FEvE4NameB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag16.C -std=gnu++98 scan-assembler _ZGVZN1N1FEvE4NameB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag16a.C -std=gnu++14 scan-assembler _ZGVZN1N1FEvE4Name UNRESOLVED: g++.dg/abi/abi-tag16a.C -std=gnu++17 scan-assembler _ZGVZN1N1FEvE4Name UNRESOLVED: g++.dg/abi/abi-tag16a.C -std=gnu++2a scan-assembler _ZGVZN1N1FEvE4Name UNRESOLVED: g++.dg/abi/abi-tag16a.C -std=gnu++98 scan-assembler _ZGVZN1N1FEvE4Name UNRESOLVED: g++.dg/abi/abi-tag17.C -std=c++14 scan-assembler _Z3fi1B6_X_tagv UNRESOLVED: g++.dg/abi/abi-tag17.C -std=c++17 scan-assembler _Z3fi1B6_X_tagv UNRESOLVED: g++.dg/abi/abi-tag17.C -std=c++2a scan-assembler _Z3fi1B6_X_tagv UNRESOLVED: g++.dg/abi/abi-tag17.C -std=c++98 scan-assembler _Z3fi1B6_X_tagv UNRESOLVED: g++.dg/template/friend56.C -std=c++14 scan-assembler _Z1fv UNRESOLVED: g++.dg/template/friend56.C -std=c++17 scan-assembler _Z1fv UNRESOLVED: g++.dg/template/friend56.C -std=c++2a scan-assembler _Z1fv UNRESOLVED: g++.dg/template/friend56.C -std=c++98 scan-assembler _Z1fv UNRESOLVED: g++.dg/template/linkage1.C -std=c++14 scan-assembler
[Bug c/94746] -Wsizeof-pointer-div not triggered by system header macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94746 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #1 from Arseny Solokha --- I'm not a GCC developer, but this is by design. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wsystem-headers
[Bug c++/94764] New: block extern incorrectly resolved to external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94764
Bug ID: 94764
Summary: block extern incorrectly resolved to external linkage
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tabloid.adroit at gmail dot com
Target Milestone: ---
Related to DR426
source:
https://stackoverflow.com/questions/61276220/why-same-named-extern-local-variables-in-different-blocks-get-different-linkages
// foo.cpp
int var = 10;// external linkage
// main.cpp
#include
static int var = 100;// internal linkage
int main() {
extern int var; // internal linkage
std::cout << var << std::endl;
{
extern int var; // g++: external linkage , clang++: internal
linkage
std::cout << var << std::endl;
{
extern int var; // g++: external linkage , clang++: internal
linkage
std::cout << var << std::endl;
}
}
}
g++ : "100 10 10"
clang++ : "100 100 100" (msvc++)
[basic.link] #6 is pretty clear about this. I'm not sure it is a UB.
[Bug c++/94764] block extern incorrectly resolved to external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94764 Andrew Pinski changed: What|Removed |Added Depends on||14769 --- Comment #1 from Andrew Pinski --- See PR 14769 also. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14769 [Bug 14769] [DR 426] Block extern incorrectly resolved to file-scope internal linkage object
[Bug c++/94764] block extern incorrectly resolved to external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94764 --- Comment #2 from tabloid.adroit at gmail dot com --- Do you think it is still UB at this moment? If not, I guess PR14769 could be worked on?
[Bug c++/94765] New: Floating point type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94765
Bug ID: 94765
Summary: Floating point type template parameter
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: emmanuel.le-tr...@cnrs-orleans.fr
Target Milestone: ---
With C++20, non-type template parameters can now be any scalar type[0] which
include floating point types[1]. So this
template struct S {};
should compile. The rules for type equivalence are straightforward[2]
[0] http://eel.is/c++draft/temp#param-6
[1] http://eel.is/c++draft/basic.types#9
[2] http://eel.is/c++draft/temp.type#2
[Bug go/94766] New: gcc/go/gofrontend/gogo.h:1076:25: performance: Function parameter 'afnname' should be passed by const reference. [passedByValue]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94766 Bug ID: 94766 Summary: gcc/go/gofrontend/gogo.h:1076:25: performance: Function parameter 'afnname' should be passed by const reference. [passedByValue] Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dcb314 at hotmail dot com CC: cmang at google dot com Target Milestone: --- Source code is Specific_type_function(Type* atype, Named_type* aname, int64_t asize, Specific_type_function_kind akind, const std::string afnname, Function_type* afntype) Suggest new code Specific_type_function(Type* atype, Named_type* aname, int64_t asize, Specific_type_function_kind akind, const std::string & afnname, Function_type* afntype)
[Bug go/94766] gcc/go/gofrontend/gogo.h:1076:25: performance: Function parameter 'afnname' should be passed by const reference. [passedByValue]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94766
--- Comment #1 from David Binderman ---
Similar thing with file gcc/go/gofrontend/names.cc:
trunk.git/gcc/go/gofrontend/names.cc:1027:47: performance: Function parameter
'pkgpath' should be passed by const reference. [passedByValue]
Source code is
std::string
Gogo::type_descriptor_list_symbol(std::string pkgpath)
{
return pkgpath + "..types";
}
[Bug preprocessor/77488] Proposal for __FILENAME_ONLY__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #8 from Fangrui Song --- Clang since version 9 supports `__FILE_NAME__` (basename) as an extension https://reviews.llvm.org/D61756 I don't know whether it has been proposed on WG14 or WG21 mailing lists, though (seems not).
[Bug translation/94698] Improper French translation for "override"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94698 --- Comment #4 from Frederic Marchal --- French translation has been updated and submitted to the Translation Project. Thanks for the report.
[Bug c/94746] -Wsizeof-pointer-div not triggered by system header macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94746 --- Comment #2 from Alejandro Colomar --- Maybe the design is not perfect. Maybe some special warnings should still be warned about when they are used in user's code. I don't think there are any possible false positives with this warning. But still I don't know. Maybe I should add a pragma in the system header to enable `-Wsystem-headers` for that macro.
[Bug c++/94765] Floating point type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94765 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-25 --- Comment #1 from Jonathan Wakely --- https://gcc.gnu.org/projects/cxx-status.html says that P1907R1 is supported since GCC 9, which seems unlikely when P1907R1 wasn't approved until 6 months after GCC 9.1 was released. That page also says that the relevant feature test macro check is __cpp_nontype_template_parameter_class >= 201806, which is wrong because the check for P1907R1 is __cpp_nontype_template_args >= 201911, and GCC defines: #define __cpp_nontype_template_args 201411L I think it's a doc bug, and the feature is not implemented yet.
[Bug c/94746] -Wsizeof-pointer-div not triggered by system header macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94746
--- Comment #3 from Alejandro Colomar ---
I tried to use ``#pragma GCC diagnostic`` to enable ``-Wsystem-headers`` only
for that macro. It bloated me with completely unrelated errors from libraries.
So it is not an option.
The only workaround right now is to use a ``_Static_assert``:
.. code-block:: c
#include
#define is_same_type(a, b) \
__builtin_types_compatible_p(__typeof__(a), __typeof__(b))
#define is_array(a) (!is_same_type((a), &(a)[0]))
#define Static_assert_array(a) \
_Static_assert(is_array(a), "Not a `[]` !")
#define ARRAY_SIZE(arr) __extension__( \
{ \
Static_assert_array(arr); \
__arraycount((arr));\
} \
)
This macro is safe no matter which warnings are enabled. There is no other way
to write a safe macro in a system library for calculating the size of an array.
I would call that a bug. The warning is completely useless, unless you keep
copy&pasting that macro for each and every project, which is of course *wrong*.
[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 kargl at gcc dot gnu.org changed: What|Removed |Added Keywords|rejects-valid | --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #2) > Correction, this is not a regression. > > F2018 has, in 19.2, paragraph 2 > > # The global identifier of an entity shall not be the same as the global > # identifier of any other entity. Furthermore, a binding label shall not > # be the same as the global identifier of any other global entity, > # ignoring differences in case. > > So, the error message is correct, and you need to change your > program accordingly. Good catch, Thomas! In hindsight, the restriction makes prefect sense given Fortran is a case insensitive language.
[Bug c++/94767] New: (unsigned bitfield) + (int) operation results in int, not unsigned int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94767 Bug ID: 94767 Summary: (unsigned bitfield) + (int) operation results in int, not unsigned int. Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jh718.park at samsung dot com Target Milestone: --- For these variables below, unsigned m_schemeEnd : 26; unsigned m_userStart; m_userStart == m_schemeEnd + 1 this comparison emits a compiler warning as below. warning: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Wsign-compare] This bug was found during WebKit gtk port build with gcc 9.3.0. Temporarily, this warning was removed by this patch, https://trac.webkit.org/changeset/260715/webkit like bool slashSlashNeeded = m_userStart == static_cast(m_schemeEnd + 1); but we think that this bug should be fixed in gcc.
[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 --- Comment #4 from Lee Busby --- (In reply to kargl from comment #3) > (In reply to Thomas Koenig from comment #2) > > Correction, this is not a regression. > > > > F2018 has, in 19.2, paragraph 2 > > > > # The global identifier of an entity shall not be the same as the global > > # identifier of any other entity. Furthermore, a binding label shall not > > # be the same as the global identifier of any other global entity, > > # ignoring differences in case. > > > > So, the error message is correct, and you need to change your > > program accordingly. > > Good catch, Thomas! > > In hindsight, the restriction makes prefect sense given > Fortran is a case insensitive language. I don't have any particular problem using 19.2 to make this a feature, not a bug. Clarity is always better. I wonder how does 19.2 square with 8.5.5, lines 13-14: # If the value of the [NAME=scalar-character-constant] is [...] nonzero, # it shall be valid as an identifier on the companion processor. If you ignore the case of an identifier in the C language (the "companion processor"?), I suppose it is still "valid". But it's the wrong one. Oh, well, above my pay grade. Thank you for your investigation, and ongoing work on gfortran.
[Bug target/94736] Missing ENDBR at label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94736 --- Comment #1 from Hongtao.liu --- Indirect jump `goto *p` is optimized off, so there's no indirect jump, either no need for inserting endbr64
[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 --- Comment #5 from Steve Kargl --- On Sun, Apr 26, 2020 at 02:39:37AM +, busby1 at llnl dot gov wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 > > --- Comment #4 from Lee Busby --- > (In reply to kargl from comment #3) > > (In reply to Thomas Koenig from comment #2) > > > Correction, this is not a regression. > > > > > > F2018 has, in 19.2, paragraph 2 > > > > > > # The global identifier of an entity shall not be the same as the global > > > # identifier of any other entity. Furthermore, a binding label shall not > > > # be the same as the global identifier of any other global entity, > > > # ignoring differences in case. > > > > > > So, the error message is correct, and you need to change your > > > program accordingly. > > > > Good catch, Thomas! > > > > In hindsight, the restriction makes prefect sense given > > Fortran is a case insensitive language. > > I don't have any particular problem using 19.2 to make this a feature, not a > bug. Clarity is always better. I wonder how does 19.2 square with 8.5.5, > lines > 13-14: > > # If the value of the [NAME=scalar-character-constant] is [...] nonzero, > # it shall be valid as an identifier on the companion processor. > > If you ignore the case of an identifier in the C language (the "companion > processor"?), I suppose it is still "valid". But it's the wrong one. Oh, > well, above my pay grade. Thank you for your investigation, and ongoing work > on gfortran. > I suppose I don't quite follow you. gfortran flagged an error in your code. Thomas took the time to locate the passage in the Fortran standard that confirms you have an error in your code. You would rather ask the diminishing number of volunteers to add an extension to gfortran to to compile your nonconforming code than fix the code. Seems reasonable.
