[Bug libstdc++/101227] Clang++ fails to instantiate std::optional if nested type has a non-static data member initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101227 --- Comment #1 from Andrew Pinski --- clang is failing because of "requirement 'is_constructible_v' was not satisfied [with _Tp = Bar::Foo, _Args = <>]" But it seems like it should be true. from https://en.cppreference.com/w/cpp/types/is_constructible: "If T is an object or reference type and the variable definition T obj(std::declval()...); is well-formed, provides the member constant value equal to true. In all other cases, value is false. For the purposes of this check, the variable definition is never interpreted as a function declaration, and the use of std::declval is not considered an odr-use. " So the question becomes why is std::is_constructible::value is false.
[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228 Andrew Pinski changed: What|Removed |Added Summary|#include |tbb/task.h is Deprecated in |triggers Intel TBB warning |newer TBB. |for tbb/task.h | Last reconfirmed||2021-06-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- tbb/task.h just got deprecated last year and after parallel_backend_tbb.h was added to GCC. https://github.com/oneapi-src/oneTBB/issues/243 It depends on the version of TBB that is installed really. Looks like Ubuntu 11.1.0 is using a much newer version. You really should file a bug with Ubuntu about this issue since you are getting both GCC and TBB from them. We won't fixing Ubuntu's compiler even with this bug filed by the way.
[Bug libstdc++/101228] #include triggers Intel TBB warning for tbb/task.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228 --- Comment #1 from Kip Warner --- Suggestion: Maybe a unit test that includes all the standard STL headers, does nothing with them, and that's expected to emit no warnings would mitigate problems like this occurring in the future.
[Bug libstdc++/101228] New: #include triggers Intel TBB warning for tbb/task.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228
Bug ID: 101228
Summary: #include triggers Intel TBB warning for
tbb/task.h
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
I've managed to reproduce this issue on two different machines, one amd64 and
the other ppc64le. Both were using g++-11 (Ubuntu 11.1.0-1ubuntu1~21.04)
11.1.0.
Here is a minimal:
#include
#include
using namespace std;
int main()
{
vector Container(3'000'000);
iota(begin(Container), end(Container), 1);
sort(execution::par, begin(Container), end(Container));
return 0;
}
Compiling raises the following pragma in header generated warning:
$ g++-11 test.cpp -o test -Wall -Werror -std=c++17 -ltbb && ./test
In file included from /usr/include/c++/11/pstl/parallel_backend_tbb.h:26,
from /usr/include/c++/11/pstl/parallel_backend.h:20,
from /usr/include/c++/11/pstl/algorithm_impl.h:22,
from /usr/include/c++/11/pstl/glue_execution_defs.h:50,
from /usr/include/c++/11/execution:32,
from test.cpp:4:
/usr/include/tbb/task.h:21:139: note: ‘#pragma message: TBB Warning: tbb/task.h
is deprecated. For details, please see Deprecated Features appendix in the TBB
reference manual.’
21 | ("TBB Warning: tbb/task.h is deprecated. For details, please see
Deprecated Features appendix in the TBB reference manual.")
|
^
Compiling again with #define TBB_SUPPRESS_DEPRECATED_MESSAGES 1 prepended to
the beginning and the warning disappears.
This appears to have crept in some how with the 11 series. The
header is indirectly including some deprecated Intel header from the TBB
library.
[Bug libstdc++/101227] New: Clang++ fails to instantiate std::optional if nested type has a non-static data member initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101227
Bug ID: 101227
Summary: Clang++ fails to instantiate std::optional if nested
type has a non-static data member initializer
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: florin at iucha dot net
Target Milestone: ---
I have reported https://bugs.llvm.org/show_bug.cgi?id=50904 and David suggested
it might be a bug in libstdc++.
GCC11.1 compiles this ok, Clang11 fails:
#include
class Bar
{
public:
struct Foo
{
int someInt = 3;
};
std::optional theFoo;
};
int main()
{
Bar aBar;
aBar.theFoo = std::make_optional();
return 0;
}
---
:18:18: error: no matching function for call to 'make_optional'
aBar.theFoo = std::make_optional();
^~~~
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/optional:1276:5:
note: candidate template ignored: requirement 'is_constructible_v'
was not satisfied [with _Tp = Bar::Foo, _Args = <>]
make_optional(_Args&&... __args)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/optional:1268:5:
note: candidate function template not viable: requires single argument '__t',
but no arguments were provided
make_optional(_Tp&& __t)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/optional:1284:5:
note: candidate function template not viable: requires at least argument
'__il', but no arguments were provided
make_optional(initializer_list<_Up> __il, _Args&&... __args)
^
1 error generated.
Compiler returned: 1
[Bug fortran/100917] Bind(c): errors handling long double real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #4 from sandra at gcc dot gnu.org --- I've observed this bug in my own testing as well, and traced it to the same cause: the GFC descriptor structure doesn't encode the kind, only the elem_len, so the runtime can't convert it to a valid C descriptor. IIUC the GFC descriptor needs to encode the kind to support assumed-type arguments in functions that are not declared bind(c) (for example, a subroutine with Fortran binding that acts as a wrapper around a C function). I imagine any proper fix for this would involve an ABI change affecting programs that don't even use bind(c).
[Bug tree-optimization/101139] Unable to remove double byteswap in fast path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101139 --- Comment #4 from Steinar H. Gunderson --- Yes, the integer promotion actually costs some performance. It happens on both x86 and Arm. Should I file that as a separate bug?
[Bug d/101226] New: Suboptimal codegen for >>/>>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101226
Bug ID: 101226
Summary: Suboptimal codegen for >>/>>>
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: maxsamukha at gmail dot com
Target Milestone: ---
Target: AVR
example.d:
void f1()
{
__gshared ubyte value;
value >>>= 5;
}
void f2()
{
__gshared ubyte value;
value = value >>> 5;
}
avr-gcc -fno-druntime -O3 example.d:
example.f1():
lds r24,example.f1().value
swap r24
lsr r24
andi r24,lo8(7)
sts example.f1().value,r24
ret
example.f2():
lds r24,example.f2().value
ldi r25,0
ldi r27,0
ldi r26,0
ldi r18,5
1:
lsr r27
ror r26
ror r25
ror r24
dec r18
brne 1b
sts example.f2().value,r24
ret
The compiler apparently fails to optimize out the integer promotion for >>> in
f2 and produces inefficient machine code.
[Bug tree-optimization/101225] New: Example where y % 16 == 0 seems more expensive than y % 400 == 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101225
Bug ID: 101225
Summary: Example where y % 16 == 0 seems more expensive than y
% 400 == 0.
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cassio.neri at gmail dot com
Target Milestone: ---
Consider this implementation of is_leap_year:
bool is_leap_year_1(short year) {
return year % 100 == 0 ? year % 400 == 0 : year % 4 == 0;
}
If a number is multiple of 100, then it's divisible by 400 if and only if it's
divisible by 16. Since checking divisibility by 16 is cheap, one would expect
the following version to be more efficient (at least, not worse):
bool is_leap_year_2(short year) {
return year % 100 == 0 ? year % 16 == 0 : year % 4 == 0;
}
According to [1] the latter is 1.4x slower than the former.
The emitted instructions with -O3 [2] don't seem bad and, except for a leal x
addw, the difference is a localized strength-reduction from "y % 400 == 0" to
"y % 16 == 0":
is_leap_year_1(short):
imulw $23593, %di, %ax
leal 1308(%rax), %edx
rorw $2, %dx
cmpw $654, %dx
ja .L2
addw $1296, %ax # Begin: year % 400 == 0
rorw $4, %ax#
cmpw $162, %ax #
setbe %al # End : year % 400 == 0
ret
.L2:
andl $3, %edi
sete %al
ret
is_leap_year_2(short):
imulw $23593, %di, %ax
addw $1308, %ax
rorw $2, %ax
cmpw $654, %ax
ja .L6
andl $15, %edi # Begin: y % 16 == 0
sete %al # End : y % 16 == 0
ret
.L6:
andl $3, %edi
sete %al
ret
FWIW: My educated **guess** is that the issue is the choice of registers: for
version 1 just after leal, the register rax/ax/al is free and regardless of the
branch taken, the CPU can continue the calculation of "y % 100 == 0" in
parallel with the other divisibility check, up to "sete %al". For version 2,
rax/ax/al is busy during the whole execution of "y % 100" and "sete %al" can't
be preemptively executed. As a test for my theory I reimplemented half of
is_leap_year_2 in inline asm (see in [1] and [2]) using similar choices of
registers as in is_leap_year_1 and I got the performance boost that I was
expecting.
[1] https://quick-bench.com/q/3U8t4qzXxtSpsehbWNOh3SWxBGQ
[2] https://godbolt.org/z/jfK3j5777
Note: [1] runs GCC 10.2 but the same happens on GCC 11.0.0.
[Bug tree-optimization/89976] [9/10/11/12 Regression] missing -Wuninitialized for struct member due to sra and TREE_NO_WARNING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976
--- Comment #6 from Eric Gallager ---
(In reply to Martin Sebor from comment #4)
> In all cases and with -O1 and above, the uninitialized read is clearly
> visible in the IL but it's suppressed because the variable (such as x$x in
> case 1) has the TREE_NO_WARNING bit set. This appears to be regression
> introduced in GCC 4.5 in r147980.
>
> gcc -O1 -S -Wall -std=c++14 -fdump-tree-uninit=/dev/stdout pr89976.C
>
> ;; Function foo (_Z3foov, funcdef_no=3, decl_uid=2098, cgraph_uid=4,
> symbol_order=3)
>
> struct X foo ()
> {
> int x$x; <<< TREE_NO_WARNING == 1
> struct X D.2133;
>
>[local count: 1073741824]:
> D.2133.x = x$x_2(D); <<< uninitialized read
> D.2133.y = 0;
> return D.2133;
>
> }
>
>
>
> ;; Function main (main, funcdef_no=4, decl_uid=2129, cgraph_uid=5,
> symbol_order=4) (executed once)
>
> int main ()
> {
> int x$x; <<< TREE_NO_WARNING == 1
> struct X D.2156;
> struct X x;
>
>[local count: 1073741824]:
> x ={v} {CLOBBER};
> return x$x_5(D); <<< uninitialized read
>
> }
did your TREE_NO_WARNING overhaul affect this at all?
[Bug middle-end/99959] [9/10/11/12 Regression] missing -Wuninitialized for an esra variable with TREE_NO_WARNING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99959
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #3 from Eric Gallager ---
(In reply to Martin Sebor from comment #1)
> The warning has been suppressed since r230968 (6.0.0 20151126). Until then,
> GCC issued:
>
> pr99959.c:7:5: warning: ‘FRAME.0.i’ is used uninitialized in this function
> [-Wuninitialized]
> __builtin_printf ("%i", i); // missing -Wuninitialized
> ^~
did your TREE_NO_WARNING overhaul affect this at all?
[Bug c++/74762] [9/10/11/12 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #19 from Eric Gallager --- does the TREE_NO_WARNING overhaul that Martin Sebor did affect this?
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 --- Comment #6 from Patrick Palka --- Fixed for GCC 12.
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9f26e34a5a9614a5b66f146752ecef9ea67b3e2d commit r12-1829-g9f26e34a5a9614a5b66f146752ecef9ea67b3e2d Author: Patrick Palka Date: Sat Jun 26 11:05:54 2021 -0400 c++: access scope during partial spec matching [PR96204] Here, when determining whether the partial specialization matches has_type_member, we do so from the scope of where the template-id appears rather than from the scope of the specialization, and this causes us to select the partial specialization (since Child::type is accessible from Parent). When we later instantiate this partial specialization, we've entered the scope of the specialization and so substitution into e.g. the DECL_CONTEXT of has_type_member::value fails with access errors since the friend declaration that we relied on to choose the partial specialization no longer applies. It seems the appropriate access scope from which to perform partial specialization matching is the specialization itself (similar to how we check access of base-clauses), which is what this patch implements. PR c++/96204 gcc/cp/ChangeLog: * pt.c (instantiate_class_template_1): Enter the scope of the type when calling most_specialized_partial_spec. gcc/testsuite/ChangeLog: * g++.dg/template/access40.C: New test. * g++.dg/template/access40a.C: New test.
[Bug c/98892] FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98892 --- Comment #3 from Jim Wilson --- On second thought, I don't think that there is anything wrong with dg-*-multiline-output. The problem is simply that the diagnostic code is left shifting the error message by m_x_offset_display, and this left shit causes the printed message to not match the expected message. The difference is only a few chars of white space which makes it very hard to see the problem when inspecting the test log. You have to count white space characters to see the problem. In my case, there is one less space char in the printed message than in the expected message. And it looks like the solution is -fmessage-length=0 which is already added to ALWAYS_CXXFLAGS and should maybe be added to ALWAYS_TEST_FLAGS instead. Or maybe just added to this one testcase for now to make it work.
[Bug c++/101224] New: Problem with interaction of modules and std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101224 Bug ID: 101224 Summary: Problem with interaction of modules and std::unique_ptr Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: p.cross13 at yahoo dot com Target Milestone: --- Created attachment 51063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51063=edit main program file with two module files included in comments, plus compiler output and compiler version in comments Code that compiles without modules, and uses std::unique_ptr, has a problem when parts of the code are moved to modules $ /d/gcc11/bin/g++ -std=c++20 -fmodules-ts FmtMain.cpp In file included from d:\gcc11\include\c++\11.1.0\memory:76, from FmtMain.cpp:1: d:\gcc11\include\c++\11.1.0\bits\unique_ptr.h: In instantiation of 'void std::default_delete<_Tp>::operator()(_Tp*) const [with _Tp = Fmt1@Fmt1]': d:\gcc11\include\c++\11.1.0\bits\unique_ptr.h:361:17: required from 'std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = Fmt1@Fmt1; _Dp = std::default_delete]' FmtMain.cpp:24:24: required from here d:\gcc11\include\c++\11.1.0\bits\unique_ptr.h:85:9: error: array subscript is not an integer 85 | delete __ptr; | ^~~~
[Bug driver/93645] Support Clang 12 --ld-path=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645 --- Comment #9 from Artur Sinila --- What's a blocker for this bug? What should be improved in the patch in order for it to be accepted?
[Bug fortran/101135] Use of absent assumed-shape array argument as an actual argument for an optional dummy argument mistakenly flagged as error by UndefinedBehaviourSanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135
--- Comment #2 from Marcel Jacobse ---
I think I found the issue within gfortran by looking at the output of
-fdump-tree-all. For the example, the file a-example.f90.005t.original lists
this intermediate representation for test_wrapper:
__attribute__((fn spec (". w ")))
void test_wrapper (real(kind=4)[1] * restrict y)
{
{
struct array01_real(kind=4) parm.5;
struct array01_real(kind=4) * D.3980;
parm.5.span = 4;
parm.5.dtype = {.elem_len=4, .rank=1, .type=3};
parm.5.dim[0].lbound = 1;
parm.5.dim[0].ubound = 1;
parm.5.dim[0].stride = 1;
parm.5.data = (void *) &(*y)[0];
parm.5.offset = -1;
D.3980 = y != 0B ? : 0B;
test (D.3980);
}
}
While there is a check for parameter y being present in the assignment for
D.3980, it kinda seems too late. For setting the data member of the parm.5
array descriptor, parameter y was already dereferenced unconditionally before.
So if y is absent, there is a null pointer dereference that UBSan seems to
complain about, even if its result is never used.
As a rookie attempt to fix this, I added a conditional to the data member
assignment:
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index a6bcd2b5ab7..503ceba82ee 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7068,6 +7068,13 @@ gfc_get_dataptr_offset (stmtblock_t *block, tree parm,
tree desc, tree offset,
/* Set the target data pointer. */
offset = gfc_build_addr_expr (gfc_array_dataptr_type (desc), tmp);
+ if (expr->expr_type == EXPR_VARIABLE && expr->symtree->n.sym->attr.optional)
+{
+ tree present = gfc_conv_expr_present (expr->symtree->n.sym);
+ offset = build3_loc (input_location, COND_EXPR, TREE_TYPE(offset),
+ present, offset,
build_zero_cst(TREE_TYPE(offset)));
+ offset = gfc_evaluate_now (offset, block);
+}
gfc_conv_descriptor_data_set (block, parm, offset);
}
With that, test_wrapper now looks like this:
__attribute__((fn spec (". w ")))
void test_wrapper (real(kind=4)[1] * restrict y)
{
{
struct array01_real(kind=4) parm.5;
real(kind=4)[0:] * restrict D.3980;
struct array01_real(kind=4) * D.3981;
parm.5.span = 4;
parm.5.dtype = {.elem_len=4, .rank=1, .type=3};
parm.5.dim[0].lbound = 1;
parm.5.dim[0].ubound = 1;
parm.5.dim[0].stride = 1;
D.3980 = y != 0B ? (real(kind=4)[0:] * restrict) &(*y)[0] : 0B;
parm.5.data = (void *) D.3980;
parm.5.offset = -1;
D.3981 = y != 0B ? : 0B;
test (D.3981);
}
}
That means y is only dereferenced if it is present, and UBSan does not throw an
error anymore.
This fix seems quite hacky to me with how late it applies, but at least it
highlights the issue well to my mind. I suppose a better, proper fix would
maybe wrap the whole initialization of the array descriptor in a conditional
branch? So that the array descriptor is only assigned if the parameter is not
absent. Perhaps that conditional could surround gfc_conv_expr_descriptor or
even one level higher gfc_conv_array_parameter.
[Bug tree-optimization/101223] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223
Bug ID: 101223
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It also affects GCC 11.*, but not GCC 10.*.
[516] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210626 (experimental) [master revision
2168bfb8144:f9d3bc42803:5b1ce655b25040048861af6c0264cb667b66fcd7] (GCC)
[517] %
[517] % gcctk -O1 small.c; ./a.out
[518] %
[518] % gcctk -Os small.c
[519] % ./a.out
Aborted
[520] %
[520] % cat small.c
struct {
int a : 1;
} b;
int c = 1, d;
int main() {
for (; d < 2; d++) {
int e = ~c, f = 0, g;
if (e) {
f = c;
g = b.a;
b.a = f;
if (b.a >= g)
__builtin_abort();
}
c = f;
b.a = g;
}
return 0;
}
[Bug c++/101222] New: unwanted templated constructor instantiation due to wrong binary operator access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101222
Bug ID: 101222
Summary: unwanted templated constructor instantiation due to
wrong binary operator access
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vopl at bk dot ru
Target Milestone: ---
cat main.cpp && echo EOFF
template struct Trap {};
struct Some
{
template)> Some(T) {}// Trap for T - only
for check if Some was instantiated
};
void operator<(const Some&, const Some&);//wrong instantiatoion of
Some::Some here
enum E{};
int main()
{
bool b = E{} < E{};// wrong access to "bool operator<(const Some&, const
Some&);"
return 0;
}
template <> struct Trap {};// now check Trap for E
EOFF
$ g++ -c main.cpp
main.cpp:17:20: error: specialization of 'Trap' after instantiation
17 | template <> struct Trap {};// now check Trap for E
|^~~
main.cpp:17:20: error: redefinition of 'struct Trap'
main.cpp:1:29: note: previous definition of 'struct Trap'
1 | template struct Trap {};
| ^~~~
-
In these code "void operator<(const Some&, const Some&)" is not a candidate for
overloading for "E{} < E{}", so, it must not be used at all, and as a result,
Some::Some must not be instantiated.
All gcc versions with c++11 standard are affected. Clang and msvc are okay.
[Bug c++/101221] New: Inaccurate error message for wrong template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101221
Bug ID: 101221
Summary: Inaccurate error message for wrong template alias
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Theodore.Papadopoulo at inria dot fr
Target Milestone: ---
Created attachment 51062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51062=edit
Code showing the bug
The attached code produces the following message. The reference of the 'auto'
is at best surprising. Of course the code is wrong but the message is not very
helpful for identifying what is wrong.
mururoa-> g++ --std=c++20 test.C
test.C:16:18: error: ‘auto’ not allowed in alias declaration
16 | using OtherNew = One::AClass;
| ^~~
test.C:23:17: error: ‘auto’ not allowed in alias declaration
23 | using New = One::AClass;
| ^~~
clang does a slightly better job and at least at namespace level explains what
is wrong.
mururoa-> clang++ --std=c++20 test.C
test.C:16:23: error: use of class template 'One::AClass' requires template
arguments
using OtherNew = One::AClass;
^
test.C:4:43: note: template is declared here
template class AClass;
~~~ ^
test.C:23:17: error: no type named 'AClass' in namespace 'One'; did you mean
'BClass'?
using New = One::AClass;
^~~
BClass
test.C:18:7: note: 'BClass' declared here
class BClass {
^
2 errors generated.
[Bug target/101220] New: arm: iwmmxt2: generating bad assembler ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101220
Bug ID: 101220
Summary: arm: iwmmxt2: generating bad assembler ?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C source code:
struct Node FirstNode_t;
struct Node {
int Pi;
int BestPi
} FirstNode() {
FirstNode_t.Pi = FirstNode_t.BestPi = 0;
}
Compiled on a raspberry pi cross compiler like this:
$ /home/dcb/raspberrypi/results/bin/arm-linux-gnueabihf-gcc -c -O3
-march=iwmmxt2 -c bug731.c
does this:
/tmp/cccOc0OE.s: Assembler messages:
/tmp/cccOc0OE.s:25: Error: selected processor does not support `wldrd wr0,.L3'
in ARM mode
/tmp/cccOc0OE.s:28: Error: selected processor does not support `wstrd wr0,[r3]'
in ARM mode
Cross compiler is
$ /home/dcb/raspberrypi/results/bin/arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/raspberrypi/results/bin/arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/dcb/raspberrypi/results/libexec/gcc/arm-linux-gnueabihf/12.0.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /home/dcb/gcc/trunk.git/configure
--prefix=/home/dcb/raspberrypi/results/ --target=arm-linux-gnueabihf
--enable-languages=c,c++,fortran --with-arch=armv6 --with-fpu=vfp
--with-float=hard --disable-multilib --enable-checking=df,extra,fold,rtl,yes
--with-pkgversion=7dcf139a2b8e1c53
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210624 (experimental) (7dcf139a2b8e1c53)
[Bug c++/101219] ice in perform_or_defer_access_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101219
--- Comment #1 from David Binderman ---
Reduced C++ code seems to be:
class PCEFast_PSG {
void UpdateOutput_Noise(int, int *);
};
template void PCEFast_PSGRunChannel() {
void (PCEFast_PSG::*ch_0)(int, int *);
_PSG::UpdateOutput_Noise == ch_0;
}
[Bug c++/101219] New: ice in perform_or_defer_access_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101219 Bug ID: 101219 Summary: ice in perform_or_defer_access_check Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51061=edit gzipped C++ source code For the attached C++ code, recent gcc trunk with flag -Wall does this: /home/dcb/gcc/results.20210626/bin/g++ mednafen/pce_fast/psg.cpp: In member function ‘void PCEFast_PSG::RunChannel(int, int32)’: mednafen/pce_fast/psg.cpp:367:50: internal compiler error: Segmentation fault 0xfd9219 crash_signal(int) ../../trunk.git/gcc/toplev.c:327 0x912bc8 perform_or_defer_access_check(tree_node*, tree_node*, tree_node*, int, access_failure_info*) ../../trunk.git/gcc/cp/semantics.c:490 Code compiled fine with git hash 7dcf139a2b8e1c53, dated two days ago, and goes wrong with 607c558804f70af2, dated yesterday.
[Bug middle-end/101204] infinite recursion in gtype-desc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101204 --- Comment #3 from David Binderman --- If there is some confusion as to which commit caused the problem, I can do a git bisect. Not before Tuesday 19 June. I have quite a few things in my intray right now.
