[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2020-11-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- > I don't get any error on the following constants: 2048, 4095, 4097, 8192. > 4096 seems special! Welcome to the RISC world and its magic integer constants! :-)
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Investigating.
[Bug tree-optimization/96272] Failure to optimize overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96272
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #2)
> Well, it needs the addition too, so I think this can't be done in match.pd,
> but would need to be done in some other pass (not sure which, perhaps
> phiopt?).
Maybe I was not too clear. Please consider this testcase:
--cut here--
#include
#include
int
foo (unsigned a, unsigned b)
{
return a > UINT_MAX - b;
}
int
bar (unsigned a, unsigned b)
{
int dummy;
return __builtin_uadd_overflow (a, b, &dummy);
}
--cut here--
This results in (-O2):
foo:
notl%esi
xorl%eax, %eax
cmpl%edi, %esi
setb%al
ret
bar:
xorl%eax, %eax
addl%esi, %edi
setc%al
ret
So, if it is possible to transform the comparison via the following
equivalence:
a > UINT_MAX - b == (a + b) > UINT_MAX
to a __builtin_uadd_overflow, then at least on x86 it is possible to produce
much better code.
[Bug sanitizer/97941] [HWASAN] use After free not working as per expectation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-11-23 Ever confirmed|0 |1 CC||matmal01 at gcc dot gnu.org Status|UNCONFIRMED |NEW
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #9 from luoxhu at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #6)
> (In reply to luoxhu from comment #4)
> > float foo(float f, float x, float y) {
> > return (fabs(f)*x+y);
> > }
> >
> > the input of fabs is float type, so use fabsf is enough here, drafted a
> > patch to avoid double promotion when generating gimple if fabs could be
> > replaced by fabsf as argument[0] is float type.
>
> what about adding something to match.pd for:
> ABS<(float_convert)f> into (float_convert)ABS
> This is only valid prompting and not reducing the precision.
Thanks, this is already implemented in fold-const.c, though not using match.pd
and fabsf really. fabs will always convert arguments to double type first in
front-end. And there are 3 kind of cases for this issue:
1) "return fabs(x);"
tree
fold_unary_loc (location_t loc, enum tree_code code, tree type, tree op0)
{
...
case ABS_EXPR:
/* Convert fabs((double)float) into (double)fabsf(float). */
if (TREE_CODE (arg0) == NOP_EXPR
&& TREE_CODE (type) == REAL_TYPE)
{
tree targ0 = strip_float_extensions (arg0);
if (targ0 != arg0)
return fold_convert_loc (loc, type,
fold_build1_loc (loc, ABS_EXPR,
TREE_TYPE (targ0),
targ0));
}
return NULL_TREE;
...
}
This piece of code could convert the code from "(float)fabs((double)x)" to
"(float)(double)(float)fabs(x)", then match.pd could remove the useless
convert.
2) "return fabs(x)*y;"
Frontend will generate "(float) (fabs((double) x) * (double) y)" expression
first,
then fold-const.c:fold_unary_loc will Convert fabs((double)float) into
(double)fabsf(float) and get "(float)((double)fabs(x) * (double)y)", finally,
match.pd will convert (outertype)((innertype0)a+(innertype1)b) into
((newtype)a+(newtype)b) to remove the double conversion.
3)"return fabs(x)*y + z;"
Frontend produces: (float) ((fabs((double) float) * (double) y) + (double z))
So what we need here is to match the MUL&ADD in match.pd as followed, any
comments?
+(simplify (convert (plus (mult (convert@3 (abs @0)) (convert@4 @1)) (convert@5
@2)))
+ (if (( flag_unsafe_math_optimizations
+ && types_match (type, float_type_node)
+ && types_match (TREE_TYPE(@0), float_type_node)
+ && types_match (TREE_TYPE(@1), float_type_node)
+ && types_match (TREE_TYPE(@2), float_type_node)
+ && element_precision (TREE_TYPE(@3)) > element_precision (TREE_TYPE
(@0))
+ && element_precision (TREE_TYPE(@4)) > element_precision (TREE_TYPE
(@1))
+ && element_precision (TREE_TYPE(@5)) > element_precision (TREE_TYPE
(@2))
+ && ! HONOR_NANS (type)
+ && ! HONOR_INFINITIES (type)))
+ (plus (mult (abs @0) @1) @2) ))
+
1) and 2) won't generate double conversion, only 3) has frsp in fast-math mode,
and it could be removed by above pattern.
PS: convert_to_real_1 seems to me not quite related here? It converts
(float)sqrt((double)x) where x is float into sqrtf(x), but with recursive call
to convert_to_real_1 and build_call_expr with new mathfn_built_in, I suppose it
a bit complicated to move them to match.pd?
The optimization should be under fast-math mode, is
flag_unsafe_math_optimizations enough to guard them?
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #10 from luoxhu at gcc dot gnu.org --- Even we could optimize fabs to fabsf, it doesn't help here as y and z are already promoted to double, then we still need a large pattern to match the MUL&PLUS expression in match.pd, so fabs to fabsf seems not a reasonable direction...
[Bug tree-optimization/97904] ICE with AArch64 SVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97904 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:d3585f5d0df47ffa453f5fe436fdf588301e5314 commit r11-5243-gd3585f5d0df47ffa453f5fe436fdf588301e5314 Author: Richard Sandiford Date: Mon Nov 23 09:06:59 2020 + c++: Add missing verify_type_context call [PR97904] When adding the verify_type_context target hook, I'd missed a site that needs to check an array element type. gcc/cp/ PR c++/97904 * pt.c (tsubst): Use verify_type_context to check the type of an array element. gcc/testsuite/ PR c++/97904 * g++.dg/ext/sve-sizeless-1.C: Add more template tests. * g++.dg/ext/sve-sizeless-2.C: Likewise.
[Bug c++/97942] New: [C++20][P0692R1] Access checking not waived for declarations of explicit specializations of function and variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97942
Bug ID: 97942
Summary: [C++20][P0692R1] Access checking not waived for
declarations of explicit specializations of function
and variable templates
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: davveston at gmail dot com
Target Milestone: ---
[temp.spec]/6[1] was added to the C++20 spec by implementation of P0692R1[2]:
"The usual access checking rules do not apply to names in a declaration of an
explicit instantiation or explicit specialization, with the exception of names
appearing in a function body, default argument, base-clause,
member-specification, enumerator-list, or static data member or variable
template initializer."
Meaning that programs (A) through (C) below are (arguably) well-formed:
(A) (DEMO: https://wandbox.org/permlink/No9RdUGRQFinIPie)
class A { class B {}; };
template struct S {};
template<> struct S {};
int main() {}
(B) (DEMO: https://wandbox.org/permlink/Ki1iLlje2raKJoEb):
class A { class B {}; };
template void foo() {};
template<> void foo() {}
int main() {}
(C) (DEMO: https://wandbox.org/permlink/AN06msZgJNmxB0HS)
class A { class B {}; };
template
constexpr bool v = false;
template<>
constexpr bool v = true;
int main() {}
However whilst GCC accepts (A), it rejects (B) and (C).
> (gcc HEAD 11.0.0 20201121 (experimental))
> g++ prog.cc -Wall -Wextra -std=c++2a
> error: 'class A::B' is private within this context
As per [3], P0692R1 has been implemented in GCC ("Available in GCC: Yes").
---
References
[1] https://timsong-cpp.github.io/cppwp/n4861/temp.spec#6
[2] P0692R1 - Access Checking on Specializations
http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0692r1.html)
[3] https://gcc.gnu.org/projects/cxx-status.html
[Bug middle-end/97943] New: [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943
Bug ID: 97943
Summary: [11 Regression] ICE with __builtin_clear_padding on
flexible array member
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
struct S { int a; char b[] __attribute__((aligned (2 * sizeof (int; };
void
foo (struct S *u)
{
__builtin_clear_padding (u);
}
ICEs starting with the __builtin_clear_padding implementation
r11-5196-g1bea0d0aa5936cb36b6f86f721ca03c1a1bb601d
Avoiding the ICE is easy, e.g.
--- gcc/gimple-fold.c.jj2020-11-20 12:28:10.102680956 +0100
+++ gcc/gimple-fold.c 2020-11-22 21:54:39.527918551 +0100
@@ -4439,6 +4439,12 @@ clear_padding_type (clear_padding_struct
}
}
}
+ else if (DECL_SIZE_UNIT (field) == NULL_TREE)
+ {
+ gcc_assert (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
+ && !COMPLETE_TYPE_P (TREE_TYPE (field)));
+ /* Flexible array member. Consider it all padding. */
+ }
else
{
HOST_WIDE_INT pos = int_byte_position (field);
the important question is what behavior we want in that case.
The above patch will make all the bits in the tail padding starting with the
address of the flexible array member till the end of the type in question
padding bits (plus the padding before the flexible array member but that is not
questionable).
The problem with that is that if the object does contain any flexible array
members, __builtin_clear_padding could then clear even the value representation
of those array elements.
Another approach would be to consider that the flexible array member contains
as many elements as can (even partially) fit into the type bounds.
So e.g. if we have:
struct S { char a; short b; char c; };
struct T { char a; struct S b __attribute__((aligned (32))); S c[]; };
the padding mask (0 for padding, 1 for unmodified value) for struct S is 0xff,
0, 0xff, 0xff, 0xff, 0
and for T it would be 0xff, 31x 0, (now is b field) 0xff, 0, 0xff, 0xff, 0xff,
0,
(now starts the flex array member and we 32-6 bytes in the tail padding), so we
repeat 0xff, 0, 0xff, 0xff, 0xff, 0 there 4 times (that fits in full) and then
0xff, 0 (first two bytes of the element that would cross the size of the T type
we were passed pointer to).
Thoughts on this?
If we go the latter route, there are complications on what to do if a structure
with flexible array member is embedded into other structures or unions.
And in those it can go either in places where it is followed by other fields,
or no real fields after it.
So given the above struct S and T, if we have:
struct U { char a __attribute__((aligned (128))); struct T b; };
U's size is 256 bytes, would the padding be 0xff, 127x 0, then for T
0xff, 31x 0, then 16x ( 0xff, 0, 0xff, 0xff, 0xff, 0 ) , i.e. as if c[] was
actually c[15] in this case?
If there are fields after it, instead consider only what is the largest number
that would fit in before that next field without partial elements?
For the implementation, we'd probably need to pass down the size of the padding
before the next element (if any), or end of the type and for the flexible array
members compute from there how many elements and whether full or partial one
can fit. If there following fields are bitfields, I have no idea, though I'd
say the elements shouldn't cross even unnamed bitfields.
struct V { struct T a; int : 30; int c : 2; };
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 CC||redi at gcc dot gnu.org, ||rodgertq at gcc dot gnu.org Last reconfirmed||2020-11-23
[Bug debug/63572] [8/9/10/11 Regression] ICF breaks user debugging experience
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572
Richard Biener changed:
What|Removed |Added
Priority|P4 |P2
--- Comment #25 from Richard Biener ---
(In reply to Jan Hubicka from comment #24)
> *** Bug 97937 has been marked as a duplicate of this bug. ***
Testcase from the bug. The thing is after ICFing test and test2 we still
emit the very same code as when not doing ICF but the only effect is
no debug info for test1.
int test(void)
{
return 0;
}
int test1(void)
{
return 0;
}
struct s {
int (*x) (void);
int (*y) (void);
};
struct s xxx = { test, test1 };
[Bug debug/63572] [8/9/10/11 Regression] ICF breaks user debugging experience
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572 --- Comment #26 from Jakub Jelinek --- Bet we ICF and then inline it back into the "thunk".
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 --- Comment #1 from Richard Biener --- I think the only viable route is to _not_ clear the "padding" covered by flexarray members. We may never ever clear actual values and they, as you say, could be actual values. But ... can we even do a atomic operation on such "incomplete" type? So, isn't there a complete type w/o flexarray always available? So ... sorry () here and reject an attempt to clear padding in an incomplete type? Which raises the question what to do for the real-world case which won't use char b[] since that's not C++ but would use char b[1] ...
[Bug libstdc++/97944] New: 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 Bug ID: 97944 Summary: 30_threads/jthread/95989.cc fails randomly Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since this new test was introduced, it fails randomly on arm, aarch64 and other targets (apparently powerpc, ia64, m68k according to gcc-testresults). The logs say: terminate called after throwing an instance of 'std::system_error' what(): Unknown error -8461584
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 --- Comment #15 from SRINATH PARVATHANENI --- (In reply to Bernd Edlinger from comment #14) > fixed on trunk. Thanks Bernd for fixing this on trunk, would you mind backporting this to GCC-10 as well? Thanks you. Regards, Srinath.
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 --- Comment #2 from Richard Biener --- (In reply to Richard Biener from comment #1) > I think the only viable route is to _not_ clear the "padding" covered by > flexarray members. We may never ever clear actual values and they, as you > say, > could be actual values. > > But ... can we even do a atomic operation on such "incomplete" type? So, > isn't there a complete type w/o flexarray always available? > > So ... sorry () here and reject an attempt to clear padding in an incomplete > type? > > Which raises the question what to do for the real-world case which won't > use char b[] since that's not C++ but would use char b[1] ... To answer my own question, array_at_struct_end_p () covered padding must not be cleared.
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
(In reply to Richard Biener from comment #2)
> > Which raises the question what to do for the real-world case which won't
> > use char b[] since that's not C++ but would use char b[1] ...
>
> To answer my own question, array_at_struct_end_p () covered padding must not
> be cleared.
If we do that, we'll violate C++20 I'd think.
For flexible array members we can choose what exactly we want to do, because we
are outside of the standard. But when one uses:
#include
struct S { char a; short b; };
struct T { char a; char b alignas (32); S c[1]; };
std::atomic t;
then we can't pretend one can store meaningful values in c[3].b and expect it
to work.
[Bug ipa/97945] New: undefined reference err when a function defined inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97945
Bug ID: 97945
Summary: undefined reference err when a function defined inline
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: dongjianqiang2 at huawei dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ cat z1.c
#define likely(x) __builtin_expect((x), 1)
#define unlikely(x) __builtin_expect((x), 0)
int a=10;
inline void test() {
__builtin_puts("hot");
a++;
__builtin_puts("hot");
}
void main() {
__builtin_puts("hot");
if (unlikely(a==2)) {
test();
}
__builtin_puts("hot");
}
gcc test.c -O2
in function `main':
test.c:(.text.startup+0x38): undefined reference to `test'
collect2: error: ld returned 1 exit status
But succeed when compiling with -fgnu89-inline.
[Bug libstdc++/58929] condition_variable does not wait without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #11 from Jonathan Wakely --- (In reply to Victor Mataré from comment #10) > OK, thanks for the clarification. But I feel I need to point out that that's > just a huge WTF. How is a C++ dev supposed to know from the standard docs > they work with all day that a condition_variable has any relation to > libpthread? You're not compiling with the standard, you're using GCC. The requirement to use libpthread is documented by the implementation (although it could be easier to find): https://gcc.gnu.org/onlinedocs/libstdc++/manual/using.html#manual.intro.using.flags
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-11-23 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug c/97945] undefined reference err when a function defined inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97945 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED Component|ipa |c CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is a user error. The C99 and later standards mandate this behavior. Either use static inline, or in one TU you need to use extern inline, or use the GNU inline semantics.
[Bug libstdc++/97362] [8/9/10 Regression] `__deref` in in debug mode clashes with internal macro in Windows system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #7 from Jonathan Wakely --- ping
[Bug c++/97946] New: passing templated function without template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97946
Bug ID: 97946
Summary: passing templated function without template argument
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: niklas at nolte dot dev
Target Milestone: ---
The compiler accepts the following code.
`fun` without template arguments should not be accepted, should it?
```
template
void fun() {}
template
void higher_order_fun( const F & f) {
f();
}
int main () {
//higher_order_fun(fun<>); //works
higher_order_fun(fun);
}
```
The related stackoverflow question:
https://stackoverflow.com/questions/64872397/passing-function-template-prototype-as-argument
[Bug libgcc/89714] allow for overriding the thread-detection mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714 --- Comment #2 from Jonathan Wakely --- -D_GLIBCXX_GTHREAD_USE_WEAK=0 appears to work, but is not officially supported. It also only affects the code in the libstdc++ headers, not the code inside libstdc++.so that checks __gthread_active_p.
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #11 from rguenther at suse dot de --- On Mon, 23 Nov 2020, luoxhu at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 > > --- Comment #10 from luoxhu at gcc dot gnu.org --- > Even we could optimize fabs to fabsf, it doesn't help here as y and z are > already promoted to double, then we still need a large pattern to match the > MUL&PLUS expression in match.pd, so fabs to fabsf seems not a reasonable > direction... The larger expressions should be subject to a propagation pass and not arbitrarily complex static pattern matching. Maybe backprop is a suitable one to wire this in.
[Bug c++/97947] New: [11 Regression] ICE in digest_init_r, at cp/typeck2.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947
Bug ID: 97947
Summary: [11 Regression] ICE in digest_init_r, at
cp/typeck2.c:1145
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-11.0.0-alpha20201122 snapshot (g:e23f47ec4065e9eec53c4ad9db91bc36a4f90793)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/powerpc/mma-builtin-2.c:
void
x1 (__vector_pair *ur)
{
__vector_pair dd = *ur;
}
% powerpc-e300c3-linux-gnu-g++-11.0.0 -c lv5swte0.c
lv5swte0.c: In function 'void x1(__vector_pair*)':
lv5swte0.c:4:23: internal compiler error: in digest_init_r, at
cp/typeck2.c:1145
4 | __vector_pair dd = *ur;
| ^~
0x69162f digest_init_r
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/typeck2.c:1145
0xae37ed store_init_value(tree_node*, tree_node*, vec**, int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/typeck2.c:729
0x930ab0 check_initializer
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/decl.c:6923
0x956e52 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/decl.c:7841
0xa0b1e7 cp_parser_init_declarator
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:21380
0x9e7801 cp_parser_simple_declaration
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:13962
0xa053da cp_parser_declaration_statement
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:13362
0x9e97b4 cp_parser_statement
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:11586
0x9ea902 cp_parser_statement_seq_opt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:11952
0x9ea9e0 cp_parser_compound_statement
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:11902
0xa0554f cp_parser_function_body
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:23569
0xa0554f cp_parser_ctor_initializer_opt_and_function_body
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:23620
0xa0a360 cp_parser_function_definition_after_declarator
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:29510
0xa0b7ed cp_parser_function_definition_from_specifiers_and_declarator
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:29426
0xa0b7ed cp_parser_init_declarator
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:21142
0x9e7801 cp_parser_simple_declaration
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:13962
0xa15e84 cp_parser_declaration
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:13659
0xa16730 cp_parser_translation_unit
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:4806
0xa16730 c_parse_file()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:44613
0xb46fb9 c_common_parse_file()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/c-family/c-opts.c:1198
[Bug libstdc++/97948] New: C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 Bug ID: 97948 Summary: C++2a synchronization tests fail to link on arm Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- These new tests fails to link on arm: 29_atomics/atomic_float/wait_notify.cc (test for excess errors) 29_atomics/atomic_integral/wait_notify.cc (test for excess errors) 29_atomics/atomic_ref/wait_notify.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `void std::__atomic_impl::store(double*, std::remove_volatile::type, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `void std::__atomic_impl::store(double*, std::remove_volatile::type, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `void std::__atomic_impl::store(double*, std::remove_volatile::type, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' collect2: error: ld returned 1 exit status This happens for instance with arm-none-linux-gnueabi-gcc and compiling with -march=armv5t
[Bug libstdc++/97949] New: Recursive calls of std::call_once together with cout leads to deadlock under mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949
Bug ID: 97949
Summary: Recursive calls of std::call_once together with cout
leads to deadlock under mingw64
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-w64-mingw32.static
The following code locks under Windows 10:
-
#include
#include
#include
#include
std::once_flag flag0;
std::once_flag flag1;
void innerDoOnce()
{
std::call_once(flag0, []() {
using namespace std::chrono_literals;
std::cout << "innerDoOnce() called...\n";
std::this_thread::sleep_for(1s);
});
}
void outerDoOnce()
{
std::call_once(flag1, []() {
std::cout << "outerDoOnce() called...\n";
innerDoOnce();
});
}
int main()
{
std::thread t0(innerDoOnce);
std::thread t1(innerDoOnce);
std::thread t2(outerDoOnce);
std::thread t3(outerDoOnce);
t0.join();
t1.join();
t2.join();
t3.join();
std::cout << "aggi\n";
}
-
Removing the `std::cout` calls seems to make the issue go away.
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 Christophe Lyon changed: What|Removed |Added Version|11.0|10.2.1 --- Comment #1 from Christophe Lyon --- This is also affects gcc-10
[Bug ipa/96734] gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734
--- Comment #10 from Martin Liška ---
All right, I have a reduced test-case (with the failing stage1 compiler):
$ cat method.ii
typedef union tree_node *tree;
struct tree_typed {
tree type;
};
struct tree_type_non_common {
tree lang_1;
};
union tree_node {
tree_typed typed;
tree_type_non_common type_non_common;
};
;
struct comp_info {
bool noex;
comp_info(tree fndecl, int ) {
if (noex) {
if ((fndecl)->typed.type)))->type_non_common.lang_1) )
noex = false;
}
}
};
tree build_comparison_op_fndecl;
int build_comparison_op_complain;
void synthesize_method() {
{
{
comp_info (build_comparison_op_fndecl, build_comparison_op_complain);
}
}
}
[Bug libstdc++/80992] libstdc++ cross-build on solaris is missing GCC_CHECK_TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80992 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-23 Ever confirmed|0 |1
[Bug libstdc++/80992] libstdc++ cross-build on solaris is missing GCC_CHECK_TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80992 --- Comment #1 from Jonathan Wakely --- I think crossconfig.m4 for mingw32* should use GCC_CHECK_TLS too.
[Bug libgcc/89714] allow for overriding the thread-detection mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714 --- Comment #3 from Thomas Neumann --- Perhaps the header files could be changed to react to _REENTRANT, as that seems to be the define that is set by gcc when requesting threading support. The redundant checks within the shared library are less of an issue. Of course they waste a few cycles, too, but the unnecessary checks in the header files are far worse as they are inlined all over the place when using, e.g., shared_ptr.
[Bug sanitizer/97941] [HWASAN] use After free not working as per expectation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941
--- Comment #1 from Matthew Malcomson ---
Hi Akhilesh,
No that's certainly not a known issue -- thanks for reporting it!
I'm having trouble reproducing your issue, do you mind giving a little more
information on your command line and the machine you're running on etc?
One point that seems worth looking into is that the line numbers on your
backtrace don't seem to match up with the line numbers in my source tree.
(e.g. GetAccessInfo is given line number 383 of hwasan_linux.cpp, while in my
source tree that function spans lines 328-376). Have you made any
modifications to the source? Or maybe you're running a different libsanitizer
version?
For reference I'm using libsanitizer from LLVM hash
6e7dd1e3e1170080b76b5dcc5716bdd974343233, and the sha256sum of hwasan_linux.cpp
in my source tree is
3986e9f4e519409e7c73a7b97722125300afc4dc1f44a3f966fedf679329fd0a.
Based on what line number `HwasanOnSIGTRAP` calls `GetAccessInfo` in my source
tree, and assuming the offset between our line numbers are the same for the
GetAccessInfo line in your stack trace, it seems that the SEGV happens when
dereferencing the address that caused the signal.
That value should be the address of the `brk` instruction in __hwasan_load1
(having been inlined from `SigTrap` in hwasan_checks.h) which caught the bad
access, but the value of 0x30 which caused this SEGV is clearly not that value.
If the offset between our line numbers is a bit different, then getting that
address might make a bit more sense. There are various struct member accesses
via pointers that `GetAccessInfo` recieves.
However, those arguments are just taken from the siginfo_t and ucontext_t
pointers that the kernel provides on receipt of a deadly signal.
I haven't found any access in that function which look like they would have an
offset of 0x30 from a NULL pointer, although I guess different kernel versions
would have different offsets.
What kernel are you running on? Is there any chance the signal handler
HwasanOnDeadlySignal is getting a NULL pointer as one of its arguments?
For reference I happen to be running on a linux kernel based off of commit
585e5b17b9 (but with some modifications that should not affect anything -- just
config changes so I can build the kernel itself with -fsanitize=hwaddress).
Just for reference -- what I see when compiling your testcase:
ubuntu@ubuntu:~/working-directory/temp/pr97941$
../../gcc-hwasan-install/bin/gcc -fsanitize=hwaddress ./test.c -o test
./test.c: In function ‘main’:
./test.c:2:20: warning: implicit declaration of function ‘malloc’
[-Wimplicit-function-declaration]
2 | char *x = (char*)malloc(10 * sizeof(char*));
|^~
./test.c:1:1: note: include ‘’ or provide a declaration of ‘malloc’
+++ |+#include
1 | int main() {
./test.c:2:20: warning: incompatible implicit declaration of built-in function
‘malloc’ [-Wbuiltin-declaration-mismatch]
2 | char *x = (char*)malloc(10 * sizeof(char*));
|^~
./test.c:2:20: note: include ‘’ or provide a declaration of ‘malloc’
./test.c:3:3: warning: implicit declaration of function ‘free’
[-Wimplicit-function-declaration]
3 | free(x);
| ^~~~
./test.c:3:3: note: include ‘’ or provide a declaration of ‘free’
./test.c:3:3: warning: incompatible implicit declaration of built-in function
‘free’ [-Wbuiltin-declaration-mismatch]
./test.c:3:3: note: include ‘’ or provide a declaration of ‘free’
ubuntu@ubuntu:~/working-directory/temp/pr97941$
LD_LIBRARY_PATH=~/working-directory/gcc-hwasan-install/lib64 ./test
==8600==ERROR: HWAddressSanitizer: tag-mismatch on address 0xefe00005 at pc
0xa828be70
READ of size 1 at 0xefe00005 tags: e2/d5 (ptr/mem) in thread T0
#0 0xa828be6c in SigTrap<0>
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:27
#1 0xa828be6c in CheckAddress<(__hwasan::ErrorAction)0,
(__hwasan::AccessType)0, 0>
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:88
#2 0xa828be6c in __hwasan_load1
../../../../gcc-source/libsanitizer/hwasan/hwasan.cpp:375
#3 0x400944 in main
(/home/ubuntu/working-directory/temp/pr97941/test+0x400944)
#4 0xa81598dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)
[0xefe0,0xefe00060) is a small unallocated heap chunk; size: 96
offset: 5
0xefe00005 is located 5 bytes inside of 80-byte region
[0xefe0,0xefe00050)
freed by thread T0 here:
#0 0xa828d64c in __sanitizer_free
../../../../gcc-source/libsanitizer/hwasan/hwasan_interceptors.cpp:108
#1 0x400934 in main
(/home/ubuntu/working-directory/temp/pr97941/test+0x400934)
#2 0xa81598dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)
#3 0x400814 (/home/ubuntu/working-directory/temp/pr97941/test+0x400814)
previously allocated here:
#0 0xa828db30 in __sanitizer_malloc
../../../../gcc-source/libsanitizer/hwasan/hwasan
[Bug libstdc++/87679] std::this_thread::sleep_until sleeps too much for clocks faster than system_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87679 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-23 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- A faster clock can be considered to be constantly being adjusted slightly forwards, which means this wording from the standard applies: Recommended practice: Implementations should decrease the duration of the wait when the clock is adjusted forwards. I'm not really sure how to do that other than sleeping for smaller durations, so that we keep waking up to see if the time has been reached. That adds overhead due to the extra calls to the _Clock::now() function. We could do something like sleep for a maximum for N seconds when using a user-defined clock. For very small durations we wouldn't bother, and so there wouldn't be extra overhead. For longer durations, we'd periodically wake up and recheck the time.
[Bug libstdc++/97948] C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 --- Comment #1 from Andreas Schwab --- See also PR81358.
[Bug libstdc++/94996] jthread should stop and join the associated thread before being assigned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94996 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.3 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- Fixed by g:08b4d325711d5c6f68ac29443aba3fd7aa173ac8 and g:7c44b67d83b34e56a4f65afd70754c5e30280247
[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.0 Status|NEW |RESOLVED --- Comment #9 from Jonathan Wakely --- This was fixed in gcc-9 by the patch for PR libstdc++/67843
[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67116 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Jonathan Wakely --- (In reply to Cezary Śliwa from comment #6) > Created attachment 36131 [details] > config.log > > libstdc++v3 config.log This shows: CXX=' x86_64-w64-mingw32-c++ -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/mingw/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/mingw/include ' CXXCPP=' x86_64-w64-mingw32-c++ -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/mingw/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/mingw/include-E' That means you're building libstdc++ with the wrong compiler.
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-23 CC||redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Jonathan Wakely --- (In reply to Ben Longbons from comment #5) > I just hit this in my testsuite, and it's worse than described for the > dynamic case: > > if libpthread.so is dlopen'ed after libstdc++, __gthread_active_p() will > *not* become true - weak symbols are not rebound. The problem isn't that weak symbols are not rebound (they are), it's that __gthread_active_p stores the result of the first check in a static variable which is initialized once and then it's value doesn't change: static void *const __gthread_active_ptr = __extension__ (void *) >HR_ACTIVE_PROXY; > Note that plugins that indirectly pull in pthreads are very common in the > wild. At the time of writing, the main executable needs to link to libpthread, not just the plugins. Otherwise libstdc++ won't work. Glibc also has a history of bugs with libpthread only being loaded via dlopen. > Further, LD_PRELOAD=libpthread.so.0 does NOT help. > > Thus, all C++ locks will do nothing despite the presence of multiple > threads. Correct code will experience race conditions. > > Do note that, nowadays, all of the *other* symbols you're making weak are in > libc.so (for GLIBC at least, which AFAIK is the only dlopen'able pthread > implementation) I don't think that's true at all. It's planned for a future version of glibc though, see https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00080.html When that happens, __gthread_active_p will always be true for glibc (and the weak symbols won't be needed anyway).
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 --- Comment #4 from Jakub Jelinek --- BTW, for all the 3 cases __builtin_clear_padding will be called on, i.e. the constructor of std::atomic for the type, the desired argument passed by value and the expected argument, which while it is passed by value is also stored by the implementation (copied from the atomic memory), one can't effectively have any flexible (or poor man's flexible) array members except those that fit into the tail padding of the structures. So in many cases nothing at all. So for the flexible array members, if we don't sorry on them, we could also clear the tail padding spot for partial elements, because one really can't have there half of an element.
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 --- Comment #5 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #4) > value and the expected argument, which while it is passed by value is also Sorry, meant passed by reference.
[Bug tree-optimization/97950] New: Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950
Bug ID: 97950
Summary: Unoptimal code generation with
__builtin_*_overflow{,_p} for short and __int128
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For the following code, the generation is unoptimal on x86-64.
For most of the functions with `short` a jump is generated.
For the functions with `__int128` all but `mul_overflow_{,un}signed___int128`
seems to have extra `mov` produced.
The same problems apply to all the `__builtin_*_overflow_p`
-
#define TEST_OVERFLOW(type) \
bool mul_overflow_signed_##type(signed type a, signed type b, signed type c)
{return __builtin_mul_overflow(a,b,&c);} \
bool add_overflow_signed_##type(signed type a, signed type b, signed type c)
{return __builtin_add_overflow(a,b,&c);} \
bool sub_overflow_signed_##type(signed type a, signed type b, signed type c)
{return __builtin_sub_overflow(a,b,&c);} \
bool mul_overflow_unsigned_##type(unsigned type a, unsigned type b, unsigned
type c) {return __builtin_mul_overflow(a,b,&c);} \
bool add_overflow_unsigned_##type(unsigned type a, unsigned type b, unsigned
type c) {return __builtin_add_overflow(a,b,&c);} \
bool sub_overflow_unsigned_##type(unsigned type a, unsigned type b, unsigned
type c) {return __builtin_sub_overflow(a,b,&c);} \
TEST_OVERFLOW(short)
TEST_OVERFLOW(__int128)
-
[Bug libstdc++/60662] simple use of call_once throws a system_error exception, but not if sleep_for is called beforehand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |11.0 --- Comment #5 from Jonathan Wakely --- I am able to reproduce this on Ubuntu 13.10, and it can be fixed by using -Wl,--no-as-needed before -lpthread which ensures the executable is linked to libpthread.so even though the linker thinks it's not needed. I'm not sure why this_thread::sleep_for (which just calls nanosleep) causes libpthread.so to get linked in, but ldd shows that there is a libpthread.so dependency with it. This should be fixed in GCC 11 which no longer uses pthread_once for std::call_once.
[Bug libstdc++/67791] Crash using std::thread and iostream with dynamic loading of a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-11-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #7 from Jonathan Wakely --- (In reply to nexyon from comment #4) > Thanks for the quick responses! I already expected some sort of side effect > like this. Maybe it's possible to reevaluate whether pthread is linked or > not during the first use of std::thread? No, because the result is cached in a static const variable, which can't be changed after its first use. > In any case std::thread should not > crash I guess, so just to fix that it would be necessary to check whether > the standard library was inizialized without threads. We used to check for the pthread_create weak symbol, and throw an exception instead of crashing. Since the fix for PR libstdc++/61841 we don't check it, and crash instead of throwing. That should be fixed. > Or shouldn't there be > locks in any case? What if another threading library is used but pthreads, > that libstdc++ is not expecting? (Not sure though, how practical that is, or > how likely that's going to happen) That's not supported. The only supported way to create new threads is via pthreads. > As the problem seems to be known, I wonder if I can expect this to be solved > any time soon? For now I guess my options are to tell the users of my > library and it's plugins to always link pthread to their main program or Right. > maybe artificially add a function in my library that uses std::thread so > that my library gets linked against pthread. Then linking dynamically with > it in the executable should not cause problems, only symloading the library > would still cause the same problem. Or do you have other ideas? If the main executable is not linked to libpthread, using dlopen to load a library that depends on libpthread doesn't work. This is currently unsupported, and unsupportable on GNU/Linux. If your library depends on libpthread.so and the main executable links to your library that should be fine. You don't need to use std::thread for that, just link to it without using --as-needed e.g. -Wl,--no-as-needed -lpthread -Wl,--as-needed Late-loading of libpthread.so via dlopen should start working with a future version of glibc, when this is implemented: https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00080.html
[Bug c++/97951] New: Template specialization of function template fails for fixed-sized SVE vector types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97951
Bug ID: 97951
Summary: Template specialization of function template fails for
fixed-sized SVE vector types.
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.tellenbach at arm dot com
Target Milestone: ---
Following the ACLE for SVE Version 00bet6, fixed-length types can be declared
by using the
__attribute__((arm_sve_vector_bits(N)))
type attribute. However, the following snippet fails using g++-10 (Ubuntu
10.1.0-2ubuntu1~18.04) 10.1.0:
g++-10 -march=armv8-a+sve -msve-vector-bits=512 main.cc -c
main.cc:
#include
typedef svfloat32_t PacketXf __attribute__((arm_sve_vector_bits(512)));
template
T func(const float& f)
{
return f;
}
template<>
PacketXf func(const float& f)
{
return svdup_n_f32(f);
}
producing the following diagnostics:
main.cc:9:10: error: template-id 'func<>' for 'PacketXf func(const float&)'
does not match any template declaration
9 | PacketXf func(const float& f) { return svdup_n_f32(f); }
| ^~~~
main.cc:6:3: note: candidate is: 'template T func(const float&)'
6 | T func(const float& f) { return f; }
| ^~~~
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
--- Comment #7 from Petr Sumbera ---
Just to confirm that '-fno-delayed-branch' as workaround seems to work (at
least based on provided test case).
Probably better is to modify the code like this:
--- gcc-10.2.0/gcc/config/sparc/sparc.c
+++ gcc-10.2.0/gcc/config/sparc/sparc.c
@@ -3963,6 +3963,8 @@
if ((TARGET_GNU_TLS && HAVE_GNU_LD) || !TARGET_TLS)
return 1;
+ return 0;
+
pat = PATTERN (trial);
/* We must reject tgd_add{32|64}, i.e.
---
Of course proper fix is needed. Any suggestion to the condition (in code)
below?
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 --- Comment #8 from Eric Botcazou --- Sorry for dropping the ball, I'll get back to it momentarily.
[Bug c++/97952] New: Poor optimization of closure-like construct in C++ as compared to C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97952 Bug ID: 97952 Summary: Poor optimization of closure-like construct in C++ as compared to C Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric-gcc at omnifarious dot org Target Milestone: --- This code generates about 400+ lines of assembly: https://gcc.godbolt.org/z/s9s9Mx and this essentially equivalent C code generates only 100+ lines: https://gcc.godbolt.org/z/5abWEe This seems like poor optimization in C++. The C code makes use of nested functions, a GCC specific feature. And the C++ code uses a class to simulate a closure, thereby accomplishing essentially the same goal.
[Bug c++/97952] Poor optimization of closure-like construct in C++ as compared to C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97952
--- Comment #1 from eric-gcc at omnifarious dot org ---
Because you might not like Godbolt links, here is the C code:
//---cut here---
/*** core string search routine ***/
typedef char *String;
typedef unsigned longIndex, Count, Size, Length, Limit, Extent, Mask, Bits;
typedef struct {
const String string;
const Length length;
const Index *const table;
} SearchString_data;
typedef SearchString_data *SearchString, SearchString_object[1];
enum {
IAC = (char) 255,
WILL= (char) 251,
WONT= (char) 252,
DO = (char) 253,
DONT= (char) 254,
};
static Length command_length( String s, String sn );
static Length command_length_unknown( String s, String sn );
String
skip_past( String input, String sn, SearchString ss ){
const Index *walkback = ss->table;
const Index kn = ss->length;
const String w= ss->string;
typedef String Skip_f( String, Index );
auto Skip_f
skip_zero, skip_one_half, skip_one,
command_skip_zero, command_skip,skip;
return skip_zero( input, 0 );
String
skip_zero( String s, Index k ){
return k == kn ? s : skip_one_half( s, k );
}
String
skip_one_half( String s, Index k ){
return s == sn ? 0 : skip_one( s, k );
}
String
skip_one( String s, Index k ){
return 0[s] == IAC ? command_skip_zero( s+1, k ) : skip( s, k );
}
String
command_skip_zero( String s, Index k ){
return s == sn ? 0
: 0[s] != IAC ? command_skip( s, k )
: /** IAC IAC **/skip( s, k );
}
String
command_skip( String s, Index k ){
Count m = command_length( s, sn );
Count n = sn - s;
return m > n ? 0 : skip_one_half( s+m, k );
}
String
skip( String s, Index k ){
return 0[s] == w[k]? skip_zero( s+1, k+1 )
: k == 0 ? skip_one_half( s+1, 0 )
: /** !=, k > 0 **/ skip( s, walkback[k] );
}
}
Length
command_length( String s, String sn ){
return *s == IAC ? 1
: *s == WILL ? 2
: *s == WONT ? 2
: *s == DO? 2
: *s == DONT ? 2
: /*** otherwise ***/command_length_unknown( s, sn )
;
}
Length
command_length_unknown( String s, String sn ){
return 1; // TBD - is there something better here?
}
//---cut here---
and here is the C++ code:
//---cut here---
/*** core string search routine ***/
typedef char *String;
typedef unsigned longIndex, Count, Size, Length, Limit, Extent, Mask, Bits;
typedef struct {
const String string;
const Length length;
const Index *const table;
} SearchString_data;
typedef SearchString_data *SearchString, SearchString_object[1];
enum : char {
IAC = (char) 255,
WILL= (char) 251,
WONT= (char) 252,
DO = (char) 253,
DONT= (char) 254,
};
static Length command_length( String s, String sn );
static Length command_length_unknown( String s, String sn );
String
skip_past3( String input, String sn, SearchString ss ) {
class search_closure {
public:
search_closure( String input, String sn, SearchString ss )
: input(input), sn(sn), ss(ss),
walkback(ss->table), kn(ss->length), w(ss->string)
{}
String operator ()() const { return skip_zero( input, 0); }
private:
const String input;
const String sn;
const SearchString ss;
const Index *walkback;
const Index kn;
const String w;
String
skip_zero( String s, Index k ) const {
return k == kn ? s : skip_one_half( s, k );
}
String
skip_one_half( String s, Index k ) const {
return s == sn ? 0 : skip_one( s, k );
}
String
skip_one( String s, Index k ) const {
return 0[s] == IAC ? command_skip_zero( s+1, k ) : skip( s, k );
}
String
command_skip_zero( String s, Index k ) const {
return s == sn ? 0
: 0[s] != IAC ? command_skip( s, k )
: /** IAC IAC **/skip( s, k );
}
String
command_skip( String s, Index k ) const {
Count m = command_length( s, sn );
Count n = sn - s;
return m > n ? 0 : skip_one_half( s+m, k );
}
String
skip( String s, Index k ) const {
return 0[s] == w[k]? skip_zero( s+1, k+1 )
: k == 0 ? skip_one_half( s+1, 0 )
: /** !=, k > 0 **/ skip( s, walkba
[Bug target/97928] -fstack-clash-protection probe miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97928 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- @Jeff: Can you please take a look?
[Bug target/97940] [11 Regression] ICE: in extract_insn, at recog.c:2306 (error: impossible constraint in 'asm'; error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97940
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Keywords||error-recovery
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
The test has
/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
so it isn't meant for other arches, uses x86 specific constraints.
So this is just an IRA error recovery ICE on random garbage code.
[Bug c/97953] New: ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
Bug ID: 97953
Summary: ICE (segfault) during GIMPLE pass: loopdone compiling
libgcc/config/libbid/bid128_fma.c:190:1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chris2553 at googlemail dot com
Target Milestone: ---
Building 11-20201122 (with gcc-10-20201121 or gcc-10-20201114) results in an
ICE as follows:
/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu/./gcc/xgcc
-B/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include
-fno-checking -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes
-Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem
./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80
-DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc
-I../../../gcc-11-20201122/libgcc -I../../../gcc-11-20201122/libgcc/.
-I../../../gcc-11-20201122/libgcc/../gcc
-I../../../gcc-11-20201122/libgcc/../include
-I../../../gcc-11-20201122/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -o bid128_fma.o -MT bid128_fma.o -MD -MP -MF
bid128_fma.dep -c ../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c
during GIMPLE pass: loopdone
../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c: In function
'nr_digits256':
../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c:190:1: internal
compiler error: Segmentation fault
190 | nr_digits256 (UINT256 R256) {
| ^~~~
A log of the full build (using rpmbuild) and the preprocessed source are
attached.
[Bug bootstrap/97933] [11 Regression] Bootstrap failure on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933 --- Comment #3 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #1) > Started with r11-5034-g253c415a1acba50711c82693426391743ac18040 Sorry for causing this error. It is clearly my mistake. I've started to work on this. The fix will be ready tomorrow.
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #1 from Chris Clayton --- Created attachment 49611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49611&action=edit Preprocessed source
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #2 from Chris Clayton --- Created attachment 49612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49612&action=edit Full build log
[Bug c++/97951] Template specialization of function template fails for fixed-sized SVE vector types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97951 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-11-23 --- Comment #1 from rsandifo at gcc dot gnu.org --- Could you try GCC 10.2? I believe this was fixed by g:ecd56bc41563a84808fe4e1a2c7341bf8a621c92.
[Bug target/97928] -fstack-clash-protection probe miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97928 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2020-11-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||law at redhat dot com --- Comment #2 from Jeffrey A. Law --- I took a peek when Serge pointed me at the issue. I think there's a window where a signal handler could clash. It'd be hard to exploit, but we should fix it. It's on my TODO list.
[Bug libgcc/89714] allow for overriding the thread-detection mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714 --- Comment #4 from Jonathan Wakely --- That wouldn't help when people link directly with -lpthread rather than -pthread. _REENTRANT is not required for pthreads, so I don't think we should depend on it.
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 --- Comment #5 from Bill Long --- Original submitter asking for a fixed-in version number.
[Bug libstdc++/97948] C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.0 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2020-11-23 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/97949] Recursive calls of std::call_once together with cout leads to deadlock under mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-23 Ever confirmed|0 |1
[Bug libstdc++/60662] simple use of call_once throws a system_error exception, but not if sleep_for is called beforehand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > I'm not sure why this_thread::sleep_for (which just calls nanosleep) causes > libpthread.so to get linked in, but ldd shows that there is a libpthread.so > dependency with it. nanosleep used to be defined in both libc.so and libpthread.so, so if you link with -lpthread then the definition in libpthread.so will be found (because of the order of libraries gcc passes to the linker) and you get a dependency on libpthread.so Recent versions of glibc only define it in libc.so
[Bug libstdc++/97948] C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fd62daea40e09c1e6d599a6171db6b298d6c362e commit r11-5255-gfd62daea40e09c1e6d599a6171db6b298d6c362e Author: Jonathan Wakely Date: Mon Nov 23 15:46:24 2020 + libstdc++: Link tests to libatomic as required [PR 97948] libstdc++-v3/ChangeLog: PR libstdc++/97948 * testsuite/29_atomics/atomic_float/wait_notify.cc: Add options for libatomic. * testsuite/29_atomics/atomic_integral/wait_notify.cc: Likewise. * testsuite/29_atomics/atomic_ref/wait_notify.cc: Likewise.
[Bug libstdc++/97948] C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jonathan Wakely --- This *should* be fixed now. Please reopen if not.
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2020-11-23 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Can't reproduce that with c2ac0d1a66e03279.
[Bug c/97954] New: [11 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97954
Bug ID: 97954
Summary: [11 Regression] ICE in maybe_record_trace_start, at
dwarf2cfi.c:2360
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20201108 and 20201115 :
$ cat z1.c
int
foo (void)
{
int x;
lab:
asm goto ("": "=a" (x) : : : lab);
return x;
}
$ gcc-11-20201122 -c z1.c -O2
during RTL pass: dwarf2
z1.c: In function 'foo':
z1.c:8:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2360
8 | }
| ^
0x7c9c43 maybe_record_trace_start
../../gcc/dwarf2cfi.c:2360
0x7ca18a create_trace_edges
../../gcc/dwarf2cfi.c:2501
0x7cc163 scan_trace
../../gcc/dwarf2cfi.c:2732
0x7cca31 create_cfi_notes
../../gcc/dwarf2cfi.c:2758
0x7cca31 execute_dwarf2_frame
../../gcc/dwarf2cfi.c:3122
0x7cca31 execute
../../gcc/dwarf2cfi.c:3610
---
z1.c: In function 'foo':
z1.c:8:1: error: too many outgoing branch edges from bb 4
8 | }
| ^
during RTL pass: loop2_invariant
z1.c:8:1: internal compiler error: verify_flow_info failed
0x814164 verify_flow_info()
../../gcc/cfghooks.c:269
0xb3c87b checking_verify_flow_info
../../gcc/cfghooks.h:212
0xb3c87b move_loop_invariants()
../../gcc/loop-invariant.c:2304
0xb384f0 execute
../../gcc/loop-init.c:530
[Bug c/97955] New: [11 Regression] ICE in build_array_type_1, at tree.c:8264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97955
Bug ID: 97955
Summary: [11 Regression] ICE in build_array_type_1, at
tree.c:8264
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20200823 and 20201004 :
$ cat z1.c
void f (int n, int a[n]);
void f (int *b) {}
$ gcc-11-20201122 -c z1.c
z1.c:2:1: internal compiler error: Segmentation fault
2 | void f (int *b) {}
| ^~~~
0xb42eff crash_signal
../../gcc/toplev.c:330
0xdbbf5d build_array_type_1
../../gcc/tree.c:8264
0x62930b attr_access::array_as_string[abi:cxx11](tree_node*) const
../../gcc/attribs.c:2299
0x6ff9cd warn_parm_array_mismatch(unsigned int, tree_node*, tree_node*)
../../gcc/c-family/c-warn.c:3435
0x6421a4 start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc/c/c-decl.c:9591
0x689236 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2444
0x690a47 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x691569 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x691569 c_parse_file()
../../gcc/c/c-parser.c:21882
0x6e0772 c_common_parse_file()
../../gcc/c-family/c-opts.c:1198
[Bug tree-optimization/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 49613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49613&action=edit gcc11-pr97950.patch Untested fix for the short cases. As for __int128, I think it would be better if you filed a separate issue, because it has nothing to do with the short one, and mentioned which moves you find redundant. Generally, some redundant moves will be there with double-word arithmetics, it is a matter of when exactly it is the right time to lower double-word operations (and which) into word ones, doing it too early prevents e.g. STV from doing its job and e.g. doing for __int128 some operations in SSE registers, while doing it too late may result in the already assigning pairs of GP registers for the 128-bit pseudos and while some useless moves can be recovered afterwards, certainly not all of them. x86 doesn't really have instructions that would allow implementing the 128-bit multiplications with overflow efficiently.
[Bug c/97956] New: [11 Regression] ICE in build2, at tree.c:4872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956
Bug ID: 97956
Summary: [11 Regression] ICE in build2, at tree.c:4872
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20200823 and 20201004, derived from memchr.c :
$ cat z1.c
typedef __INT8_TYPE__ int8_t;
typedef __INT32_TYPE__ int32_t;
extern void* memchr (const void*, int, long);
struct SX
{
int32_t n;
int8_t a[];
};
const struct SX sx = { 0x1221 };
const char sx_rep[] = { };
void test_find (void)
{
int n = 0, nb = (const char*)&sx.a - (const char*)&sx;
const char *p = (const char*)&sx, *q = sx_rep;
n += p + 1 == memchr (p, q[1], nb);
}
$ gcc-11-20201122 -c z1.c
$
$ gcc-11-20201122 -c z1.c -O2
during GIMPLE pass: forwprop
z1.c: In function 'test_find':
z1.c:16:1: internal compiler error: in build2, at tree.c:4872
16 | }
| ^
0xdaae9e build2(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/tree.c:4871
0x880b9f build2_loc
../../gcc/tree.h:4371
0x880b9f fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:13318
0xc3ad53 forward_propagate_into_comparison_1
../../gcc/tree-ssa-forwprop.c:434
0xc41900 forward_propagate_into_comparison
../../gcc/tree-ssa-forwprop.c:491
0xc41900 execute
../../gcc/tree-ssa-forwprop.c:3145
[Bug c/97957] New: ICE in init_dynamic_diag_info, at c-family/c-format.c:5024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97957
Bug ID: 97957
Summary: ICE in init_dynamic_diag_info, at
c-family/c-format.c:5024
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
A doubled line affects versions down to at least r5 :
$ cat z1.c
typedef long __gcc_host_wide_int__;
typedef long __gcc_host_wide_int__;
__attribute__ ((__format__ (__gcc_diag__, 1, 2)))
void f () {}
$ gcc-11-20201122 -c z1.c
z1.c:4:1: internal compiler error: in init_dynamic_diag_info, at
c-family/c-format.c:5024
4 | void f () {}
| ^~~~
0x6d1b97 init_dynamic_diag_info
../../gcc/c-family/c-format.c:5024
0x6d1b97 handle_format_attribute(tree_node**, tree_node*, tree_node*, int,
bool*)
../../gcc/c-family/c-format.c:5252
0x62a101 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:724
0x641eef start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc/c/c-decl.c:9410
0x689236 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2444
0x690a47 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x691569 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x691569 c_parse_file()
../../gcc/c/c-parser.c:21882
0x6e0772 c_common_parse_file()
../../gcc/c-family/c-opts.c:1198
[Bug c/97957] ICE in init_dynamic_diag_info, at c-family/c-format.c:5024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97957
--- Comment #1 from G. Steinmetz ---
Another similar situation :
$ cat z2.c
typedef long __gcc_host_wide_int__;
typedef long __gcc_host_wide_int__;
__attribute__ ((__format__ (__asm_fprintf__, 1, 2)))
void f () {}
$ gcc-11-20201122 -c z2.c
z2.c:4:1: internal compiler error: in init_dynamic_asm_fprintf_info, at
c-family/c-format.c:4829
4 | void f () {}
| ^~~~
0x6d1b33 init_dynamic_asm_fprintf_info
../../gcc/c-family/c-format.c:4829
0x6d1b33 handle_format_attribute(tree_node**, tree_node*, tree_node*, int,
bool*)
../../gcc/c-family/c-format.c:5240
0x62a101 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:724
0x641eef start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc/c/c-decl.c:9410
0x689236 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2444
0x690a47 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x691569 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x691569 c_parse_file()
../../gcc/c/c-parser.c:21882
0x6e0772 c_common_parse_file()
../../gcc/c-family/c-opts.c:1198
[Bug libstdc++/67791] [8/9/10/11 Regression] Crash using std::thread and iostream with dynamic loading of a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791 Jonathan Wakely changed: What|Removed |Added Summary|Crash using std::thread and |[8/9/10/11 Regression] |iostream with dynamic |Crash using std::thread and |loading of a shared library |iostream with dynamic ||loading of a shared library Known to work||4.9.4 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED Known to fail||10.2.0, 11.0, 5.1.0, 8.4.0, ||9.3.0 Target Milestone|--- |8.5 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > (In reply to nexyon from comment #4) > > In any case std::thread should not > > crash I guess, so just to fix that it would be necessary to check whether > > the standard library was inizialized without threads. > > We used to check for the pthread_create weak symbol, and throw an exception > instead of crashing. Since the fix for PR libstdc++/61841 we don't check it, > and crash instead of throwing. That should be fixed. Marking as a regression, because GCC 4.9 printed this error instead of crashing: terminate called after throwing an instance of 'std::system_error' what(): Enable multithreading to use std::thread: Operation not permitted Aborted (core dumped) That's better than segfaulting with no explanation. I incorrectly assumed that the use of &pthread_create added for PR 61841 would make checking __gthread_active_p unnecessary. As the examples here show, that's not true. The program calls __gthread_active_p() before main() runs, and at that time libpthread.so is not loaded. When libpthread.so is loaded later, it's too late for __gthread_active_p to notice.
[Bug c/97958] New: ICE in build2, at tree.c:4868
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97958
Bug ID: 97958
Summary: ICE in build2, at tree.c:4868
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5 :
$ cat z1.c
int f ()
{
#pragma omp atomic
f = f + 1;
}
$ gcc-11-20201122 -c z1.c -fopenmp
z1.c: In function 'f':
z1.c:4:3: internal compiler error: in build2, at tree.c:4868
4 | f = f + 1;
| ^
0xdaaf2d build2(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/tree.c:4867
0x674105 c_parser_binary_expression
../../gcc/c/c-parser.c:8010
0x674b15 c_parser_conditional_expression
../../gcc/c/c-parser.c:7607
0x675071 c_parser_expr_no_commas
../../gcc/c/c-parser.c:7522
0x67ffd0 c_parser_omp_atomic
../../gcc/c/c-parser.c:17677
0x69045c c_parser_omp_construct
../../gcc/c/c-parser.c:21546
0x66dd07 c_parser_pragma
../../gcc/c/c-parser.c:12517
0x688206 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5764
0x6885d3 c_parser_compound_statement
../../gcc/c/c-parser.c:5606
0x689e61 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2543
0x690a47 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x691569 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x691569 c_parse_file()
../../gcc/c/c-parser.c:21882
0x6e0772 c_common_parse_file()
../../gcc/c-family/c-opts.c:1198
[Bug tree-optimization/96272] Failure to optimize overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96272 --- Comment #5 from Jakub Jelinek --- It shouldn't be added to match.pd, the check as written in the source is certainly better for other optimization passes. For PR95853 I've added recently a widening_mul (i.e. very late pass, almost before expansion) pattern matching of another form (very lame in the source code) of the overflow check but in that case I've put a constraint that the overflow check and addition must be in the same bb (and not too far from each other). In this case it isn't in the same bb and again would be very undesirable if it is really too far (would increase register pressure).
[Bug lto/97959] New: Random FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O -flto -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97959
Bug ID: 97959
Summary: Random FAIL: gcc.dg/lto/save-temps
c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O
-flto -save-temps
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
On Linux/x86-64 with 96 cores, I got random:
Executing on host:
/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/
c_lto_save-temps_0.o -mx32 -fdiagnostics-plain-output -O -flto -save-temps
-o gcc-dg-lto-save-temps-01.exe(timeout = 300)
spawn -ignore SIGHUP
/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/
c_lto_save-temps_0.o -mx32 -fdiagnostics-plain-output -O -flto -save-temps -o
gcc-dg-lto-save-temps-01.exe
/usr/local/bin/ld: i386 architecture of input file
`./gcc-dg-lto-save-temps-01.ltrans0.ltrans.o' is incompatible with i386:x64-32
output
/usr/local/bin/ld: final link failed: file in wrong format
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O
-flto -save-temps
with
$ make -j 56 check RUNTESTFLAGS="--target_board='unix{-m32,-mx32,}'"
The problem is that -m32, -mx32 and -m64 use the same filename,
gcc-dg-lto-save-temps-01.ltrans0.ltrans.o.
[Bug tree-optimization/97960] New: [8/9/10/11 Regression] Wrong code at -O3 since r8-6511-g3ae129323d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960
Bug ID: 97960
Summary: [8/9/10/11 Regression] Wrong code at -O3 since
r8-6511-g3ae129323d
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
GCC miscompiles the following C++ testcase at -O3 (reproduced on both x86 and
aarch64):
const int &c(const int &d, const int &f) {
if (d < f)
return f;
return d;
}
short a[575];
unsigned b[25];
unsigned char g;
int main()
{
for (int e = 0; e < 23; ++e)
a[e * 23] = 16137;
for (signed char h = c(g, 253) + 3; h < 24; h++)
b[h] = 1064739102;
for (int e = 0; e < 23; ++e)
if (a[e * 23] != 16137)
__builtin_abort();
}
When compiled with -O{0,g,s,1,2} (with or without -ftree-vectorize), the
program exits cleanly, but aborts when compiled with -O3 since the above
revision. The program also exits cleanly when compiled with clang on x86 and
aarch64 at various optimization levels.
[Bug c/97958] ICE in build2, at tree.c:4868
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97958 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-11-23 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 49614 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49614&action=edit gcc11-pr97958.patch Untested fix.
[Bug tree-optimization/97960] [8/9/10/11 Regression] Wrong code at -O3 since r8-6511-g3ae129323d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960
--- Comment #1 from Alex Coplan ---
C testcase:
const int *c(const int *p, const int *q)
{
if (*p < *q)
return q;
return p;
}
short a[575];
unsigned b[25];
unsigned char g;
int main()
{
for (int e = 0; e < 23; ++e)
a[e * 23] = 16137;
int t1 = g;
int t2 = 253;
signed char h = *c(&t1, &t2) + 3;
for (; h < 24; h++)
b[h] = 1064739102;
for (int e = 0; e < 23; ++e)
if (a[e * 23] != 16137)
__builtin_abort();
}
[Bug tree-optimization/97960] [8/9/10/11 Regression] Wrong code at -O3 since r8-6511-g3ae129323d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Last reconfirmed||2020-11-23 Priority|P3 |P1 Ever confirmed|0 |1 Target Milestone|--- |8.5 Keywords||wrong-code --- Comment #2 from Martin Liška --- Confirmed!
[Bug tree-optimization/97961] New: unnecessary moves with __builtin_{add,sub}_overflow_p and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97961
Bug ID: 97961
Summary: unnecessary moves with __builtin_{add,sub}_overflow_p
and __int128
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In #97950 Jackub told me to open a new bug for that.
The snippet bellow has the following problems
- f1 and f2 generate 4 unnecessary moves
mov r9, rdi
mov r8, rsi
mov rsi, r9
mov rdi, r8
- f4 has "only" 2 unnecessary moves
mov r9, rdi
mov rdi, rsi
- f3 should be identical to f4 except for the flag checking.
bool f1(unsigned __int128 a,unsigned __int128 b) {
return __builtin_add_overflow_p(a, b, (unsigned __int128)0);
}
bool f2(__int128 a,__int128 b) {
return __builtin_add_overflow_p(a, b, (__int128)0);
}
bool f3(unsigned __int128 a,unsigned __int128 b) {
return __builtin_sub_overflow_p(a, b, (unsigned __int128)0);
}
bool f4(__int128 a,__int128 b) {
return __builtin_sub_overflow_p(a, b, (__int128)0);
}
asm generated
f1(unsigned __int128, unsigned __int128):
mov r9, rdi
mov r8, rsi
mov rsi, r9
mov rdi, r8
add rsi, rdx
adc rdi, rcx
setcal
ret
f2(__int128, __int128):
mov r9, rdi
mov r8, rsi
mov rsi, r9
mov rdi, r8
add rsi, rdx
adc rdi, rcx
setoal
ret
f3(unsigned __int128, unsigned __int128):
mov r9, rdi
mov r8, rsi
mov rdi, r8
mov rax, r9
mov r8, rdx
sub rax, r8
mov rdx, rdi
sbb rdx, rcx
cmp r9, rax
mov rcx, rdi
sbb rcx, rdx
setcal
ret
f4(__int128, __int128):
mov r9, rdi
mov rdi, rsi
cmp r9, rdx
sbb rdi, rcx
setoal
ret
---
[Bug tree-optimization/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 --- Comment #2 from denis.campredon at gmail dot com --- Thanks for your fast patch. I've opened PR97961 for the __int128 problem
[Bug c/97957] ICE in init_dynamic_diag_info, at c-family/c-format.c:5024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97957 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-11-23 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Confirmed, at least as old as GCC 4.8.0.
[Bug c++/97947] [11 Regression] ICE in digest_init_r, at cp/typeck2.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-11-23 Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed with powerpc64le-unknown-linux-gnu cross.
[Bug tree-optimization/97956] [11 Regression] ICE in build2, at tree.c:4872 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956 Martin Liška changed: What|Removed |Added Known to work||10.2.0 Summary|[11 Regression] ICE in |[11 Regression] ICE in |build2, at tree.c:4872 |build2, at tree.c:4872 ||since ||r11-2709-g866626efd749ed3e Known to fail||11.0 Ever confirmed|0 |1 Priority|P3 |P1 Last reconfirmed||2020-11-23 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Component|c |tree-optimization Target Milestone|--- |11.0 --- Comment #1 from Martin Liška --- Started with r11-2709-g866626efd749ed3e.
[Bug target/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c/97955] [11 Regression] ICE in build_array_type_1, at tree.c:8264 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97955 Martin Liška changed: What|Removed |Added Known to work||10.2.0 Last reconfirmed||2020-11-23 Summary|[11 Regression] ICE in |[11 Regression] ICE in |build_array_type_1, at |build_array_type_1, at |tree.c:8264 |tree.c:8264 since ||r11-3303-g6450f07388f9fe57 Target Milestone|--- |11.0 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Known to fail||11.0 --- Comment #1 from Martin Liška --- Started with r11-3303-g6450f07388f9fe57.
[Bug c++/97947] [11 Regression] ICE in digest_init_r, at cp/typeck2.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947 --- Comment #2 from Marek Polacek --- We crash here 1143 /* Come here only for aggregates: records, arrays, unions, complex numbers 1144 and vectors. */ 1145 gcc_assert (code == ARRAY_TYPE 1146 || VECTOR_TYPE_P (type) 1147 || code == RECORD_TYPE 1148 || code == UNION_TYPE 1149 || code == COMPLEX_TYPE); because code == OPAQUE_TYPE.
[Bug c/97954] [11 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97954 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0 Known to fail||11.0 Last reconfirmed||2020-11-23 Ever confirmed|0 |1 Known to work||10.2.0 CC||marxin at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r11-5002-ge3b3b59683c1e7d3.
[Bug fortran/97927] gfortran: ICE in lookup_field_for_decl, at tree-nested.c:288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927 --- Comment #8 from Jakub Jelinek --- Can't reproduce with 20201005 10 branch or current trunk. The 10 branch changed tree-nested.c e.g. in r10-8663, but I don't really see any linear, lastprivate or reduction clauses in this.
[Bug target/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 --- Comment #3 from Uroš Bizjak --- Comment on attachment 49613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49613 gcc11-pr97950.patch >+(define_insn_and_split "*setcc_hi_1" >+ [(set (match_operand:HI 0 "register_operand" "=q") >+ (match_operator:HI 1 "ix86_comparison_operator" >+[(reg FLAGS_REG) (const_int 0)]))] >+ "!TARGET_PARTIAL_REG_STALL" >+ "#" >+ "&& reload_completed" >+ [(set (match_dup 2) (match_dup 1)) >+ (set (match_dup 0) (zero_extend:DI (match_dup 2)))] zero_extend:HI Perhaps you could apply SWI24 mode iterator to existing *setcc_si_1_and and *setcc_si_1_movzbl?
[Bug target/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 Jakub Jelinek changed: What|Removed |Added Attachment #49613|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-11-23 --- Comment #4 from Jakub Jelinek --- Created attachment 49615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49615&action=edit gcc11-pr97950.patch Updated patch.
[Bug libstdc++/97949] Recursive calls of std::call_once together with cout leads to deadlock under mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949 --- Comment #1 from Jonathan Wakely --- This isn't specific to mingw, it's a bug in the std::call_once implementation for non-TLS targets. t2 runs outerDoOnce() and tries to acquire a mutex lock before running innerDoOnce(), but that mutex is held by t3 while it waits to try to run outerDoOnce(). t3 won't proceed until t2 finishes, which is blocked by t3.
[Bug rtl-optimization/92294] alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 rsandifo at gcc dot gnu.org changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Februar ||y/539763.html --- Comment #9 from rsandifo at gcc dot gnu.org --- Oops, I never linked the patch, it's: https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539763.html (following on from an earlier discussion in January). Reading the thread back now, the reception wasn't as negative as I'd remembered. I'd been vaguely hoping to find time to try removing find_base_term & co. for GCC 11, but that obviously never happened. (Turns out that writing new code is more fun. ;-)) Maybe we could consider going for the linked patch for GCC 11.
[Bug c++/97962] New: [10/11] ICE in build_over_call, at cp/call.c:8976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97962
Bug ID: 97962
Summary: [10/11] ICE in build_over_call, at cp/call.c:8976
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
Created attachment 49616
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49616&action=edit
preprocessed source
seen with the gcc-10 branch and the trunk, compiler configured with
--enable-checking=yes,extra,rtl
works with gcc-9, configured with --enable-checking=release.
$ g++ -c -std=c++17 pool-prj-mgr-app_win_download.ii
pool-prj-mgr-app_win_download.ii: In instantiation of ‘struct
__result_of_memfun_deref’:
pool-prj-mgr-app_win_download.ii:13:60: required from ‘struct
conditional<__result_of_memfun_deref >’
pool-prj-mgr-app_win_download.ii:27:75: required from ‘struct
__result_of_memfun’
pool-prj-mgr-app_win_download.ii:32:8: required from ‘struct
__result_of_impl’
pool-prj-mgr-app_win_download.ii:44:8: recursively required by substitution
of ‘template struct __is_invocable_impl<_Result,
_Ret, __void_t > [with _Result = __invoke_result; _Ret =
void]’
pool-prj-mgr-app_win_download.ii:44:8: required from ‘struct
__is_invocable’
pool-prj-mgr-app_win_download.ii:62:41: required from
‘thread::thread(_Callable, _Args ...) [with _Callable = void
(PoolProjectManagerAppWindow::*)(Trans_NS___cxx11_basic_string); _Args =
{PoolProjectManagerAppWindow*, ustring, Trans_NS___cxx11_basic_string}]’
pool-prj-mgr-app_win_download.ii:68:57: required from here
pool-prj-mgr-app_win_download.ii:17:55: internal compiler error: in
build_over_call, at cp/call.c:8976
17 | static __result_of_success
_S_test;
| ^~~~
0x5de01a build_over_call
../../src/gcc/cp/call.c:8976
0xaa30fe build_new_method_call_1
../../src/gcc/cp/call.c:10385
0xaa429e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../src/gcc/cp/call.c:10460
0xaa429e build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../src/gcc/cp/call.c:9861
0xa94458 build_temp
../../src/gcc/cp/call.c:7128
0xa94458 convert_like_real_1
../../src/gcc/cp/call.c:7705
0xa95b3d perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../src/gcc/cp/call.c:11921
0xca79f5 convert_arguments
../../src/gcc/cp/typeck.c:4197
0xca79f5 cp_build_function_call_vec(tree_node*, vec**, int, tree_node*)
../../src/gcc/cp/typeck.c:4031
0xb4c4d0 build_offset_ref_call_from_tree(tree_node*, vec**, int)
../../src/gcc/cp/decl2.c:5276
0xc28b46 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:20073
0xc2b204 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:15946
0xc2db88 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13193
0xc3331b tsubst_aggr_type
../../src/gcc/cp/pt.c:13396
0xc22b01 tsubst_decl
../../src/gcc/cp/pt.c:14604
0xc33a29 instantiate_template_1
../../src/gcc/cp/pt.c:20871
0xc340ba instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.c:20928
0xc340ba finish_template_variable(tree_node*, int)
../../src/gcc/cp/pt.c:10167
0xc3420a lookup_and_finish_template_variable(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.c:10180
0xc28af8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:19306
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
[Bug libstdc++/97949] Recursive calls of std::call_once together with cout leads to deadlock under mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949 --- Comment #2 from Jonathan Wakely --- Oh, and I think the cout calls just slow things down and introduce some serialization (in stdio) so that the threads run concurrently.
[Bug fortran/85796] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from anlauf at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2020-November/055325.html Thus taking.
[Bug c++/97951] Template specialization of function template fails for fixed-sized SVE vector types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97951 David Tellenbach changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #2 from David Tellenbach --- Thanks, I can confirm this is fixed in GCC 10.2 and works as expected.
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 --- Comment #6 from Jason Merrill --- I think we should reject trying to clear the padding of a flexible/zero-length array, with error rather than sorry. And handle an array at the end of a struct like any other array. Nobody should be using this builtin with the struct hack, it's impossible for it to do anything sensible.
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 --- Comment #16 from Bernd Edlinger --- (In reply to SRINATH PARVATHANENI from comment #15) > (In reply to Bernd Edlinger from comment #14) > > fixed on trunk. > > Thanks Bernd for fixing this on trunk, would you mind backporting this to > GCC-10 as well? > > Thanks you. > > Regards, > Srinath. Since it is a gcc_checking_assert that triggers the ICE, I assumed that does not affect a release build, is that correct?
