[Bug target/98878] Incorrect multilib list for riscv*-rtems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98878 --- Comment #1 from Sebastian Huber --- It may have something to do with TARGET_RISCV_DEFAULT_ABI == ilp32d. The gcc/tm.h in the build tree contains this: gcc/tm.h:#ifndef TARGET_RISCV_DEFAULT_ARCH gcc/tm.h:# define TARGET_RISCV_DEFAULT_ARCH rv32gc gcc/tm.h:#ifndef TARGET_RISCV_DEFAULT_ABI gcc/tm.h:# define TARGET_RISCV_DEFAULT_ABI ilp32d The rv32imafd/ilp32d multilib is the only multilib (except ".") which has also this ABI. This could be checked by adding a rv32imfd/ilp32d multilib for example.
[Bug debug/98875] DWARF5 as default causes perf probe to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875 --- Comment #1 from Richard Biener --- With perf you'll have to use -gdwarf-4 anyway since otherwise it cannot parse debug in my experience. Quite some tools need to be brought up-to-date with DWARF5 yet.
[Bug target/98872] ICE leads to SEGV on MMA test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872 Richard Biener changed: What|Removed |Added Target Milestone|11.0|---
[Bug target/98870] [11 regression] assembler output count off for gcc.target/powerpc/ppc-fortran/ieee128-math.f90 after r11-6959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98866] [11 Regresion] Compile time hog in VRP since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98866 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug target/98878] New: Incorrect multilib list for riscv*-rtems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98878 Bug ID: 98878 Summary: Incorrect multilib list for riscv*-rtems Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: kito at gcc dot gnu.org Reporter: kito at gcc dot gnu.org CC: sebastian.hu...@embedded-brains.de, wilson at gcc dot gnu.org Target Milestone: --- Target: riscv32-rtems Sebastian has reported multilib generation for RTEM is broken after g:a5ad5d5c478ee7bebf057161bb8715ee7d286875. GCC configure: --with-arch=rv32gc --with-abi=ilp32 --target=riscv32-rtems. Before this commit g:a5ad5d5c478ee7bebf057161bb8715ee7d286875: ./gcc/xgcc -print-multi-lib .; rv32i/ilp32;@march=rv32i@mabi=ilp32 rv32im/ilp32;@march=rv32im@mabi=ilp32 rv32imafd/ilp32d;@march=rv32imafd@mabi=ilp32d <-- HERE rv32iac/ilp32;@march=rv32iac@mabi=ilp32 rv32imac/ilp32;@march=rv32imac@mabi=ilp32 rv32imafc/ilp32f;@march=rv32imafc@mabi=ilp32f rv64imafd/lp64d;@march=rv64imafd@mabi=lp64d rv64imafd/lp64d/medany;@march=rv64imafd@mabi=lp64d@mcmodel=medany rv64imac/lp64;@march=rv64imac@mabi=lp64 rv64imac/lp64/medany;@march=rv64imac@mabi=lp64@mcmodel=medany rv64imafdc/lp64d;@march=rv64imafdc@mabi=lp64d rv64imafdc/lp64d/medany;@march=rv64imafdc@mabi=lp64d@mcmodel=medany ./gcc/xgcc -print-multi-directory -march=rv32imafd -mabi=ilp32d rv32imafd/ilp32d After this commit g:a5ad5d5c478ee7bebf057161bb8715ee7d286875: ./gcc/xgcc -print-multi-lib .; rv32i/ilp32;@march=rv32i@mabi=ilp32 rv32im/ilp32;@march=rv32im@mabi=ilp32 rv32iac/ilp32;@march=rv32iac@mabi=ilp32 rv32imac/ilp32;@march=rv32imac@mabi=ilp32 rv32imafc/ilp32f;@march=rv32imafc@mabi=ilp32f rv64imafd/lp64d;@march=rv64imafd@mabi=lp64d rv64imafd/lp64d/medany;@march=rv64imafd@mabi=lp64d@mcmodel=medany rv64imac/lp64;@march=rv64imac@mabi=lp64 rv64imac/lp64/medany;@march=rv64imac@mabi=lp64@mcmodel=medany rv64imafdc/lp64d;@march=rv64imafdc@mabi=lp64d rv64imafdc/lp64d/medany;@march=rv64imafdc@mabi=lp64d@mcmodel=medany ./gcc/xgcc -print-multi-directory -march=rv32imafd -mabi=ilp32d rv32imafd/ilp32d --- The difference is rv32imafd/ilp32d is disappeared from the output of -print-multi-directory, the gcc think that could reuse the default library, but it's not true, but seems like -print-multi-directory is doing right here.
[Bug tree-optimization/98868] [8/9/10/11 Regression] polyhedron rnflow.f90 regression since r8-2555-g344be1fd47d7d64e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98868 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.5 Last reconfirmed||2021-01-29 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Keywords||missed-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug target/98877] [AArch64] Inefficient code generated for tbl NEON intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877 Andrew Pinski changed: What|Removed |Added Depends on||91753 --- Comment #2 from Andrew Pinski --- See PR 91753 for another example. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753 [Bug 91753] Bad register allocation of multi-register types
[Bug target/98877] [AArch64] Inefficient code generated for tbl NEON intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877 --- Comment #1 from Andrew Pinski --- I am 90% sure this is just a register allocation issue.
[Bug middle-end/98209] [8/9/10/11 Regression] printf failed with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209 --- Comment #10 from rguenther at suse dot de --- On Thu, 28 Jan 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #9 from Jakub Jelinek --- > But e.g. for the *intrin.h intrinsics, ignoring the ISA requirements that it > got from the target pragmas is highly undesirable, we do need the diagnostics > and refuse to inline them, otherwise they will ICE all over. > And it is unclear how to differentiate between ISA requirements that were > added > because of the command line option flags vs. ISA requirements that got added > through target pragmas or target attributes. For select cases we have sth like cfun->uses_math and chose to ignore some (target specific) settings based on things we use in the IL. We could go much further here (but of course _not_ scan the IL in the respective function - we'd have to pre-compute things somehow, like adding target specific fields in the inline summary / merging and when computing that, allow the target to amend). I think the *intrin.h example is not really relevant as their direct caller is very unlikely to differ in setting.
[Bug tree-optimization/98848] [9/10/11 regression] vectorizer failed to reduce max pattern since r9-1590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848 --- Comment #5 from rguenther at suse dot de --- On Thu, 28 Jan 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848 > > --- Comment #4 from Jakub Jelinek --- > Alternatively, couldn't we support truncation in the reductions if > SSA_NAME_RANGE_INFO suggests that the values are always in the narrower range? Yes, we probably could. But note that changes in reduction support are quite fragile and we're currently just set up for sign changes (via emitting V_C_E) but not required promotions/demotions so there would be a lot of changes needed. It's also not clear promoting/demoting the reduction IV all the time is doing any good (unless you suggest that we'd magically undo the pattern by promoting the non-reduction OP instead - but that would require even more changes). So I guess the better approach might be to somehow allow late "undoing" of pattern recog (but it's a bit complicated because of how that influences VF compute and also relevant/liveness compute).
[Bug target/98877] New: [AArch64] Inefficient code generated for tbl NEON intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Bug ID: 98877
Summary: [AArch64] Inefficient code generated for tbl NEON
intrinsics
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: spop at gcc dot gnu.org
Target Milestone: ---
The use of NEON intrinsics is inefficient and leads developers to prefer inline
assembly instead of intrinsics.
A similar performance bug for vmlal intrinsics was reported in
https://gcc.gnu.org/PR92665
The code generated by GCC for table lookups is also inefficient:
$ cat red.c
#include "arm_neon.h"
uint8x16_t fun(uint8x16_t lo, uint8x16_t hi, uint8x16_t idx) {
uint8x16x2_t tab = { .val = {lo, hi} };
uint8x16_t res = vqtbl2q_u8(tab, idx);
return res;
}
$ gcc -O3 -S -o- red.c
fun:
mov v4.16b, v0.16b
mov v5.16b, v1.16b
tbl v0.16b, {v4.16b - v5.16b}, v2.16b
ret
$ clang -O3 -S -o- red.c
fun:
tbl v0.16b, { v0.16b, v1.16b }, v2.16b
ret
[Bug demangler/98876] New: demangler-warning: unable to demangle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98876 Bug ID: 98876 Summary: demangler-warning: unable to demangle Product: gcc Version: 7.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: kazantsev.ernest at mail dot ru Target Milestone: --- The demangler in GDB crashes on the symbol below. GNU gdb (Linaro_GDB-2019.02) 8.2.1.20190122 This GDB was configured as "x86_64_arm-linux-gnueabihf". Boost Version 1.70.0 >&"/home/tcwg-buildslave/workspace/tcwg-make-release_0/snapshots/binutils-gdb.git~gdb-8.2-branch/gdb/cp-support.c:1581: > demangler-warning: unable to demangle >'_ZTSN5boost6spirit2x311alternativeINS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS2_INS1_6actionINS1_17binary_lit_parserIihLNS_6endian5orderE1ELj8EEEN7msgpack2v26detailUlRT_E2_EEENS3_IS7_NSA_UlSC_E3_ENS3_IS7_NSA_UlSC_E4_ENS3_INS3_INS1_17any_binary_parserIhLS6_1ELj8EEEZNKSA_UlhhE_clEhhEUlSC_E_EENSA_UlSC_E5_ENS3_ISP_NSA_UlSC_E6_ENS1_8sequenceIS7_NS3_ISM_NSA_UlSC_E7_EEENSW_IS7_NS3_INSL_ItLS6_0ELj16EEENSA_UlSC_E8_EEENSW_IS7_NS3_INSL_IjLS6_0ELj32EEENSA_UlSC_E9_EEENSW_IS7_NS3_INSL_IyLS6_0ELj64EEENSA_UlSC_E10_EEENSW_IS7_NS3_ISM_NSA_UlSC_E11_EEENSW_IS7_NS3_IS11_NSA_UlSC_E12_EEENSW_IS7_NS3_IS16_NSA_UlSC_E13_EEENSW_IS7_NS3_IS1B_NSA_UlSC_E14_EEENSW_IS7_NS3_IS16_NSA_UlSC_E15_EEENSW_IS7_NS3_IS1B_NSA_UlSC_E16_EEENSW_INS3_ISP_NSA_UlSC_E17_EEENS3_INS1_13raw_directiveINSW_INS1_6kleeneINSW_INS3_INS1_10eps_parserENSA_UlSC_E0_EEENS1_8any_charINS0_13char_encoding8standardEEENS3_IS28_NSA_UlSC_E1_EEENSA_UlSC_E18_EEENSW_INSW_IS7_NS3_ISM_NSA_UlSC_E19_ENS3_IS2K_NSA_UlSC_E20_EEENSW_INSW_IS7_NS3_IS11_NSA_UlSC_E21_ENS3_IS2K_NSA_UlSC_E22_EEENSW_INSW_IS7_NS3_IS16_NSA_UlSC_E23_ENS3_IS2K_NSA_UlSC_E24_EEENSW_INSW_IS7_NS3_ISM_NSA_UlSC_E25_ENS3_IS2K_NSA_UlSC_E26_EEENSW_INSW_IS7_NS3_IS11_NSA_UlSC_E27_ENS3_IS2K_NSA_UlSC_E28_EEENSW_INSW_IS7_NS3_IS16_NSA_UlSC_E29_ENS3_IS2K_NSA_UlSC_E30_EEENSW_INSW_INS3_ISP_NSA_UlSC_E31_EEENS27_INSW_IS2A_NS1_4ruleINSA_11array_itemsENS1_11unused_typeELb0ES2I_NSW_INSW_INSW_IS7_NS3_IS11_NSA_UlSC_E32_ES42_EES2I_NSW_INSW_INSW_IS7_NS3_IS16_NSA_UlSC_E33_ES42_EES2I_NSW_INSW_INS3_ISP_NSA_UlSC_E34_EEENS27_INSW_IS2A_NS3X_INSA_9map_itemsES3Z_Lb0ES2I_NSW_INSW_INSW_IS7_NS3_IS11_NSA_UlSC_E35_ES4N_EES2I_NSW_INSW_INSW_IS7_NS3_IS16_NSA_UlSC_E36_ES4N_EES2I_NSW_INS3_IS7_NSA_UlSC_E37_EEENS3_IS2K_NSA_UlSC_E38_EEENSW_INS3_IS7_NSA_UlSC_E39_EEENS3_IS2K_NSA_UlSC_E40_EEENSW_INS3_IS7_NSA_UlSC_E41_EEENS3_IS2K_NSA_UlSC_E42_EEE' > (demangler failed with signal 11)\nUnable to dump core, use `ulimit -c >unlimited' before executing GDB next time.\n" >~"/home/tcwg-buildslave/workspace/tcwg-make-release_0/snapshots/binutils-gdb.git~gdb-8.2-branch/gdb/cp-support.c:1595: > demangler-warning: unable to demangle
[Bug c++/98355] [9/10/11 Regression] ICE in has_attribute, at c-family/c-attribs.c:5628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98355
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #5 from Marek Polacek ---
My earlier fix to emit sorry rather than ICE didn't catch this case; this patch
fixes that:
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -8934,7 +8934,7 @@ cp_parser_has_attribute_expression (cp_parser *parser)
{
if (oper == error_mark_node)
/* Nothing. */;
- else if (type_dependent_expression_p (oper))
+ else if (uses_template_parms (oper))
sorry_at (atloc, "%<__builtin_has_attribute%> with dependent argument "
"not supported yet");
else
[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137 --- Comment #6 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:f8f5388c9e94d4324c31d82b335fa138518e3171 commit r11-6967-gf8f5388c9e94d4324c31d82b335fa138518e3171 Author: Marek Polacek Date: Thu Jan 28 22:18:32 2021 -0500 c++: Fix infinite looping with invalid operator [PR96137] My r11-86 adjusted cp_parser_class_name to do - scope = parser->scope; + scope = parser->scope ? parser->scope : parser->context->object_type; if (scope == error_mark_node) return error_mark_node; but that caused endless looping in cp_parser_type_specifier_seq (the while (true) loop) in this invalid test, because we never set a parser error, therefore cp_parser_type_specifier returned error_mark_node instead of NULL_TREE, and we never issued the "expected type-specifier" error. At first I thought I'd just add cp_parser_simulate_error right before the return, but that regresses crash81.C -- we'd emit multiple errors for "T::X". So the next best thing seemed to revert to pre-r11-86 behavior: return early when parser->scope is bad, otherwise proceed to get the parser error. gcc/cp/ChangeLog: PR c++/96137 * parser.c (cp_parser_class_name): If parser->scope is error_mark_node, return it, otherwise continue. gcc/testsuite/ChangeLog: PR c++/96137 * g++.dg/parse/error63.C: New test.
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 Liu Hao changed: What|Removed |Added CC|lh_mouse at 126 dot com| --- Comment #20 from Liu Hao --- 0. You may ask about this issue on MSYS2 issue tracker [1]. 1. Talk to the community (the 'people'), not an individual person. 2. Stop being noisy. [1] https://github.com/msys2/MINGW-packages/issues
[Bug debug/98875] New: DWARF5 as default causes perf probe to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875 Bug ID: 98875 Summary: DWARF5 as default causes perf probe to hang Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: pc at us dot ibm.com Target Milestone: --- I sent this to gcc-patches, but realized I should open a bug report: -- The subject commit, 3804e937b0e252a7e42632fe6d9f898f1851a49c, causes a failure in the test suite for the IBM Advance Toolchain. The test in question uses "perf probe" to set a tracepoint at "main" in a newly built (with GCC 11) binary of "/bin/ld". With the patch applied, the command enters an infinte loop, calling libdw1 functions but making no progress. The infinite loop can be found in the Linux kernel tools/perf/utils/probe-finder.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/util/probe-finder.c?h=v5.11-rc5#n1190 Reverting this patch permits the command to succeed. -- $ grep VERSION= /etc/os-release VERSION="15-SP2" $ uname -r 5.3.18-22-default $ perf --version perf version 5.3.18 Top of the GCC tree used: ATSRC_PACKAGE_REV=eb9883c1312c Reversion patch: -- $ cat ~/projects/gcc/gcc/gcc-revert-dwarf-5.patch diff --git a/gcc/common.opt b/gcc/common.opt index a8a2b67a99d..7aff4ac6079 100644 --- a/gcc/common.opt +++ b/gcc/common.opt @@ -3179,7 +3179,7 @@ Common Driver JoinedOrMissing Negative(gdwarf-) Generate debug information in default version of DWARF format. gdwarf- -Common Driver Joined UInteger Var(dwarf_version) Init(5) Negative(gstabs) +Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs) Generate debug information in DWARF v2 (or later) format. gdwarf32 -- Failing command: $ perf probe -v -x /path/to/AT/at-next-15.0-0-alpha/bin/ld ldmain=main
[Bug target/79251] PowerPC vec_insert generates store-hit-load if the element number is variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251 luoxhu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from luoxhu at gcc dot gnu.org --- Fixed on master.
[Bug target/98065] [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7024 since r11-5457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98065 Bug 98065 depends on bug 98799, which changed state. Bug 98799 Summary: [11 Regression] vector_set_var ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/98799] [11 Regression] vector_set_var ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799 luoxhu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from luoxhu at gcc dot gnu.org --- Fixed.
[Bug middle-end/98871] Cannot silence -Wmaybe-uninitialized at declaration site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Until this is fixed, moving the suppression pragma above or around the definition of the inc() function should work.
[Bug middle-end/98871] Cannot silence -Wmaybe-uninitialized at declaration site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871 Martin Sebor changed: What|Removed |Added Component|c |middle-end Last reconfirmed||2021-01-29 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98465, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98512 Ever confirmed|0 |1 Keywords||diagnostic CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Blocks||24639 --- Comment #2 from Martin Sebor --- Confirmed. The root cause of the problem is that the #pragma diagnostic suppression machinery consider only one location but that location may be different depending on the warning and depending on inlining. For some warnings it's the location of the call site into which the problem statement has been inlined. For others it might be the original location of the statement itself. -Wuninitialized and -Wmaybe-uninitialized happen to fall into the first category. The solution I posted for pr98465 and pr98512 lets it consider both (or all locations along the inlining stack) and, with an minor extension, makes the suppression work in this case as well. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug c++/81930] [meta-bug] Issues with -Weffc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930 Bug 81930 depends on bug 98841, which changed state. Bug 98841 Summary: wrong ‘operator=’ should return a reference to ‘*this’ [-Weffc++] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/98841] wrong ‘operator=’ should return a reference to ‘*this’ [-Weffc++]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed for GCC 11.
[Bug c++/98841] wrong ‘operator=’ should return a reference to ‘*this’ [-Weffc++]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:850a8ec54c4310d779004299bf9a0dec52324e9e commit r11-6964-g850a8ec54c4310d779004299bf9a0dec52324e9e Author: Jakub Jelinek Date: Fri Jan 29 00:39:00 2021 +0100 c++: Fix -Weffc++ in templates [PR98841] We emit a bogus warning on the following testcase, suggesting that the operator should return *this even when it does that already. The problem is that normally cp_build_indirect_ref_1 ensures that *this is folded as current_class_ref, but in templates (if return type is non-dependent, otherwise check_return_expr doesn't check it) it didn't go through cp_build_indirect_ref_1, but just built another INDIRECT_REF. Which means it then doesn't compare pointer-equal to current_class_ref. The following patch fixes it by doing in build_x_indirect_ref for *this what cp_build_indirect_ref_1 would do. 2021-01-28 Jakub Jelinek PR c++/98841 * typeck.c (build_x_indirect_ref): For *this, return current_class_ref. * g++.dg/warn/effc5.C: New test.
[Bug middle-end/98503] [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 Martin Sebor changed: What|Removed |Added Keywords||patch Component|c |middle-end Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|REOPENED|ASSIGNED --- Comment #11 from Martin Sebor --- Patch to issue -Wstrict-aliasing instead of -Warray-bounds in the subset of cases when the member access is fully in bounds but the enclosing struct is not: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564483.html
[Bug testsuite/98874] New: PowerPC test gcc.target/powerpc/ppc-fortran/pr80108-1.f90 uses wrong dg-options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98874 Bug ID: 98874 Summary: PowerPC test gcc.target/powerpc/ppc-fortran/pr80108-1.f90 uses wrong dg-options Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- In looking at PR target/98870, I noticed that there is a failure of another module (gcc.target/powerpc/ppc-fortran/pr80108-1.f90) because it uses obsolete options: Executing on host: /home3/meissner/fsf-build-ppc64le/work034-if/gcc/xgcc -B/home3/meissner/fsf-build-ppc64le/work034-if/gcc/ /home/meissner/fsf-src/work034/gcc/testsuite/gcc.target/powerpc/ppc-fortran/pr80108-1.f90 -fdiagnostics-plain-output-O -mdejagnu-cpu=405 -mpower9-minmax -mfloat128-type -S -o pr80108-1.s(timeout = 300) spawn -ignore SIGHUP /home3/meissner/fsf-build-ppc64le/work034-if/gcc/xgcc -B/home3/meissner/fsf-build-ppc64le/work034-if/gcc/ /home/meissner/fsf-src/work034/gcc/testsuite/gcc.target/powerpc/ppc-fortran/pr80108-1.f90 -fdiagnostics-plain-output -O -mdejagnu-cpu=405 -mpower9-minmax -mfloat128-type -S -o pr80108-1.s xgcc: error: unrecognized command-line option '-mfloat128-type'; did you mean '-mfloat128'? compiler exited with status 1 XFAIL: gcc.target/powerpc/ppc-fortran/pr80108-1.f90 -O (test for excess errors) Excess errors: xgcc: error: unrecognized command-line option '-mfloat128-type'; did you mean '-mfloat128'?
[Bug target/98870] [11 regression] assembler output count off for gcc.target/powerpc/ppc-fortran/ieee128-math.f90 after r11-6959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870 --- Comment #2 from Peter Bergner --- *** Bug 98873 has been marked as a duplicate of this bug. ***
[Bug target/98873] PowerPC test gcc.target/powerpc/ppc-fortran/ieee128-math.f90 now fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873 Peter Bergner changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #1 from Peter Bergner --- Closing as a dup. *** This bug has been marked as a duplicate of bug 98870 ***
[Bug target/98873] PowerPC test gcc.target/powerpc/ppc-fortran/ieee128-math.f90 now fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873 Michael Meissner changed: What|Removed |Added Target||powerpc64le-gnu-linux Build||powerpc64le-gnu-linux Host||powerpc64le-gnu-linux Last reconfirmed||2021-01-28 Ever confirmed|0 |1 CC||bergner at gcc dot gnu.org, ||dje at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||seurer at us dot ibm.com, ||wschmidt at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org
[Bug target/98872] ICE leads to SEGV on MMA test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872 Peter Bergner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED CC||raji at linux dot vnet.ibm.com, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Target||powerpc*-*-* Target Milestone|--- |11.0 Last reconfirmed||2021-01-28 Ever confirmed|0 |1 --- Comment #1 from Peter Bergner --- Raji reported the above ICE/SEGV. This probably also affects GCC10. Mine.
[Bug target/98873] New: PowerPC test gcc.target/powerpc/ppc-fortran/ieee128-math.f90 now fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873 Bug ID: 98873 Summary: PowerPC test gcc.target/powerpc/ppc-fortran/ieee128-math.f90 now fails Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- In checking in the change on January 28th that changes the built-in function names if long double is IEEE 128-bit, I broke the test gcc.target/powerpc/ppc-fortran/ieee128-math.f90. This is before the change the compiler had changed 'logl' to 'logf128' when long doubles are IEEE 128-bit. After the change, 'logl' becomes '__logieee128' instead.
[Bug target/98872] New: ICE leads to SEGV on MMA test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
Bug ID: 98872
Summary: ICE leads to SEGV on MMA test case
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
bergner@pike:~/gcc/BUGS/MMA$ cat ice3.i
typedef unsigned char vec_t __attribute__((vector_size(16)));
int
foo (vec_t *rowA, vec_t *rowB, vec_t *dst)
{
__vector_quad acc0;
__builtin_mma_xvf32gerpp (, rowB[0], rowA[0]);
__builtin_mma_disassemble_acc (dst, );
}
bergner@pike:~/gcc/BUGS/MMA$
/home/bergner/gcc/build/gcc-fsf-mainline-mma-builtins-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-mma-builtins-debug/gcc -S -O2
-mcpu=power10 ice3.i
during RTL pass: init-regs
ice3.i: In function ‘foo’:
ice3.i:8:1: internal compiler error: Segmentation fault
8 | }
| ^
0x113d6697 crash_signal
/home/bergner/gcc/gcc-fsf-mainline-mma-builtins/gcc/toplev.c:327
0x10b436c4 emit_move_insn(rtx_def*, rtx_def*)
/home/bergner/gcc/gcc-fsf-mainline-mma-builtins/gcc/expr.c:3821
0x1289319b initialize_uninitialized_regs
/home/bergner/gcc/gcc-fsf-mainline-mma-builtins/gcc/init-regs.c:108
0x12893443 execute
/home/bergner/gcc/gcc-fsf-mainline-mma-builtins/gcc/init-regs.c:156
[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137
--- Comment #5 from Marek Polacek ---
A more realistic test:
void
fn ()
{
X.operator T();
}
[Bug c/98871] Cannot silence -Wmaybe-uninitialized at declaration site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871 1zeeky at gmail dot com changed: What|Removed |Added Attachment #50077|0 |1 is obsolete|| --- Comment #1 from 1zeeky at gmail dot com --- Created attachment 50078 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50078=edit actual testcast I played around with the code before posting the patch. This is the actual version I meant to send.
[Bug c/98871] New: Cannot silence -Wmaybe-uninitialized at declaration site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871 Bug ID: 98871 Summary: Cannot silence -Wmaybe-uninitialized at declaration site Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 1zeeky at gmail dot com Target Milestone: --- Created attachment 50077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50077=edit testcase I have some code where I'm relying on the caller to uphold some guarantee in order to properly initialize a variable. gcc correctly detects that the variable maybe left uninitialized. The warning is correct, but I am unable to properly silence this warning because the warning doesn't "show up" at the location where the variable is declared, but where it is used, which is another function, which receives it via pointer. This is probably better explained with the testcase. The setup is a bit weird and looks like it could be minimized. I needed to increase the complexity to thwart static analysis sufficiently such that gcc is unsure if 'max' gets initialized or not. Here's the warning I get: $ gcc -O -Wmaybe-uninitialized maybe-uninit.c maybe-uninit.c: In function ‘main’: maybe-uninit.c:8:9: warning: ‘max.x’ may be used uninitialized in this function [-Wmaybe-uninitialized] 8 | return ++*x; | ^~~~ maybe-uninit.c:15:13: note: ‘max.x’ was declared here 15 | struct Foo max; | ^~~ A site-note: the first line in the error-report states "In function ‘main’" for some reason. I would like to silence the warning from within foo() (my failed attempt at using '#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"' is left in the testcase), since inc() is used in other places where having this warning may be beneficial. The warning would probably have to change to something like maybe-uninit.c: In function ‘foo’: maybe-uninit.c:22:13: warning: 'max.x' is passed to function 'inc', where it may be used uninitialized [-Wmaybe-pass-uninitialized] 22 | return inc(); | ^~ maybe-uninit.c:8:9: note: ‘max.x’ used here 8 | return ++*x; | ^~~~ maybe-uninit.c:15:13: note: ‘max.x’ was declared here 15 | struct Foo max; Alternatively, a variable attribute would work for me as well, e.g. '__attribute__((assume_initialized))'. Locally I use gcc 10.2.0, but through godbolt.org I also tested 10.2.1 and "gcc (trunk)" which describes itself as "gcc (Compiler-Explorer-Build) 11.0.0 20210127 (experimental)".
[Bug tree-optimization/98866] [11 Regresion] Compile time hog in VRP since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98866 --- Comment #1 from Andrew Macleod --- Very large function (16000+ basic blocks) with a lot of exception regions, and a pattern whereby about 300 pointers are live to all the regions. We spend a lot of time propagating an unchanging non-zero property around. My observation is that if a pointer evaluates to [1, +INF] at its definition (ie, the address of something), there will never be a meaningful range to track. a comparison to NULL will be folded as appropriate, and there is no need to track [UNDEFINED] on the un-taken edge as the branch will be folded and the edge removed. The range will remain [1, +INF] on the other edge. a comparison to some other pointer will likewise not result in a change of the range [1, +INF]. Relational/symbolic tracking could decide to fold the comparison away or propagate the ssa_name, but again, it will not change the range from [1, +INF] I think I can extend the invariant tweak to the cache to also include pointers which evaluate to [1, +INF] at their definition to be "invariant" as well and thus not be included in the on-entry cache. This appears to resolve the time issue. testing is underway
[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338 --- Comment #12 from Jan Hubicka --- > > Honza, any ideas on this? > The comment on assert says > /* In LTO mode we may have speculative edges set. */ > gcc_assert (in_lto_p || size_info->size == size_info->self_size); > > Which seems expected because the speculative edges are not accounted by > self_size. So perhaps we simply want to track if there is speculative > edge and disable the sanity check inthat case. https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg01650.html is the patch that intoduced the comment and it seems it does right thing. size_inf->self_size is normally computed from original function body and if speculation is added it is not udpated, while size_info->size contains size adjusted by all speculations and inline decision, so in presence of speculatie edges we can not expect both to match. I will check tomorrow if it makes code to compile. Honza > > Honza
[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338 --- Comment #11 from Jan Hubicka --- > Honza, any ideas on this? The comment on assert says /* In LTO mode we may have speculative edges set. */ gcc_assert (in_lto_p || size_info->size == size_info->self_size); Which seems expected because the speculative edges are not accounted by self_size. So perhaps we simply want to track if there is speculative edge and disable the sanity check inthat case. Honza
[Bug c++/94775] [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 Marek Polacek changed: What|Removed |Added Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in |in strip_typedefs, at |strip_typedefs, at |cp/tree.c:1734 since|cp/tree.c:1734 since |r8-4668-g8a5ee94a082b3d48 |r8-4668-g8a5ee94a082b3d48 --- Comment #19 from Marek Polacek --- Fixed on trunk. Not sure if I want to backport to 10...
[Bug c++/94775] [8/9/10/11 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 --- Comment #18 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:513ee7d2cd9a60339a50dc9c4cba39a8f1c707f0 commit r11-6963-g513ee7d2cd9a60339a50dc9c4cba39a8f1c707f0 Author: Marek Polacek Date: Thu Jan 28 16:21:50 2021 -0500 tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775] A year ago I submitted this patch: ~~ Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built by build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1. When we strip_typedefs the element of the array "const d", we see it's a typedef_variant_p, so we look at its DECL_ORIGINAL_TYPE, which is char, but we need to add the const qualifier, so we call cp_build_qualified_type -> build_qualified_type where get_qualified_type checks to see if we already have such a type by walking the variants list, which in this case is: char -> c -> const char -> const char -> d -> const d Because check_base_type only checks TYPE_ALIGN and not TYPE_USER_ALIGN, we choose the first const char, which has TYPE_USER_ALIGN set. If the element type of an array has TYPE_USER_ALIGN, the array type gets it too. So we can make check_base_type stricter. I was afraid that it might make us reuse types less often, but measuring showed that we build the same amount of types with and without the patch, while bootstrapping. ~~ However, the patch broke a few tests on STRICT_ALIGNMENT platforms and had to be reverted. This is another try. The original patch is kept unchanged, but I added the finalize_type_size hunk that ought to fix the STRICT_ALIGNMENT issues. The problem is that finalize_type_size can clear TYPE_USER_ALIGN on the main variant of a type, but doesn't clear it on any of the variants. Then we end up with types which share the same TYPE_MAIN_VARIANT, but their TYPE_CANONICAL differs and then the usual "canonical types differ for identical types" follows. I've created alignas19.C to exercise this scenario. What happens is: - when parsing the class S we create a type S in xref_tag, - we see alignas(8) so common_handle_aligned_attribute sets T_U_A in S, - we parse the member function fn and build_memfn_type creates a copy of S to add const; this variant has T_U_A set, - we finish_struct S which calls layout_class_type -> finish_record_type -> finalize_size_type where we reset T_U_A in S (but const S keeps it), - finish_non_static_data_member for arr calls maybe_dummy_object with type = S, - maybe_dummy_object calls same_type_ignoring_top_level_qualifiers_p to check if S and TREE_TYPE (current_class_ref), which is const S, are the same, - same_type_ignoring_top_level_qualifiers_p creates cv-unqualified versions of the passed types. Previously we'd use our main variant S when stripping "const S" of const, but since the T_U_A flags don't match (check_base_type), we create a new variant S'. Then we crash in comptypes because S and S' have the same TYPE_MAIN_VARIANT but different TYPE_CANONICALs. With my patch we'll clear T_U_A for S's variants too, and then instead of S' we'll just use S. gcc/ChangeLog: PR c++/94775 * stor-layout.c (finalize_type_size): If we reset TYPE_USER_ALIGN in the main variant, maybe reset it in its variants too. * tree.c (check_base_type): Return true only if TYPE_USER_ALIGN match. (check_aligned_type): Check if TYPE_USER_ALIGN match. gcc/testsuite/ChangeLog: PR c++/94775 * g++.dg/cpp0x/alignas19.C: New test. * g++.dg/warn/Warray-bounds15.C: New test.
[Bug c++/58354] variadic template ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58354 --- Comment #2 from 1zeeky at gmail dot com --- This has been fixed as of gcc 10.2.
[Bug fortran/86470] [8/9/10/11 Regression] [OOP] ICE with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/86470] [8/9/10/11 Regression] [OOP] ICE with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470 --- Comment #12 from CVS Commits --- The releases/gcc-8 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:dd1537924e18e87a44abbd4063de89f7b48c60d5 commit r8-10744-gdd1537924e18e87a44abbd4063de89f7b48c60d5 Author: Harald Anlauf Date: Thu Jan 28 10:13:46 2021 +0100 PR fortran/86470 - ICE with OpenMP, class(*) allocatable gfc_call_malloc should malloc an area of size 1 if no size given. gcc/fortran/ChangeLog: PR fortran/86470 * trans.c (gfc_call_malloc): Allocate area of size 1 if passed size is NULL (as documented). gcc/testsuite/ChangeLog: PR fortran/86470 * gfortran.dg/gomp/pr86470.f90: New test. (cherry picked from commit 33a7a93218b1393d0135e3c4a9ad9ced87808f5e)
[Bug fortran/86470] [8/9/10/11 Regression] [OOP] ICE with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2d9597f400e3456240e4499c9a9bc7023380247f commit r9-9209-g2d9597f400e3456240e4499c9a9bc7023380247f Author: Harald Anlauf Date: Thu Jan 28 10:13:46 2021 +0100 PR fortran/86470 - ICE with OpenMP, class(*) allocatable gfc_call_malloc should malloc an area of size 1 if no size given. gcc/fortran/ChangeLog: PR fortran/86470 * trans.c (gfc_call_malloc): Allocate area of size 1 if passed size is NULL (as documented). gcc/testsuite/ChangeLog: PR fortran/86470 * gfortran.dg/gomp/pr86470.f90: New test. (cherry picked from commit 33a7a93218b1393d0135e3c4a9ad9ced87808f5e)
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-01-28 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug fortran/86470] [8/9/10/11 Regression] [OOP] ICE with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0f42bb8722204fb83dcd001cc4254ad25b969402 commit r10-9308-g0f42bb8722204fb83dcd001cc4254ad25b969402 Author: Harald Anlauf Date: Thu Jan 28 10:13:46 2021 +0100 PR fortran/86470 - ICE with OpenMP, class(*) allocatable gfc_call_malloc should malloc an area of size 1 if no size given. gcc/fortran/ChangeLog: PR fortran/86470 * trans.c (gfc_call_malloc): Allocate area of size 1 if passed size is NULL (as documented). gcc/testsuite/ChangeLog: PR fortran/86470 * gfortran.dg/gomp/pr86470.f90: New test. (cherry picked from commit 33a7a93218b1393d0135e3c4a9ad9ced87808f5e)
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #30 from cqwrteur --- > Great. So build with --disable-libstdcxx-verbose as well and stop > complaining about a feature that other people find useful. But even GCC bootstraps itself with EH, RTTI disabled (of course you are not allowed to use iostream either). How could you convince other people they are actually useful? They are broken tbh.
[Bug target/82150] Produces a branch prefetch which causes a hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150 david.welch at netronome dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #15 from david.welch at netronome dot com --- Please read the errata and not blow off this ticket. The MMU is not being used, this is a verified problem, acknowledge by ARM as well as being independently discovered. The problem has been present and known by ARM for years, as well as being reported a while ago to gnu/gcc. Use the mmu is not a valid solution to fix a known, demonstrable, bug in the compiler.
[Bug target/98870] [11 regression] assembler output count off for gcc.target/powerpc/ppc-fortran/ieee128-math.f90 after r11-6959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870 seurer at gcc dot gnu.org changed: What|Removed |Added CC||meissner at gcc dot gnu.org Target||powerpc64*-linux-gnu Build||powerpc64*-linux-gnu Host||powerpc64*-linux-gnu --- Comment #1 from seurer at gcc dot gnu.org --- commit e11e5d3889f9e54c547efee50fa1b72b50f0f265 Author: Michael Meissner Date: Thu Jan 28 11:30:46 2021 -0500
[Bug target/98870] New: [11 regression] assembler output count off for gcc.target/powerpc/ppc-fortran/ieee128-math.f90 after r11-6959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870 Bug ID: 98870 Summary: [11 regression] assembler output count off for gcc.target/powerpc/ppc-fortran/ieee128-math.f90 after r11-6959 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:e11e5d3889f9e54c547efee50fa1b72b50f0f265, r11-6959 FAIL: gcc.target/powerpc/ppc-fortran/ieee128-math.f90 -O scan-assembler \\mbl logf128\\M
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #29 from cqwrteur ---
(In reply to Jakub Jelinek from comment #23)
> And memcpy must be provided as documented in the GCC documentation:
> Most of the compiler support routines used by GCC are present in
> @file{libgcc}, but there are a few exceptions. GCC requires the
> freestanding environment provide @code{memcpy}, @code{memmove},
> @code{memset} and @code{memcmp}.
> Finally, if @code{__builtin_trap} is used, and the target does
> not implement the @code{trap} pattern, then GCC emits a call
> to @code{abort}.
I am sure I did not understand anything wrong. The rule is simple, if you use
gcc, you must use libgcc. libgcc provides those facilities.
https://wiki.osdev.org/Libgcc
__builtin_trap() is always faster than std::terminate(), even it actually emits
a call to std::abort(), because std::terminate() requires atomic to sync the
terminate_handler. The problem with std::terminate() is that it does not work
like operator new where it is weak alias. You still get bloat and dependency to
std::abort() even you are using set_terminate_handle().
if we are using __builtin_trap() on platforms like x86_64, they emit ud
instructions and use that to terminate is fast and avoid dependency on libc,
(particularly we mean glibc here.)
[Bug fortran/83927] Type-Bound Procedure on element of Derived Type PARAMETER Array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83927 --- Comment #5 from Dominique d'Humieres --- > Seems fixed... I'll try to commit the test case this evening. I still get 31 | M = v_array_par(1)%MyFunc() | 1 Error: Cannot convert TYPE(mytype) to REAL(4) at (1) with module Types implicit none type MyType real :: x contains procedure :: MyFunc end type contains pure function MyFunc(this) result(M) class(MyType), intent(in) :: this real :: M M = this%x end function end module program Main use Types implicit none type(MyType), parameter :: v_array_par(1) = [ MyType(1) ] type(MyType), parameter :: v_scalar_par = MyType(1) type(MyType) :: v_array(1) real :: M M = v_array_par(1)%MyFunc() print *, M ! M = v_scalar_par%MyFunc() ! print *, M v_array(1) = MyType(1) M = v_array(1)%MyFunc() print *, M end program
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #24 from Jakub Jelinek ---
Actually asm (".global pthread_cond_init"); (etc.) is probably better, doesn't
need relocations, just adds the symbol to the symtab as non-weak.
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 --- Comment #23 from Jakub Jelinek --- Unaware of extern directive in gas. I'd think (but it would need to be surrounded by configury checks) that something like: .section .gnu.need.pthread_cond, "e" .8byte pthread_cond_init ... .previous where you'd list all the symbols you want to force in should work though, and wouldn't actually waste .data or .rodata.
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #22 from Jonathan Wakely ---
In that case it finds the no-op symbol in libc.so.6 and doesn't crash.
$ g++ cv.C -g -Wl,--trace-symbol=pthread_cond_destroy
/usr/bin/ld: /lib64/libc.so.6: definition of pthread_cond_destroy
This fixes the static linking case:
--- a/libstdc++-v3/src/c++11/condition_variable.cc
+++ b/libstdc++-v3/src/c++11/condition_variable.cc
@@ -31,9 +31,19 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
- condition_variable::condition_variable() noexcept = default;
+ condition_variable::condition_variable() noexcept
+ {
+#if defined __GLIBC__ && ! defined _GLIBCXX_SHARED
+asm("extern pthread_cond_init");
+#endif
+ }
- condition_variable::~condition_variable() noexcept = default;
+ condition_variable::~condition_variable() noexcept
+ {
+#if defined __GLIBC__ && ! defined _GLIBCXX_SHARED
+asm("extern pthread_cond_destroy");
+#endif
+ }
void
condition_variable::wait(unique_lock& __lock) noexcept
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #28 from cqwrteur --- (In reply to cqwrteur from comment #27) > > But portable code can't rely on deterministict exceptions either, yet you > > insist that it's essential and you can't live without it. It seems you're > > quite happy to rely on non-standard things when it suits you, but when it > > doesn't it's completely unusable. Because you're a timewaster. > > It will be portable when it is a part of the C++ standard. > > > (In reply to cqwrteur from comment #25) > > > I mean you can try to fix it a little. However, it breaks ABI. > > > > So do deterministic exceptions. > > It does not. No existing code will be broken because of deterministic > exceptions. > > > Please go away and write your own compiler or language. > > Rust folks did that. Are you happy with it? > > I have no interest in writing my own compiler or language. I am more > interested in how to fixing existing things. I was a lover of C++ EH and I > completely hate C++ exceptions when I understand the ugliness beneath it. > That is why deterministic exceptions are important. > > Same with C++ iostream, they need to be replaced with something else too. That is why Herb Sutter said "digging the hole we already jumped into". Those fixing makes nonsense, to be honest.
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 --- Comment #21 from Jakub Jelinek --- So how does that work for dynamic linking when -lpthread is not linked in? Does it crash too?
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #27 from cqwrteur --- > But portable code can't rely on deterministict exceptions either, yet you > insist that it's essential and you can't live without it. It seems you're > quite happy to rely on non-standard things when it suits you, but when it > doesn't it's completely unusable. Because you're a timewaster. It will be portable when it is a part of the C++ standard. > (In reply to cqwrteur from comment #25) > > I mean you can try to fix it a little. However, it breaks ABI. > > So do deterministic exceptions. It does not. No existing code will be broken because of deterministic exceptions. > Please go away and write your own compiler or language. Rust folks did that. Are you happy with it? I have no interest in writing my own compiler or language. I am more interested in how to fixing existing things. I was a lover of C++ EH and I completely hate C++ exceptions when I understand the ugliness beneath it. That is why deterministic exceptions are important. Same with C++ iostream, they need to be replaced with something else too.
[Bug target/82150] Produces a branch prefetch which causes a hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150 Richard Earnshaw changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #14 from Richard Earnshaw --- The code generated is architecturally correct. If your core is prefetching from addresses that are not valid then this is indicative that the MMU is incorrectly configured for your system. Prefetches will NOT be attempted from unmapped pages, or pages that are mapped as device memory. So you need to find out why your memory system has not been correctly set up. There's no bug in GCC here.
[Bug target/98862] Complex reduction support in offload region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98862 --- Comment #3 from Ye Luo --- Cool. -foffload=-latomic resolved my problem.
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 --- Comment #20 from Jonathan Wakely --- I don't think so. The linker just doesn't resolve the undefined weak symbol for pthread_cond_destroy is left equal to zero, and so there's a segfault when it gets called. $ g++ cv.C -static -g -Wl,--trace-symbol=pthread_cond_destroy -pthread /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/10/libstdc++.a(condition_variable.o): reference to pthread_cond_destroy IIUC it's not finding the definition in libc.a, or any definition at all.
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #26 from Jonathan Wakely --- (In reply to cqwrteur from comment #24) > (In reply to Jonathan Wakely from comment #22) > > (In reply to cqwrteur from comment #20) > > > 1. Freestanding C++ in the current situation is very problematic. (You do > > > not have memcpy, you do not have std::move. You do not have std::forward. > > > You do not have std::addressof(). > > > > Freestanding libstdc++ provides std::move, std::forward and std::addressof. > > But that is actually not standard compliant. I think what you mean is it's not portable and strictly compliant code can't rely on it. It's is standard compliant for our freestanding mode to provide more than the minimum required. But portable code can't rely on deterministict exceptions either, yet you insist that it's essential and you can't live without it. It seems you're quite happy to rely on non-standard things when it suits you, but when it doesn't it's completely unusable. Because you're a timewaster. (In reply to cqwrteur from comment #25) > I mean you can try to fix it a little. However, it breaks ABI. So do deterministic exceptions. Please go away and write your own compiler or language.
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #25 from cqwrteur --- > > 1. Freestanding C++ in the current situation is very problematic. (You do > > not have memcpy, you do not have std::move. You do not have std::forward. > > You do not have std::addressof(). you do not have std::array.) However, you > > have an exception handling support. > > But no dependency on stdio. That does not mean it has no dependency. It depends on malloc/free which is something you cannot avoid at all. BTW, there are other issues with the implementation EH unwinder, it walks stack twice for just more debugging information. Guess what is the information consumed for? They output to stdio lol. Your termination with multiple fputs calls also has issues even in a hosted environment. Because it is not process-safe. When multiple processes throw eh at the same time, they end up corrupting log files. (I did see that when i was doing testing on the burden of multiple process TCP servers.) I guess changing that to writev(2) might solve part of the problems but writev(2) does not guarantee process safety for console or other I/O devices. > > > 2. What's the point of reporting a bug when building libstdc++ with GNU > > So it can be fixed, duh. > > > newlib just works much better and you have an entire hosted toolchain that > > will not break compilation? The only problem is that you never enable EH. > > I did report bugs before. However, it was not fixed. I am not going to try > > it again tbh since newlib works just fine. > > Great. So build with --disable-libstdcxx-verbose as well and stop > complaining about a feature that other people find useful. > > Maybe we should make that the default for --with-newlib builds. That might > be a useful improvement. More useful than your usual hyperbole and > timewasting anyway. I mean you can try to fix it a little. However, it breaks ABI. The effort does not worth the cost. More fundamental issues like binary bloat would never get fixed. Unfortunately, the C++ compiler does not remove dead virtual functions. The entire C++ exceptions are built on virtual function calls. That stuff all add bloat you do not want. Recently I just remove one virtual method of EH and the binary size reduces 50KB for hello world. If the exceptions are just designed for termination, it is nowhere better than killing the process and restarted it again. (With __builtin_trap() you even get higher performance than EH in the happy path because it reduces the burden of CPU instruction cache) For servers hosted on the internet, using EH is a disaster since it is basically DDOS. The attacker can inject invalid input to make the process keep throwing EH which ends up crashing. (There are security papers talking about that. I can even show you). EH does not work for cryptography either since cryptography requires deterministic. Any gap between timing can be a side-channel.
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #24 from cqwrteur --- (In reply to Jonathan Wakely from comment #22) > (In reply to cqwrteur from comment #20) > > 1. Freestanding C++ in the current situation is very problematic. (You do > > not have memcpy, you do not have std::move. You do not have std::forward. > > You do not have std::addressof(). > > Freestanding libstdc++ provides std::move, std::forward and std::addressof. But that is actually not standard compliant. You may end up with another toolchain that does not provide those facilities and you have troubles now. The only option is to use newlib basically and that is why newlib is nowadays the standard libc for embedded systems.
[Bug target/97701] [10/11 Regression] aarch64: ICE in extract_constrain_insn since r10-4447-g095f78c6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701 --- Comment #7 from Vladimir Makarov --- I've reproduced it on gcc-10 branch. For some reason, LRA does not change register class for reload pseudo. This bug will take some time for a fix as the fix will probably affect very sensitive part of LRA and will need a lot of testing. But I guess the patch will be ready on the next week.
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #23 from Jakub Jelinek ---
And memcpy must be provided as documented in the GCC documentation:
Most of the compiler support routines used by GCC are present in
@file{libgcc}, but there are a few exceptions. GCC requires the
freestanding environment provide @code{memcpy}, @code{memmove},
@code{memset} and @code{memcmp}.
Finally, if @code{__builtin_trap} is used, and the target does
not implement the @code{trap} pattern, then GCC emits a call
to @code{abort}.
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #22 from Jonathan Wakely --- (In reply to cqwrteur from comment #20) > 1. Freestanding C++ in the current situation is very problematic. (You do > not have memcpy, you do not have std::move. You do not have std::forward. > You do not have std::addressof(). Freestanding libstdc++ provides std::move, std::forward and std::addressof.
[Bug c++/98869] Allowing mapping this in OpenMP target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98869 --- Comment #2 from Jakub Jelinek --- It is required by OpenMP 4.5, and the OpenMP 5.0 support that allows this is not finished yet.
[Bug c++/98869] Allowing mapping this in OpenMP target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98869 --- Comment #1 from Ye Luo --- Full source code at https://github.com/QMCPACK/qmcpack/blob/a23584738485bb7c948d0ba1841c669fe76500b6/src/Particle/SoaDistanceTableABOMPTarget.h#L63
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #21 from Jonathan Wakely --- (In reply to cqwrteur from comment #20) > (In reply to Jonathan Wakely from comment #19) > > (In reply to cqwrteur from comment #16) > > > That does not work in the real-world since your libstdc++'s freestanding > > > header never works correctly, (you get compilation errors). > > > > Try reporting a bug about *that* next time (except don't, I don't want any > > more stupidity from you). > > Let me be more clear. That would be a welcome change from your usual nonsense. > 1. Freestanding C++ in the current situation is very problematic. (You do > not have memcpy, you do not have std::move. You do not have std::forward. > You do not have std::addressof(). you do not have std::array.) However, you > have an exception handling support. But no dependency on stdio. > 2. What's the point of reporting a bug when building libstdc++ with GNU So it can be fixed, duh. > newlib just works much better and you have an entire hosted toolchain that > will not break compilation? The only problem is that you never enable EH. > I did report bugs before. However, it was not fixed. I am not going to try > it again tbh since newlib works just fine. Great. So build with --disable-libstdcxx-verbose as well and stop complaining about a feature that other people find useful. Maybe we should make that the default for --with-newlib builds. That might be a useful improvement. More useful than your usual hyperbole and timewasting anyway.
[Bug c++/98869] New: Allowing mapping this in OpenMP target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98869 Bug ID: 98869 Summary: Allowing mapping this in OpenMP target Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: xw111luoye at gmail dot com Target Milestone: --- this restriction seems unnecessary. /home/yeluo/opt/qmcpack/src/Particle/SoaDistanceTableABOMPTarget.h:63:42: error: ‘this’ allowed in OpenMP only in ‘declare simd’ clauses 63 | #pragma omp target enter data map(to:this[:1])
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 --- Comment #19 from Jakub Jelinek --- Is that because some functions are also in libc.a and not just in libpthread.a?
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #20 from cqwrteur --- (In reply to Jonathan Wakely from comment #19) > (In reply to cqwrteur from comment #16) > > That does not work in the real-world since your libstdc++'s freestanding > > header never works correctly, (you get compilation errors). > > Try reporting a bug about *that* next time (except don't, I don't want any > more stupidity from you). Let me be more clear. 1. Freestanding C++ in the current situation is very problematic. (You do not have memcpy, you do not have std::move. You do not have std::forward. You do not have std::addressof(). you do not have std::array.) However, you have an exception handling support. 2. What's the point of reporting a bug when building libstdc++ with GNU newlib just works much better and you have an entire hosted toolchain that will not break compilation? The only problem is that you never enable EH. I did report bugs before. However, it was not fixed. I am not going to try it again tbh since newlib works just fine. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1105r0.html Bare metal gcc 4.8 with newlib undefined reference to "__exidx_end" undefined reference to "__exidx_start" undefined reference to "_exit" undefined reference to "_sbrk" undefined reference to "_kill" undefined reference to "_getpid" undefined reference to "_write" undefined reference to "_close" undefined reference to "_fstat" undefined reference to "_isatty" undefined reference to "_lseek" undefined reference to "_read"
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 --- Comment #18 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #17) > (In reply to Jakub Jelinek from comment #16) > The example in comment 0 fails on Fedora. Nothing in libstdc++.a causes > anything from libpthread.o to be used. However, any real program that uses std::condition_variable is likely to also use std::thread, and that will cause a dependency on symbols in libpthread.o
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #19 from Jonathan Wakely --- (In reply to cqwrteur from comment #16) > That does not work in the real-world since your libstdc++'s freestanding > header never works correctly, (you get compilation errors). Try reporting a bug about *that* next time (except don't, I don't want any more stupidity from you).
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #18 from Jonathan Wakely --- (In reply to cqwrteur from comment #17) > No one wants to tweak around compiler options since compiler options can > always break something tbh. OK, go away and stop wasting our time then. Write your own compiler or your own language and stop being a pain here.
[Bug middle-end/98209] [8/9/10/11 Regression] printf failed with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- But e.g. for the *intrin.h intrinsics, ignoring the ISA requirements that it got from the target pragmas is highly undesirable, we do need the diagnostics and refuse to inline them, otherwise they will ICE all over. And it is unclear how to differentiate between ISA requirements that were added because of the command line option flags vs. ISA requirements that got added through target pragmas or target attributes.
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 --- Comment #17 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #16) > Are those weak refs from libstdc++.a objects or from the user *.o files? >From libstdc++.a > If the former, perhaps we could declare some libstdc++ APIs (related to > threading) as requiring linking of -lpthread and made them non-weak in > libstdc++.a. Yes, I think we should just use the non-weak pthread_xxx symbols directly when !defined(_GLIBCXX_SHARED) and rely on those sections from libstdc++.a not being used unless they're needed. > I don't really see how can one reproduce this on Fedora/RHEL/CentOS where > libpthread.a > contains a single libpthread.o and therefore it is either you link no thread > support at all, or link it completely. The example in comment 0 fails on Fedora. Nothing in libstdc++.a causes anything from libpthread.o to be used.
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #17 from cqwrteur --- (In reply to Jonathan Wakely from comment #15) > > > (In reply to cqwrteur from comment #12) > > > > stdio.h should not get included in any circumstances for EH. You are > > > > implementing the operating system, but you need to enable EH by the > > > > standard > > > > and EH relies on stdio. Chicken-egg problem. > > > > > > It doesn't depend on stdio though. What are you talking about? > > > > https://github.com/gcc-mirror/gcc/blob/ > > e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/ > > vterminate.cc#L93 > > Which is disabled in freestanding, and can be optionally disabled in hosted. > > This is an OPTIONAL feature of libstdc++, not something that exception > handling intrinsically relies on. If you don't want it, you don't have to > use it. > > And if you're implementing the OS then you're using freestanding and it's > automatically disabled. Looks at line 27 in that file. > > Once again you are talking out of your backside. > > Stop wasting our time. No one wants to tweak around compiler options since compiler options can always break something tbh. There is a reason why C++ is terrible in embedded systems and bare-metal operating systems. What Linus said was totally correct from a kernel dev perspective.
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #16 from cqwrteur --- (In reply to Jonathan Wakely from comment #15) > > > (In reply to cqwrteur from comment #12) > > > > stdio.h should not get included in any circumstances for EH. You are > > > > implementing the operating system, but you need to enable EH by the > > > > standard > > > > and EH relies on stdio. Chicken-egg problem. > > > > > > It doesn't depend on stdio though. What are you talking about? > > > > https://github.com/gcc-mirror/gcc/blob/ > > e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/ > > vterminate.cc#L93 > > Which is disabled in freestanding, and can be optionally disabled in hosted. > > This is an OPTIONAL feature of libstdc++, not something that exception > handling intrinsically relies on. If you don't want it, you don't have to > use it. > > And if you're implementing the OS then you're using freestanding and it's > automatically disabled. Looks at line 27 in that file. > > Once again you are talking out of your backside. > > Stop wasting our time. That does not work in the real-world since your libstdc++'s freestanding header never works correctly, (you get compilation errors). In reality, people just use a "hosted toolchain" with GNU newlib. A "hosted version" of real freestanding. Or you do not even have proper headers to run C++.
[Bug target/98730] vceqzq_p64 does not generate vceq with immediate 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98730 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Christophe Lyon --- Now fixed on trunk
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #15 from Jonathan Wakely --- > > (In reply to cqwrteur from comment #12) > > > stdio.h should not get included in any circumstances for EH. You are > > > implementing the operating system, but you need to enable EH by the > > > standard > > > and EH relies on stdio. Chicken-egg problem. > > > > It doesn't depend on stdio though. What are you talking about? > > https://github.com/gcc-mirror/gcc/blob/ > e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/ > vterminate.cc#L93 Which is disabled in freestanding, and can be optionally disabled in hosted. This is an OPTIONAL feature of libstdc++, not something that exception handling intrinsically relies on. If you don't want it, you don't have to use it. And if you're implementing the OS then you're using freestanding and it's automatically disabled. Looks at line 27 in that file. Once again you are talking out of your backside. Stop wasting our time.
[Bug target/98730] vceqzq_p64 does not generate vceq with immediate 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98730 --- Comment #5 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:31a0ab9213f780d2fa1da6e4879df214c0f247f9 commit r11-6961-g31a0ab9213f780d2fa1da6e4879df214c0f247f9 Author: Christophe Lyon Date: Thu Jan 28 17:55:45 2021 + arm: Adjust cost of vector of constant zero Neon vector comparisons have a dedicated version when comparing with constant zero: it means its cost is free. Adjust the cost in arm_rtx_costs_internal accordingly, for Neon only, since MVE does not support this. 2021-01-28 Christophe Lyon gcc/ PR target/98730 * config/arm/arm.c (arm_rtx_costs_internal): Adjust cost of vector of constant zero for comparisons. gcc/testsuite/ PR target/98730 * gcc.target/arm/simd/vceqzq_p64.c: Update expected result.
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 --- Comment #16 from Jakub Jelinek --- Are those weak refs from libstdc++.a objects or from the user *.o files? If the former, perhaps we could declare some libstdc++ APIs (related to threading) as requiring linking of -lpthread and made them non-weak in libstdc++.a. I don't really see how can one reproduce this on Fedora/RHEL/CentOS where libpthread.a contains a single libpthread.o and therefore it is either you link no thread support at all, or link it completely.
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #14 from cqwrteur --- (In reply to Jonathan Wakely from comment #13) > (In reply to cqwrteur from comment #11) > > Functions without thread-safety are always terrible. Like all functions in > > cctype. They should be avoided like plague. > > It's thread-safe though. What are you talking about? It calls std::abort() and std::abort() will close FILE* and FILE* might not be thread-safe. BTW std::terminate() is slow compared to compiler intrinsic like __builtin_trap(). > (In reply to cqwrteur from comment #12) > > stdio.h should not get included in any circumstances for EH. You are > > implementing the operating system, but you need to enable EH by the standard > > and EH relies on stdio. Chicken-egg problem. > > It doesn't depend on stdio though. What are you talking about? https://github.com/gcc-mirror/gcc/blob/e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/vterminate.cc#L93
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #13 from Jonathan Wakely --- (In reply to cqwrteur from comment #11) > Functions without thread-safety are always terrible. Like all functions in > cctype. They should be avoided like plague. It's thread-safe though. What are you talking about? (In reply to cqwrteur from comment #12) > stdio.h should not get included in any circumstances for EH. You are > implementing the operating system, but you need to enable EH by the standard > and EH relies on stdio. Chicken-egg problem. It doesn't depend on stdio though. What are you talking about?
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 --- Comment #15 from Jonathan Wakely --- And the static libc++.a doesn't use weak symbols, so you need to link to libpthread youself, and the necessary symbols get pulled in correctly. The problem for libstdc++.a is that the weak symbols do not cause the libpthread.a symbols to get linked into the binary.
[Bug target/98065] [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7024 since r11-5457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98065 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||seurer at gcc dot gnu.org --- Comment #6 from seurer at gcc dot gnu.org --- This appears to be fixed from testing with latest trunk.
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #12 from cqwrteur --- (In reply to Jonathan Wakely from comment #10) > (In reply to cqwrteur from comment #3) > > Relying on stdio.h even stdio.h is not freestanding. > > Nonsense. stdio.h should not get included in any circumstances for EH. You are implementing the operating system, but you need to enable EH by the standard and EH relies on stdio. Chicken-egg problem.
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 --- Comment #14 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #13) > Maybe libc++ doesn't bother with supporting not linking against -lpthread. libc++ is linked to libpthread.so unconditionally.
[Bug rtl-optimization/97684] [11 Regression] ICE in reg_preferred_class, at reginfo.c:789 by r11-4577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97684 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #7 from seurer at gcc dot gnu.org --- The two bits of code shown seem to compile fine now on powerpc. Is this done then?
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #11 from cqwrteur --- (In reply to Jonathan Wakely from comment #10) > (In reply to cqwrteur from comment #3) > > Relying on stdio.h even stdio.h is not freestanding. > > Nonsense. > > (In reply to cqwrteur from comment #4) > > BTW. std::terminate() is not thread-safe which is terrible. > > Nonsense. Functions without thread-safety are always terrible. Like all functions in cctype. They should be avoided like plague.
[Bug c++/98861] I want deterministic exceptions (Herbception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861 --- Comment #10 from Jonathan Wakely --- (In reply to cqwrteur from comment #3) > Relying on stdio.h even stdio.h is not freestanding. Nonsense. (In reply to cqwrteur from comment #4) > BTW. std::terminate() is not thread-safe which is terrible. Nonsense.
[Bug tree-optimization/98848] [9/10/11 regression] vectorizer failed to reduce max pattern since r9-1590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848 --- Comment #4 from Jakub Jelinek --- Alternatively, couldn't we support truncation in the reductions if SSA_NAME_RANGE_INFO suggests that the values are always in the narrower range?
[Bug libstdc++/92546] Large increase in preprocessed file sizes in C++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546 Jonathan Wakely changed: What|Removed |Added Target Milestone|10.3|12.0 Summary|[10/11 Regression] Large|Large increase in |increase in preprocessed|preprocessed file sizes in |file sizes in C++2a mode|C++2a mode --- Comment #18 from Jonathan Wakely --- Definitely defer. I think we could remove the regression marker now too.
[Bug tree-optimization/98848] [9/10/11 regression] vectorizer failed to reduce max pattern since r9-1590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[9/10/11 regression]|[9/10/11 regression] |vectorizer failed to reduce |vectorizer failed to reduce |max pattern.|max pattern since r9-1590 --- Comment #3 from Jakub Jelinek --- Regressed with r9-1590-g370c2ebe8fa20e0812cd2d533d4ed38ee2d37c85
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 --- Comment #13 from Jakub Jelinek --- Maybe libc++ doesn't bother with supporting not linking against -lpthread.
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 Keegan Saunders changed: What|Removed |Added CC||ksaunders at nowsecure dot com --- Comment #12 from Keegan Saunders --- This behaviour does not occur with clang when statically linking libc++. It is, however, still an issue on clang and gcc when using libstdc++. It is still possible to reproduce this issue with: clang version 11.0.0 (Fedora 11.0.0-2.fc33) and g++ (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9) As libc++ links against glibc, this appears to be strictly an issue with libstdc++ rather than glibc.
