[Bug c++/92365] [10 Regression] ice unexpected expression ‘int16_t()’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92365 Bernd Edlinger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Bernd Edlinger --- fixed on trunk.
[Bug c++/92365] [10 Regression] ice unexpected expression ‘int16_t()’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92365 --- Comment #8 from Bernd Edlinger --- Author: edlinger Date: Sat Nov 23 06:33:59 2019 New Revision: 278639 URL: https://gcc.gnu.org/viewcvs?rev=278639=gcc=rev Log: PR c++/92365 2019-11-22 Bernd Edlinger PR c++/92365 * name-lookup.c (check_local_shadow): Use can_convert_arg instead of can_convert. testsuite: 2019-11-22 Bernd Edlinger PR c++/92365 * g++.dg/pr92365.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr92365.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/92637] New: runtime issue with -ftree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92637 Bug ID: 92637 Summary: runtime issue with -ftree-coalesce-vars Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dongjianqiang2 at huawei dot com Target Milestone: --- Created attachment 47338 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47338=edit testsuite hi, I compiled the attached with aarch64-linux-gnu-gcc -c -O2 -march=armv8.1-a testsuite.c -o testsuite.o, it had runtime error, and I found x10 was overwriten ar row 214. 01d0 : 1d0: a9bf7bfdstp x29, x30, [sp, #-16]! 1d4: aa0403ebmov x11, x4 1d8: aa0003eamov x10, x0 1dc: aa0103e9mov x9, x1 1e0: 910003fdmov x29, sp 1e4: aa2403edmvn x13, x4 1e8: 2a0303ecmov w12, w3 1ec: 1405b 200 1f0: 9400bl f0 1f4: eb00011fcmp x8, x0 1f8: 54000209b.ls238 // b.plast 1fc: 91000402add x2, x0, #0x1 200: aa0903e1mov x1, x9 204: aa0a03e0mov x0, x10 208: 9400bl 0 20c: 8b0b0007add x7, x0, x11 210: 8a0d00e7and x7, x7, x13 214: aa0a03e0mov x0, x10 // HERE x10 is overwriten by glibc 218: 8b0c00e8add x8, x7, x12 21c: aa0703e2mov x2, x7 220: aa0803e1mov x1, x8 224: eb08013fcmp x9, x8 228: 54fffe42b.cs1f0 // b.hs, b.nlast 22c: aa0803e0mov x0, x8 230: a8c17bfdldp x29, x30, [sp], #16 234: d65f03c0ret 238: aa0703e8mov x8, x7 23c: aa0803e0mov x0, x8 240: a8c17bfdldp x29, x30, [sp], #16 244: d65f03c0ret But when I add -fno-tree-coalesce-vars, x10 changed to x9, following assembler is running correctly. 01e0 : 1e0: a9bf7bfdstp x29, x30, [sp, #-16]! 1e4: aa0403eamov x10, x4 1e8: aa0003e9mov x9, x0 1ec: aa0103e8mov x8, x1 1f0: 910003fdmov x29, sp 1f4: aa2403ecmvn x12, x4 1f8: 2a0303ebmov w11, w3 1fc: 1405b 210 200: 9400bl f8 204: ebffcmp x7, x0 208: 54000209b.ls248 // b.plast 20c: 91000402add x2, x0, #0x1 210: aa0803e1mov x1, x8 214: aa0903e0mov x0, x9 //HERE is correct 218: 9400bl 0 21c: 8b0a0006add x6, x0, x10 220: 8a0c00c6and x6, x6, x12 224: aa0903e0mov x0, x9 228: 8b0b00c7add x7, x6, x11 22c: aa0603e2mov x2, x6 230: aa0703e1mov x1, x7 234: eb07011fcmp x8, x7 238: 54fffe42b.cs200 // b.hs, b.nlast 23c: aa0703e0mov x0, x7 240: a8c17bfdldp x29, x30, [sp], #16 244: d65f03c0ret 248: aa0603e0mov x0, x6 24c: a8c17bfdldp x29, x30, [sp], #16 250: d65f03c0ret I checked x9-x15 are caller-saved register, why compiler doesn't push these registers onto the stack across calls?
[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589 Eric Gallager changed: What|Removed |Added Keywords||documentation CC||egallager at gcc dot gnu.org --- Comment #12 from Eric Gallager --- (In reply to Matthijs Kooijman from comment #11) > It seems this was actually implemented at some point (at least for C++, > maybe that was the case all along already), though the manual page was not > updated to reflect this. Sounds like a documentation issue, too, then; adding that keyword...
[Bug other/92631] Warnings partly caused by system headers are broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92631 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- (In reply to Matthew Woehlke from comment #0) > > (Apologies if this is a duplicate and I have overlooked a similar report.) There are actually several other similar reports having to do with the handling of -Wsystem-headers, but I can't decide which of them to mark this a duplicate of...
[Bug tree-optimization/79716] memset followed by overwrite not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79716 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- I'd want to see bug 68034 fixed first before GCC starts doing this optimization.
[Bug c++/61339] add mismatch between struct and class [-Wmismatched-tags] to non-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339 --- Comment #14 from Eric Gallager --- (In reply to Martin Sebor from comment #13) > Author: msebor > Date: Tue Jul 9 18:32:49 2019 > New Revision: 273311 > > URL: https://gcc.gnu.org/viewcvs?rev=273311=gcc=rev > Log: > PR c++/61339 - add mismatch between struct and class [-Wmismatched-tags] to > non-bugs > [...snip...] This is just dealing with the fallout that WOULD occur if we were to add the warning, right? i.e., it didn't actually add the warning itself?
[Bug target/90724] ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90724 Eric Gallager changed: What|Removed |Added Target Milestone|--- |9.4 --- Comment #4 from Eric Gallager --- (In reply to prathamesh3492 from comment #3) > (In reply to Eric Gallager from comment #2) > > (In reply to prathamesh3492 from comment #1) > > > Author: prathamesh3492 > > > Date: Wed Aug 21 18:34:43 2019 > > > New Revision: 274805 > > > > > > URL: https://gcc.gnu.org/viewcvs?rev=274805=gcc=rev > > > Log: > > > 2019-08-21 Prathamesh Kulkarni > > > > > > PR target/90724 > > > * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): Force y > > > in reg if it fails aarch64_plus_operand predicate. > > > > > > Modified: > > > trunk/gcc/ChangeLog > > > trunk/gcc/config/aarch64/aarch64.c > > > > Did this fix it? > > On trunk, yes. Needs to be backported to gcc-9-branch. > > Thanks, > Prathamesh ok, adjusting Target Milestone
[Bug c++/85861] g++ -Wconversion misses int to size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85861 --- Comment #12 from Eric Gallager --- (In reply to Martin Sebor from comment #10) > He's at Microsoft and no longer involved in GCC development. He came to Cauldron this year though...
[Bug c++/92636] New: out-of-class definition of member template of specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92636
Bug ID: 92636
Summary: out-of-class definition of member template of
specialization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
looks like a long standing bug, and probably already reported. But I ran into
it, it looks well formed [clang accepts it]
template class X;
template<>
class X
{
template void f (U);
};
template<>
template
void X::f (U)
{
}
g++ -c
x.cc:11:6: error: too many template-parameter-lists
11 | void X::f (U)
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #10 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > I Know there has been discussion about >f not being a NULL pointer even > but I cannot find it right now. Finally found it: PR30368 comment #3: The C standard still says that is undefined. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf : 6.5.3.2/3: If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator. Otherwise, the result is a pointer to the object or function designated by its operand. CUT In the case of >f, it is the same as &((*a).f). There is no discussion in the above about the . operator NOTE also the commentry comments in the margin: Thus, &*E is equivalent to E (even if E is a null pointer), and &(E1[E2]) to ((E1)+(E2)). It is always true that if E is a function designator or an lvalue that is a valid operand of the unary & operator, * is a function designator or an lvalue equal to E. If *P is an lvalue and T is the name of an object pointer type, *(T)P is an lvalue that has a type compatible with that to which T points. Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime. CUT Again there is the no discussion about -> or . here. So Again >f cannot be null even if a is null.
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #9 from Andrew Pinski --- https://gcc.gnu.org/ml/gcc-patches/2005-05/msg00076.html
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #8 from Andrew Pinski --- (In reply to Alan Modra from comment #7) > Here's another example, a typical offsetof. > > #define offsetof(TYPE, MEMBER) ((unsigned long) &((TYPE *)0)->MEMBER) That can never be a correct offsetof as that can never be a constant integer expression in C or C++. That is one of the reasons why GCC created __builtin_offsetof (reading old history): https://gcc.gnu.org/ml/gcc-bugs/2003-06/msg00482.html :) I Know there has been discussion about >f not being a NULL pointer even but I cannot find it right now.
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #7 from Alan Modra --- Here's another example, a typical offsetof. #define offsetof(TYPE, MEMBER) ((unsigned long) &((TYPE *)0)->MEMBER)
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 Jakub Jelinek changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- CCing Joseph on the language lawyer part of the thing.
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
Alan Modra changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2019-11-23
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #5 from Alan Modra ---
How is it that "clang does this" overrides the C standard?
And yes, I quite realise that the C standard does not explicitly say >field
does not dereference p, but the analogy with [i] is strong and the fact is
that >field does not cause a dereference. So it ought to be good when p is
null.
I'll note that we are talking C here, not C++.
If you're going to close this bug again then do so with an explanation from a
language viewpoint as to why
void
lang_for_each_input_file (void (*func) (lang_input_statement_type *))
{
lang_input_statement_type *f;
for (f = _file_chain.head->input_statement;
f != NULL;
f = f->next_real_file)
if (f->flags.real)
func (f);
}
is wrong. I'm genuinely interested, not just pissed off that you've closed my
bug..
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Dup of bug 80797. What I mean by that is the regression is not a regression but rather a specific change introduced in GCC 7 and that is the PR which was asking for this specific change.
[Bug sanitizer/80797] -fsanitize=null doesn't instrument >x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80797 Andrew Pinski changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 92634 has been marked as a duplicate of this bug. ***
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 80797. *** This bug has been marked as a duplicate of bug 80797 ***
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #2 from Alan Modra --- (In reply to Andrew Pinski from comment #1) > No those are still officially considered a referencing. > > In fact all three cases: > >field does not dereference p, just as &*p and [i] do not. > > Should be considered a deference even though the deference does not happen. The ISO C standard ISO/IEC 9899:1999 appears to disagree with you. From 6.5.3.2 "3 The unary & operator returns the address of its operand. If the operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. Similarly, if the operand is the result of a [] operator" [snip rest] I do not see anything under "constraints on the operators" that precludes &*p on a null p, in fact there is a note that says "83) Thus, &*E is equivalent to E (even if E is a null pointer)" [snip rest] So what is more official than the C standard that makes you say "those are still officially considered a referencing"?
[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337 --- Comment #10 from Marek Polacek --- Author: mpolacek Date: Fri Nov 22 23:48:25 2019 New Revision: 278635 URL: https://gcc.gnu.org/viewcvs?rev=278635=gcc=rev Log: PR c++/88337 - P1327R1: Allow polymorphic typeid in constexpr. Part of P1327R1 is to allow typeid with an operand of polymorphic type in constexpr. I found that we pretty much support it already, the only tweak was to allow TYPEID_EXPR (only created in a template) in constexpr in C++20. * constexpr.c (potential_constant_expression_1): Allow a typeid expression whose operand is of polymorphic type in constexpr in C++20. * rtti.c (build_typeid): Remove obsolete FIXME comment. * g++.dg/cpp2a/constexpr-typeid1.C: New test. * g++.dg/cpp2a/constexpr-typeid2.C: New test. * g++.dg/cpp2a/constexpr-typeid3.C: New test. * g++.dg/cpp2a/constexpr-typeid4.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-typeid1.C trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-typeid2.C trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-typeid3.C trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-typeid4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/rtti.c trunk/gcc/testsuite/ChangeLog
[Bug target/92635] __builtin_finited{32,64,128} should inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92635 --- Comment #1 from Andrew Pinski --- >Inline ASM is not ideal since dfp classification instructions targets CRs. If the PowerPC had the "Flag Output" inline-asm extension like x86 has: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Extended-Asm.html#Flag-Output-Operands Then you could express it using inline-asm without any issues.
[Bug target/92635] New: __builtin_finited{32,64,128} should inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92635
Bug ID: 92635
Summary: __builtin_finited{32,64,128} should inline
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: murphyp at linux dot vnet.ibm.com
Target Milestone: ---
Target: powerpc
Inline ASM is not ideal since dfp classification instructions targets CRs.
e.g for _Decimal128:
inline _Decimal128
___isfinited128 (_Decimal128 x)
{
int cr0;
asm ("dtstdcq cr0,%1,0x38\n"
"mfcr %0, 128\n"
: "=r" (cr0)
: "f" (x)
: "cr0");
return (cr0 & 0x2000) ? 1 : 0;
};
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #1 from Andrew Pinski --- No those are still officially considered a referencing. In fact all three cases: >field does not dereference p, just as &*p and [i] do not. Should be considered a deference even though the deference does not happen. There are other similar bug reports that say similar things to the null pointer case.
[Bug sanitizer/92634] New: [gcc-8 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 Bug ID: 92634 Summary: [gcc-8 regression] -fsanitize=undefined erroneous null pointer check Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 47337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47337=edit testcase -fsanitize=undefined inserts bogus pointer checks on expressions that effectively cast a pointer to a union to a pointer to one of the elements of that union. >field does not dereference p, just as &*p and [i] do not. This bites in binutils sources (eg. see ldlang.c lang_for_each_input_file), where >field is used in preference to (type_of_field *) p, since the cast loses some type checking.
[Bug fortran/92629] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92629
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> Confirmed.
>
> Tentative fix:
>
> Index: gcc/fortran/simplify.c
> ===
> --- gcc/fortran/simplify.c (Revision 278629)
> +++ gcc/fortran/simplify.c (Arbeitskopie)
> @@ -170,7 +170,8 @@ convert_mpz_to_unsigned (mpz_t x, int bitsize)
>else
> {
>/* Confirm that no bits above the signed range are set. */
> - gcc_assert (mpz_scan1 (x, bitsize-1) == ULONG_MAX);
> + if (flag_range_check != 0)
> + gcc_assert (mpz_scan1 (x, bitsize-1) == ULONG_MAX);
> }
> }
I was looking at a fix in compare_bitwise(), but it did not
work as intended. One thing I added was a warning that
bit wise comparisons involving a negative integer is processor
dependent.
[Bug c++/92633] [concepts] constrained lambda with placehoder syntax getting wrong substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92633 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-22 Blocks||67491 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c/90677] [9 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] gcc-9.1.0 |[9 Regression] gcc-9.1.0 |fails to build __gcc_diag__ |fails to build __gcc_diag__ |souce: error: 'cgraph_node' |souce: error: 'cgraph_node' |is not defined as a type|is not defined as a type --- Comment #11 from Jakub Jelinek --- Should be fixed on the trunk so far.
[Bug c++/92458] Constraints do not work with precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92458 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Should be fixed now. I believe GCC 9 cp/constraints.cc doesn't have this tree_cache_map.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 92458, which changed state. Bug 92458 Summary: Constraints do not work with precompiled headers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92458 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug fortran/92629] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92629
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-11-22
CC||anlauf at gcc dot gnu.org
Version|unknown |10.0
Ever confirmed|0 |1
Known to fail||10.0, 8.3.1, 9.2.1
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
Tentative fix:
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (Revision 278629)
+++ gcc/fortran/simplify.c (Arbeitskopie)
@@ -170,7 +170,8 @@ convert_mpz_to_unsigned (mpz_t x, int bitsize)
else
{
/* Confirm that no bits above the signed range are set. */
- gcc_assert (mpz_scan1 (x, bitsize-1) == ULONG_MAX);
+ if (flag_range_check != 0)
+ gcc_assert (mpz_scan1 (x, bitsize-1) == ULONG_MAX);
}
}
[Bug c/90677] [9/10 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Fri Nov 22 21:45:27 2019 New Revision: 278634 URL: https://gcc.gnu.org/viewcvs?rev=278634=gcc=rev Log: PR c/90677 * c-common.h (identifier_global_tag): Declare. * c-format.c (get_pointer_to_named_type): Renamed to ... (get_named_type): ... this. Use identifier_global_tag instead of identifier_global_value, handle the return value being a TYPE_P. (init_dynamic_diag_info): Adjust get_pointer_to_named_type callers to call get_named_type instead. Formatting fixes. c/ * c-decl.c (identifier_global_tag): Define. cp/ * cp-objcp-common.c (identifier_global_tag): Define. testsuite/ * c-c++-common/pr90677.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr90677.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/c-family/c-format.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.c trunk/gcc/testsuite/ChangeLog
[Bug c++/92633] New: [concepts] constrained lambda with placehoder syntax getting wrong substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92633
Bug ID: 92633
Summary: [concepts] constrained lambda with placehoder syntax
getting wrong substitution
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following code fails to compile with trunk with -std=c++2a
template
concept different_than = !__is_same_as(A, B);
template
auto diff(B) {
return [](different_than auto a) {};
}
int main() {
diff(42)("");
}
By the time the compiler evaluates the constraint, it seems to have forgotten
the context in which the constraint lives; that is, it no longer seems to know
what type B is.
I think the code should compile, and it does with clang-concepts:
https://godbolt.org/z/3QzhxS
[Bug tree-optimization/92632] New: Calculix regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92632 Bug ID: 92632 Summary: Calculix regression Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- LNT testing show 137% regression of calculix with LTO and PGO https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=288.170.0 The range is between Revision: fbbadf0018292a93 (2019-11-15 03:28) and Revision: 1e9cd853b7ecae82 (2019-11-18 02:22) The diff from this range is: +2019-11-18 Hongtao Liu + + PR target/92448 + * config/i386/i386-expand.c (ix86_expand_set_or_cpymem): + Replace TARGET_AVX128_OPTIMAL with TARGET_AVX256_SPLIT_REGS. + * config/i386/i386-option.c (ix86_vec_cost): Ditto. + (ix86_reassociation_width): Ditto. + * config/i386/i386-options.c (ix86_option_override_internal): + Replace TARGET_AVX128_OPTIAML with + ix86_tune_features[X86_TUNE_AVX128_OPTIMAL] + * config/i386/i386.h (TARGET_AVX256_SPLIT_REGS): New macro. + (TARGET_AVX128_OPTIMAL): Deleted. + * config/i386/x86-tune.def (X86_TUNE_AVX256_SPLIT_REGS): New + DEF_TUNE. + +2019-11-16 Segher Boessenkool + + * config/rs6000/rs6000.md (cceq_ior_compare): Rename to... + (@cceq_ior_compare_ for GPR): ... this. Allow GPR instead of + just SI. + (cceq_rev_compare): Rename to... + (@cceq_rev_compare_ for GPR): ... this. Allow GPR instead of + just SI. + (define_split for tf_): Add SImode first argument to + gen_cceq_ior_compare. + +2019-11-16 Segher Boessenkool + + * common/config/powerpcspe: Delete. + +2019-11-16 Richard Sandiford + + * config/aarch64/aarch64-sve.md (aarch64_wrffr): Wrap the FFRT + output in UNSPEC_WRFFR. + +2019-11-16 Richard Sandiford + + * tree-data-ref.c (create_intersect_range_checks_index): Rewrite + the index tests to have the form (unsigned T) (B - A + bias) <= limit. + +2019-11-16 Richard Sandiford + + * tree-data-ref.c (create_intersect_range_checks_index) + (create_intersect_range_checks): Print dump messages. + +2019-11-16 Richard Sandiford + + * tree-data-ref.c (dump_alias_pair): New function. + (prune_runtime_alias_test_list): Use it to dump each merged alias pair. + +2019-11-16 Richard Sandiford + + * tree-data-ref.h (DR_ALIAS_MIXED_STEPS): New flag. + * tree-data-ref.c (prune_runtime_alias_test_list): Set it when + merging data references with different steps. + (create_intersect_range_checks_index): Take a + dr_with_seg_len_pair_t instead of two dr_with_seg_lens. + Bail out if DR_ALIAS_MIXED_STEPS is set. + (create_intersect_range_checks): Take a dr_with_seg_len_pair_t + instead of two dr_with_seg_lens. Update call to + create_intersect_range_checks_index. + (create_runtime_alias_checks): Update call accordingly. + +2019-11-16 Richard Sandiford + + * tree-data-ref.h (DR_ALIAS_RAW, DR_ALIAS_WAR, DR_ALIAS_WAW) + (DR_ALIAS_ARBITRARY, DR_ALIAS_SWAPPED, DR_ALIAS_UNSWAPPED): New flags. + (dr_with_seg_len_pair_t::sequencing): New enum. + (dr_with_seg_len_pair_t::flags): New member variable. + (dr_with_seg_len_pair_t::dr_with_seg_len_pair_t): Take a sequencing + parameter and initialize the flags member variable. + * tree-loop-distribution.c (compute_alias_check_pairs): Update + call accordingly. + * tree-vect-data-refs.c (vect_prune_runtime_alias_test_list): Likewise. + Ensure the two data references in an alias pair are in statement + order, if there is a defined order. + * tree-data-ref.c (prune_runtime_alias_test_list): Use + DR_ALIAS_SWAPPED and DR_ALIAS_UNSWAPPED to record whether we've + swapped the references in a dr_with_seg_len_pair_t. OR together + the flags when merging two dr_with_seg_len_pair_ts. After merging, + try to restore the original dr_with_seg_len order, updating the + flags if that fails. + +2019-11-16 Richard Sandiford + + * tree-data-ref.c (prune_runtime_alias_test_list): Delay + swapping the dr_as based on init values until we've decided + whether to merge them. + +2019-11-16 Richard Sandiford + + * tree-data-ref.c (prune_runtime_alias_test_list): Sort the + two accesses in each dr_with_seg_len_pair_t before trying to + combine separate dr_with_seg_len_pair_ts. + * tree-loop-distribution.c (compute_alias_check_pairs): Don't do + that here. + * tree-vect-data-refs.c (vect_prune_runtime_alias_test_list): Likewise. + +2019-11-16 Richard Sandiford + + * config/aarch64/aarch64-sve.md + (scatter_store): Extend to... + (scatter_store): ...this. +
[Bug other/92631] New: Warnings partly caused by system headers are broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92631
Bug ID: 92631
Summary: Warnings partly caused by system headers are broken
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: mwoehlke.floss at gmail dot com
Target Milestone: ---
While trying to fix warnings in a code base, we noticed that some are very
strange:
foo.cpp: warning: by ‘virtual ...’ [-Werror=overloaded-virtual]
bar.cpp: warning: but ‘...’ does not throw; perhaps it should be declared
‘noexcept’ [-Wnoexcept]
The commonality is that all of these are the second part of a multi-part
warning. The first part of the warning IS NOT SHOWN. Further testing proved
that the problem isn't on our end (misreading the log or some such); gcc NEVER
printed the first part of the warning. Additionally, the file reference for the
missing first part would be in a "system" header.
Needless to say, this makes for some *very* confusing warnings.
Attempting to compile the following example will reproduce the issue:
==> foo.cpp <==
#pragma GCC diagnostic error "-Woverloaded-virtual"
#include "foo.h"
struct bar : foo
{
void frob(int) override;
}
==> foo.h <==
#pragma GCC system_header
struct foo
{
virtual void frob(int);
virtual void frob(long);
};
(Compile with 'g++ foo.cpp'.)
Adding -Wsystem-headers "reveals" the missing first part of the
warnings/errors.
(Apologies if this is a duplicate and I have overlooked a similar report.)
[Bug c++/92458] Constraints do not work with precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92458 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Fri Nov 22 21:38:44 2019 New Revision: 278633 URL: https://gcc.gnu.org/viewcvs?rev=278633=gcc=rev Log: PR c++/92458 * tree-hash-traits.h (tree_decl_hash, tree_ssa_name_hash, tree_hash): Move to ... * tree.h (tree_decl_hash, tree_ssa_name_hash, tree_hash): ... here. (struct decl_tree_cache_traits, struct type_tree_cache_traits): New types. (decl_tree_cache_map, tree_tree_cache_map): New typedefs. * init.c (nsdmi_inst): Change type to decl_tree_cache_map * from tree_cache_map *. * constraint.cc (decl_constraints): Likewise. * decl.c (get_tuple_decomp_init): Likewise. * pt.c (defarg_inst, explicit_specifier_map): Likewise. (tsubst_default_argument, store_explicit_specifier): Use decl_tree_cache_map::create_ggc rather than tree_cache_map::create_ggc. * cp-objcp-common.c (debug_type_map): Change type to type_tree_cache_map * from tree_cache_map *. * g++.dg/pch/pr92458.C: New test. * g++.dg/pch/pr92458.Hs: New test. Added: trunk/gcc/testsuite/g++.dg/pch/pr92458.C trunk/gcc/testsuite/g++.dg/pch/pr92458.Hs Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/constraint.cc trunk/gcc/cp/cp-objcp-common.c trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-hash-traits.h trunk/gcc/tree.h
[Bug libfortran/92569] [8/9/10 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
--- Comment #7 from Thomas Koenig ---
(In reply to anlauf from comment #6)
> Something like the following fixes the testcase, but leads to regressions
> elsewhere in the testsuite (e.g. direct_io_{9,10}.f):
You've found the right spot, I think.
Index: io/transfer.c
===
--- io/transfer.c (Revision 278025)
+++ io/transfer.c (Arbeitskopie)
@@ -2544,6 +2544,10 @@
while (data)
{
+ if (unlikely (dtp->u.p.current_unit
+ && dtp->u.p.current_unit->endfile == AFTER_ENDFILE))
+ return;
+
dtp->u.p.transfer (dtp, iotype, data, kind, size, tsize);
data += stride0 * tsize;
count[0] += tsize;
seems to be better...
[Bug middle-end/92630] New: missing -Wrestrict with attribute access and restrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92630
Bug ID: 92630
Summary: missing -Wrestrict with attribute access and restrict
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Besides out-of-bounds reads and writes, the new attribute access also makes it
possible to detect overlapping copies. Calls in all four functions below
should be diagnosed as suggested in the comments.
$ cat t.c && gcc -O2 -S -Wall -Wextra t.c
typedef __SIZE_TYPE__ size_t;
void* memcpy (void* restrict, const void* restrict, size_t);
__attribute__ ((access (write_only, 1, 3), access (read_only, 2, 3))) void
f0 (void* restrict, const void *restrict, unsigned);
char a[8];
void f1 (void)
{
memcpy (a, a + 2, 8); // -Wstringop-overflow (good)
}
void f2 (void)
{
memcpy (a, a + 2, 4); // -Wsrestrict (good)
}
__attribute__ ((access (write_only, 1, 3), access (read_only, 2, 3))) void
mycpy (void* restrict, const void *restrict, unsigned);
void g1 (void)
{
mycpy (a, a + 2, 8); // warning (good)
}
void g2 (void)
{
mycpy (a, a + 2, 4); // missing -Wsrestrict
}
t.c: In function ‘f2’:
t.c:17:3: warning: ‘memcpy’ accessing 4 bytes at offsets 0 and 2 overlaps 2
bytes at offset 2 [-Wrestrict]
17 | memcpy (a, a + 2, 4); // -Wsrestrict (good)
| ^~~~
t.c: In function ‘f1’:
t.c:12:3: warning: ‘memcpy’ forming offset [8, 9] is out of the bounds [0, 8]
of object ‘a’ with type ‘char[8]’ [-Warray-bounds]
12 | memcpy (a, a + 2, 8); // warning (good)
| ^~~~
t.c:8:6: note: ‘a’ declared here
8 | char a[8];
| ^
t.c: In function ‘g1’:
t.c:25:3: warning: ‘mycpy’ reading 8 bytes from a region of size 6
[-Wstringop-overflow=]
25 | mycpy (a, a + 2, 8); // -Wstringop-overflow (good)
| ^~~
t.c:21:1: note: in a call to function ‘mycpy’ declared with attribute
‘read_only (2, 3)’
21 | mycpy (void* restrict, const void *restrict, unsigned);
| ^
[Bug bootstrap/92627] configure script unable to find gmp, mpc, and mpfr install dirs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92627 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jakub Jelinek --- .
[Bug bootstrap/92627] configure script unable to find gmp, mpc, and mpfr install dirs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92627 --- Comment #4 from George R. Goffe --- Hi, Pleas disregard this bug. It's a UFU (User Foul Up). The message CLEARLY says mpfr >= 3.1.0. I have mpfr 3.0 1. Can you spell dyslexia? Sorry for the misfire. Best regards, George...
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #19 from Daniel Marjamäki ---
(In reply to Segher Boessenkool from comment #15)
> (In reply to Daniel Marjamäki from comment #12)
> > So, how would you fix the warning for `f`? Many programmers would "fix" it
> > with a cast.
> >
> > Assuming that `s` and `u` can have arbitrary values, here is the proper
> > code:
> >
> > void f(long s, unsigned long u) { if (s >= 0 && s == u) g(); }
> >
> > For this correct code, gcc warns.
>
> A much better fix is
>
> void f1(long s, unsigned long u) { unsigned long su = s; if (su == u) g(); }
>
> which makes it rather explicit what is going on.
>
> Still much better is to not mixed signedness in types at all.
That does not work.
Imagine that you call f1 like so : `f1(-1L, ~0UL)`. If you don't want that g()
is called when the argument values are mathematically different.. like here..
how do you do?
[Bug target/91615] [10 regression][armeb] ICEs since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #11 from Bernd Edlinger --- (In reply to Jakub Jelinek from comment #9) > Is this fixed now? everything except the regression in arm/unaligned-memcpy-2/3.c the patch was considered too ugly: the last version was here (probably still too ugly): https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00370.html but I did not consider this important enough to send any pings.
[Bug fortran/92629] New: internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92629 Bug ID: 92629 Summary: internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:173 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gsocshubham at gmail dot com Target Milestone: --- For below testcase, I ran on godbolt.org GFORTRAN trunk - TESTCASE--- subroutine print_pass_fail(expected, actual) implicit none logical :: actual, expected if ( actual .eqv. expected )then print *, "PASS" else print *, "FAIL" end if end subroutine print_pass_fail program bge_test_base implicit none logical :: index index = BGE(127, 2147483648); !print *, index call print_pass_fail (.true.,index) end program --COMMAND LINE OPTIION USED -fno-range-check --TRIED ON--- X86-64 gfortran (trunk)
[Bug middle-end/91612] [10 regression][arm] gcc.target/arm/aapcs/align4.c ICE after r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Christophe Lyon --- Yes, this is fixed.
[Bug middle-end/91613] [10 regression][arm] gcc.dg/pr83930.c ICE since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91613 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Christophe Lyon --- Yes, this is fixed.
[Bug target/91615] [10 regression][armeb] ICEs since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Christophe Lyon --- Yes, this is fixed.
[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589
Matthijs Kooijman changed:
What|Removed |Added
CC||matthijs at stdin dot nl
--- Comment #11 from Matthijs Kooijman ---
It seems this was actually implemented at some point (at least for C++, maybe
that was the case all along already), though the manual page was not updated to
reflect this. Taking the example from the manual (which is documented to *not*
cause this warning):
matthijs@grubby:~$ cat foo.cpp
struct s { int f, g, h; };
struct s x = { .f = 3, .g = 4 };
matthijs@grubby:~$ gcc foo.cpp -c -Wall -Wextra
foo.cpp:2:31: warning: missing initializer for member ‘s::h’
[-Wmissing-field-initializers]
struct s x = { .f = 3, .g = 4 };
^
However, this seems to be the case only for C++, if I rename to foo.c, no
warning is emitted.
I actually came here looking for a way to *disable* this warning for designated
initializers on a specific struct. I was hoping to use a struct with designated
initializers as an elegant way to specify configuration with optional fields
(e.g. by lettin any unspecified fields be initialized to 0 and fill in a
default value for them). However, when any caller that omits a field to get the
default value is pestered with a warning, that approach does not really work
well. On the other hand, disabling the warning completely with a commandline
option or pragma seems heavy-handed, since I do consider this a useful warning
in many other cases.
[Bug testsuite/90517] [10 regression] test case gcc.dg/cdce1.c fails (unresolved) starting with r271281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90517 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90576 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Is this fixed now?
[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #20 from Jakub Jelinek --- Assuming fixed then, please reopen if not.
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #29 from Jakub Jelinek --- So can this be closed now as fixed?
[Bug rtl-optimization/91223] [10 Regression] ICE: in curr_insn_transform, at lra-constraints.c:4459
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91223 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vmakarov at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Let's assume it is. If not, please reopen.
[Bug middle-end/91612] [10 regression][arm] gcc.target/arm/aapcs/align4.c ICE after r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Is this fixed now?
[Bug middle-end/91613] [10 regression][arm] gcc.dg/pr83930.c ICE since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91613 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Is this fixed now?
[Bug target/91615] [10 regression][armeb] ICEs since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Is this fixed now?
[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91769 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Assuming this is fixed. If not, please reopen.
[Bug ipa/91832] [10 Regression] ICE in scan_expr_access, at ipa-sra.c:1695 since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91832 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Is this fixed now?
[Bug c/91401] schedule + dist_schedule clauses rejected on distribute parallel for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91401 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.4 --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug middle-end/91623] [8 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug middle-end/91001] internal compiler error: in extract_insn, at recog.c:2310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91001 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug middle-end/91105] internal compiler error: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91105 Bug 91105 depends on bug 91001, which changed state. Bug 91001 Summary: internal compiler error: in extract_insn, at recog.c:2310 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91001 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug preprocessor/92296] [8 Regression] internal compiler error: Segmentation fault #pragma push_macro("__LINE__")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug middle-end/92384] [8 Regression] Empty class instances have different equal testing result among GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92384 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug target/90867] [8 Regression] Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c/90898] [8 Regression] ICE in insert_clobber_before_stack_restore, at tree-ssa-ccp.c:2112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90898 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug middle-end/91450] __builtin_mul_overflow(A,B,R) wrong code if product < 0, *R is unsigned, and !(A)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91450 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed for 10+, 9.3+ and 8.4+.
[Bug middle-end/90840] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90840 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug tree-optimization/92618] [10 Regression] error: type mismatch in binary expression in reassoc since r273490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92618 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/92618] [10 Regression] error: type mismatch in binary expression in reassoc since r273490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92618 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Nov 22 18:17:04 2019 New Revision: 278626 URL: https://gcc.gnu.org/viewcvs?rev=278626=gcc=rev Log: PR tree-optimization/92618 * tree-ssa-reassoc.c (v_info): Change from auto_vec to a struct containing the auto_vec and a tree. (undistribute_bitref_for_vector): Handle the case when element type of vec is not the same as type of the BIT_FIELD_REF. Formatting fixes. * gcc.c-torture/compile/pr92618.c: New test. * gcc.c-torture/execute/pr92618.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr92618.c trunk/gcc/testsuite/gcc.c-torture/execute/pr92618.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #18 from Segher Boessenkool ---
(In reply to Vincent Lefèvre from comment #17)
> (In reply to Segher Boessenkool from comment #15)
> > A much better fix is
> >
> > void f1(long s, unsigned long u) { unsigned long su = s; if (su == u) g(); }
>
> But what if s is some arbitrary integer type, e.g. that comes from a library?
You need to fix this per case. If there was a simple fix this PR would
not even exist :-(
> > Still much better is to not mixed signedness in types at all.
>
> One does not necessarily have the choice. The signedness of some types is
> not specified.
Do not mix signed, unsigned, and unspecified signedness type.
This requires less sloppy API design, and you need to match impedance
with other libraries in some places, sure. Same as always.
[Bug c/84919] [8/9/10 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c++/90480] [8/9/10 Regression] ICE when calling operator() inside a lambda defined in a template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90480 --- Comment #3 from Luke Dalessandro --- Created attachment 47336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47336=edit Testcast
[Bug c++/90480] [8/9/10 Regression] ICE when calling operator() inside a lambda defined in a template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90480
--- Comment #2 from Luke Dalessandro ---
I'm hitting this with the following similar, but different snippet. Maybe it
will help with this.
#include
struct Foo {
int operator()(int i) {
return 0;
}
template
auto operator()(std::array ids) {
return std::apply([&](auto...) {
return operator()(0);
}, ids);
}
};
int main() {
Foo foo;
foo(std::array{0, 1});
}
[Bug middle-end/83859] Please add new attribute which will establish relation between parameters for buffer and its size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Martin Sebor --- The part of the patch that adds the attribute has been added in r278624. The rest of it will be committed separately under other bugs (e.g., those referenced in See Also).
[Bug middle-end/31279] Uninitialized warning for call-by-reference arguments with known intent(in)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279 Bug 31279 depends on bug 83859, which changed state. Bug 83859 Summary: Please add new attribute which will establish relation between parameters for buffer and its size https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/83859] Please add new attribute which will establish relation between parameters for buffer and its size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859 --- Comment #10 from Martin Sebor --- Author: msebor Date: Fri Nov 22 17:14:17 2019 New Revision: 278624 URL: https://gcc.gnu.org/viewcvs?rev=278624=gcc=rev Log: PR middle-end/83859 - attributes to associate pointer arguments and sizes gcc/ChangeLog: PR middle-end/83859 * attribs.h (struct attr_access): New. * attribs.c (decl_attributes): Add an informational note. * builtins.c (check_access): Make extern. Consistently set no-warning after issuing a warning. Handle calls through function pointers. Set no-warning. * builtins.h (check_access): Declare. * calls.c (rdwr_access_hash): New type. (rdwr_map): Same. (init_attr_rdwr_indices): New function. (maybe_warn_rdwr_sizes): Same. (initialize_argument_information): Call init_attr_rdwr_indices. Call maybe_warn_rdwr_sizes. (get_size_range): Avoid null argument. * doc/extend.texi (attribute access): Document new attribute. gcc/c-family/ChangeLog: PR middle-end/83859 * c-attribs.c (handle_access_attribute): New function. (c_common_attribute_table): Add new attribute. (get_argument_type): New function. (append_access_attrs): New function. (get_nonnull_operand): Rename... (get_attribute_operand): ...to this. * c-common.c (get_nonnull_operand): Rename... (get_attribute_operand): ...to this. gcc/testsuite/ChangeLog: PR middle-end/83859 * c-c++-common/attr-nonstring-8.c: Adjust text of expected warning. * gcc.dg/Wstringop-overflow-23.c: New test. * gcc.dg/Wstringop-overflow-24.c: New test. * gcc.dg/attr-access-read-only.c: New test. * gcc.dg/attr-access-read-write.c: New test. * gcc.dg/attr-access-read-write-2.c: New test. * gcc.dg/attr-access-write-only.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-23.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-24.c trunk/gcc/testsuite/gcc.dg/attr-access-read-only.c trunk/gcc/testsuite/gcc.dg/attr-access-read-write-2.c trunk/gcc/testsuite/gcc.dg/attr-access-read-write.c trunk/gcc/testsuite/gcc.dg/attr-access-write-only.c Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/attribs.h trunk/gcc/builtins.c trunk/gcc/builtins.h trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/calls.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attr-nonstring-8.c
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 92501, which changed state. Bug 92501 Summary: strncmp with constant unterminated arrays not folded https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92501 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/92501] strncmp with constant unterminated arrays not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92501 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- Patch committed in r278621.
[Bug middle-end/88226] missing warning on fprintf, fputs, and puts with an unterminated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88226 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Sebor --- Patch committed in r278623.
[Bug middle-end/88226] missing warning on fprintf, fputs, and puts with an unterminated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88226 --- Comment #5 from Martin Sebor --- Author: msebor Date: Fri Nov 22 16:47:22 2019 New Revision: 278623 URL: https://gcc.gnu.org/viewcvs?rev=278623=gcc=rev Log: PR middle-end/88226 - missing warning on fprintf, fputs, and puts with an unterminated array gcc/ChangeLog: PR middle-end/88226 * builtins.c (check_nul_terminated_array): New function. (fold_builtin_0): Remove declaration. (fold_builtin_1): Same. (fold_builtin_2): Same. (fold_builtin_3): Same. (fold_builtin_strpbrk): Add argument. (fold_builtin_strspn): Same. (fold_builtin_strcspn): Same. (expand_builtin_strcat): Call it. Remove unused argument. (expand_builtin_stpncpy): Same. (expand_builtin_strncat): Same. (expand_builtin_strncpy): Same. Adjust indentation. (expand_builtin_strcmp): Same. (expand_builtin_strncmp): Same. (expand_builtin_fork_or_exec): Same. (expand_builtin): Handle more built-ins. (fold_builtin_2): Add argument. (fold_builtin_n): Make static. Add argument. (fold_call_expr): Pass new argument to fold_builtin_n and fold_builtin_2. (fold_builtin_call_array): Pass new argument to fold_builtin_n. (fold_builtin_strpbrk): Add argument. Call check_nul_terminated_array. (fold_call_stmt): Pass new argument to fold_builtin_n. * builtins.h: Correct a comment. * gimple-fold.c (gimple_fold_builtin_strchr): Call check_nul_terminated_array. * tree-ssa-strlen.c (handle_builtin_strlen): Call check_nul_terminated_array. (handle_builtin_strchr): Same. (handle_builtin_string_cmp): Same. gcc/testsuite/ChangeLog: PR middle-end/88226 * gcc.dg/Wstringop-overflow-22.c: New test. * gcc.dg/tree-ssa/builtin-fprintf-warn-1.c: Remove xfails. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-22.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/builtins.h trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-fprintf-warn-1.c trunk/gcc/tree-ssa-strlen.c
[Bug tree-optimization/92501] strncmp with constant unterminated arrays not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92501 --- Comment #2 from Martin Sebor --- Author: msebor Date: Fri Nov 22 16:39:37 2019 New Revision: 278621 URL: https://gcc.gnu.org/viewcvs?rev=278621=gcc=rev Log: PR tree-optimization/92501 - strncmp with constant unterminated arrays not folded gcc/testsuite/ChangeLog: PR tree-optimization/92501 * gcc.dg/strcmpopt_7.c: New test. gcc/ChangeLog: PR tree-optimization/92501 * gimple-fold.c ((gimple_fold_builtin_string_compare): Let strncmp handle unterminated arrays. Rename local variables for clarity. Added: trunk/gcc/testsuite/gcc.dg/strcmpopt_7.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug c/92620] Ignored -fno-builtin -fno-builtin-memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92620 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- It would be helpful to warn even with -fno-builtin-memcpy for user-defined definitions of memcpy that are incompatible with the standard function (e.g., GCC shouldn't silently accept the definition of a variable named memcpy). It might also help to reiterate under -fno-builtin the part about memcpy et al. being required even in freestanding environments.
[Bug ipa/92109] [10 Regression] ICE in modify_call_stmt, at ipa-param-manipulation.c:1586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92109 --- Comment #7 from Martin Jambor --- After talking to Honza, I have proposed a different patch on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02205.html
[Bug ipa/91956] [10 Regression] ICE: verify_cgraph_node failed (error: comdat-local function called by __ct .isra outside its comdat) since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91956 --- Comment #2 from Martin Jambor --- I proposed a patch on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02203.html
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #17 from Vincent Lefèvre ---
(In reply to Segher Boessenkool from comment #15)
> A much better fix is
>
> void f1(long s, unsigned long u) { unsigned long su = s; if (su == u) g(); }
But what if s is some arbitrary integer type, e.g. that comes from a library?
Even using uintmax_t may be insufficient. For instance, GCC has __uint128.
> Still much better is to not mixed signedness in types at all.
One does not necessarily have the choice. The signedness of some types is not
specified.
[Bug c++/92625] [8/9/10 Regression] Internal compiler error accessing element in static constexpr char array in template class using alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92625
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Target Milestone|9.3 |8.4
Summary|[9/10 Regression] Internal |[8/9/10 Regression]
|compiler error accessing|Internal compiler error
|element in static constexpr |accessing element in static
|char array in template |constexpr char array in
|class using alias |template class using alias
--- Comment #2 from Jakub Jelinek ---
Though, with a small modification it started with r221328.
template
struct G {
using C = char;
static constexpr C my_array[1] = "";
};
void
work ()
{
G::my_array[1];
}
This ICEs because in tsubst_copy we do for STRING_CST:
16647 /* Instantiate any typedefs in the type. */
16648 tree type = tsubst (TREE_TYPE (t), args, complain, in_decl);
16649 r = fold_convert (type, t);
16650 gcc_assert (TREE_CODE (r) == code);
For other codes handled by this like INTEGER_CST, REAL_CST and COMPLEX_CST, the
assertion is meaningful, but for STRING_CSTs fold_convert doesn't really create
a new STRING_CST with different type. Both types are C[1], just the C is
different tree between the two.
So, shall we just not do this assertion (say gcc_assert (code == STRING_CST ||
TREE_CODE (r) == code); and is it fine if we return a NOP_EXPR? I guess it
could change something for lvalues, with say ADDR_EXPR of a STRING_CST being
valid, but ADDR_EXPR of NOP_EXPR of STRING_CST not valid.
Or shall we build a new STRING_CST with the new type if the type is different?
Something else?
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #39 from Vladimir Makarov --- (In reply to Jan Hubicka from comment #38) > > Seems a lot of memory is taken by IRA, too. > > I played with the test too. 2^16 functions. It is a lot of insns and IRA/LRA is not only RA but in some way a code selector too which should keep a lot additional structures about insns. Memory numbers for IRA is just GCed memory allocation. We should be interesting in *peak* memory allocation. I don't see any peak for RA. ./cc1 -O2 with valgrind massif looks like (after recent Richard's patch changing IRA XNEWs on a memory pool): KB 206.8^: | :#::@:@::@::: | : ::: : :#::@:@::@::: |:: : : : : :#::@:@::@::: | : : : : : : :#::@:@::@::: | :@ :: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: | ::@::: : : : : : :#::@:@::@::: 0 +--->Mi 0 1.435 So it is about 200MB *peak* memory consumption and RA consuming only 4% of time which I think is an excellent result (usually RA takes more time). integrated RA : 7.21 ( 4%) 1.51 ( 3%) 9.37 ( 3%) 1581592 kB ( 38%) LRA non-specific : 1.35 ( 1%) 0.31 ( 1%) 1.95 ( 1%) 3584 kB ( 0%) LRA virtuals elimination : 0.38 ( 0%) 0.10 ( 0%) 0.43 ( 0%) 0 kB ( 0%) LRA reload inheritance : 0.16 ( 0%) 0.04 ( 0%) 0.14 ( 0%) 0 kB ( 0%) LRA create live ranges : 0.01 ( 0%) 0.01 ( 0%) 0.08 ( 0%) 0 kB ( 0%) LRA hard reg assignment: 0.23 ( 0%) 0.06 ( 0%) 0.17 ( 0%) 0 kB ( 0%)
[Bug c++/92625] [9/10 Regression] Internal compiler error accessing element in static constexpr char array in template class using alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92625 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-22 CC||jakub at gcc dot gnu.org, ||msebor at gcc dot gnu.org Target Milestone|--- |9.3 Summary|Internal compiler error |[9/10 Regression] Internal |accessing element in static |compiler error accessing |constexpr char array in |element in static constexpr |template class using alias |char array in template ||class using alias Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started to ICE with r263511.
[Bug tree-optimization/91355] [8/9/10 Regression] optimized code does not call destructor while unwinding after exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355 --- Comment #10 from Jakub Jelinek --- With the above changes, the bug is now latent.
[Bug rtl-optimization/92610] [10 Regression] ICE in calc_dfs_tree, at dominance.c:458 since r270940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92610 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 47335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47335=edit gcc10-pr92610.patch Untested fix.
[Bug tree-optimization/91665] [8 Regression] ICE in build_vector_from_val, at tree.c:1904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91665 Arseny Solokha changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Arseny Solokha --- Fixed on all affected branches.
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #16 from Segher Boessenkool ---
(In reply to Eric Gallager from comment #13)
> > Yes. You should not use casts, except in some very specific cases, and
> > most of the uses you see "in the wild" are a bad idea. Sometimes I wonder
> > if we should have a -Wcast ("Warn for any cast.").
>
> I get the feeling that such a warning would be extremely noisy and that no
> one would use it.
It was not meant as a serious suggestion of course, or I would have done this
many many years ago.
My point is that *most* casts you see in the wild are a bad idea.
Unfortunately it isn't easy (if possible at all) to have the compiler give
the user good advice on this.
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #15 from Segher Boessenkool ---
(In reply to Daniel Marjamäki from comment #12)
> So, how would you fix the warning for `f`? Many programmers would "fix" it
> with a cast.
>
> Assuming that `s` and `u` can have arbitrary values, here is the proper code:
>
> void f(long s, unsigned long u) { if (s >= 0 && s == u) g(); }
>
> For this correct code, gcc warns.
A much better fix is
void f1(long s, unsigned long u) { unsigned long su = s; if (su == u) g(); }
which makes it rather explicit what is going on.
Still much better is to not mixed signedness in types at all.
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- Please show output of 'cc -v' and attach assembly for main.cc. Providing vague linkage semantics with dynamic linking is a tricky area, especially when dlopen is in play, moreso with RTLD_LOCAL as in this example. For example, if you wanted vague-linkage objects to be unified across multiple dlopen'ed libraries (each with RTLD_LOCAL), you'd need special support from the toolchain and the dynamic linker. At some point GNU toolchain invented a new special ELF symbol binding type, STB_GNU_UNIQUE, but it turned out to cause other issues. It can be disabled in the compiler with --disable-gnu-unique-object, in which case the outcome you show here is expected. I think on non-GNU systems you'll likely get "1" rather than "2".
[Bug tree-optimization/88915] Try smaller vectorisation factors in scalar fallback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88915 Tamar Christina changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/88915] Try smaller vectorisation factors in scalar fallback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88915 Tamar Christina changed: What|Removed |Added Target Milestone|--- |10.0 --- Comment #6 from Tamar Christina --- Can this issue be closed now Andre?
[Bug c++/22395] -Weffc++ shouldn't warn about non-virtual dtor of private subclasses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22395 --- Comment #9 from Jonathan Wakely --- (In reply to marc from comment #8) > I don't think Effective C++ is the benchmark any more I've been trying to say that for years and people keep insisting they want warnings based on advice from the late '90s. Warnings that don't even accurately follow that advice.
[Bug inline-asm/92615] [8/9/10 Regression] ICE in extract_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92615 --- Comment #2 from Jakub Jelinek --- Created attachment 47334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47334=edit gcc10-pr92615.patch Untested fix.
[Bug inline-asm/92615] [8/9/10 Regression] ICE in extract_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92615
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-11-22
CC||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started to ICE with r225122. Shorter testcase:
void
foo (void)
{
void *p = (void *)
__asm__ ("" : "=@ccng" (p) : "r" (1));
}
[Bug c++/22395] -Weffc++ shouldn't warn about non-virtual dtor of private subclasses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22395 --- Comment #8 from marc at kdab dot com --- I don't think Effective C++ is the benchmark any more, so water under bridges that have already burned, but fwiw: contrary to C.127 these days, I learned this rule as "A base class's destructor should be public and virtual or else protected and non-virtual" (implying that, otherwise, don't use inheritance, but aggregation; could've been from CS:101 from Andrej and Herb).
