[Bug tree-optimization/89430] A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 --- Comment #16 from Tamar Christina --- I think this can be closed now right?
[Bug tree-optimization/89430] A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 --- Comment #17 from Jiangning Liu --- Yes. > -Original Message- > From: tnfchris at gcc dot gnu.org > Sent: Friday, November 11, 2022 4:48 PM > To: JiangNing Liu > Subject: [Bug tree-optimization/89430] A missing ifcvt optimization to > generate csel > > [EXTERNAL EMAIL NOTICE: This email originated from an external sender. > Please be mindful of safe email handling and proprietary information > protection practices.] > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 > > --- Comment #16 from Tamar Christina --- I > think this can be closed now right? > > -- > You are receiving this mail because: > You reported the bug.
[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612 --- Comment #1 from Rainer Orth --- Besides, the m2rte plugin is incorrectly named on Darwin, thus unusable: cc1gm2: fatal error: inaccessible plugin file /var/gcc/modula-2/10.7-gcc/./gcc/plugin/m2rte.dylib expanded from short plugin name m2rte: No such file or directory compilation terminated. There's code in gcc/jit/Make-lang.in handling the same situation. To get further along, I've just manually added a symlink for now.
[Bug modula2/107629] New: runtime libs don't link on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107629 Bug ID: 107629 Summary: runtime libs don't link on macOS Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin11.4.2 Target: x86_64-apple-darwin11.4.2 Build: x86_64-apple-darwin11.4.2 The gm2 runtime libs don't link on macOS, e.g. libm2log: Undefined symbols for architecture x86_64: "_DynamicStrings_ConCat", referenced from: _FileSystem_Create in FileSystem.o _InOut_OpenInput in InOut.o _InOut_OpenOutput in InOut.o _RealConversions_LongRealToString in RealConversions.o _Pad.part.0 in RealInOut.o _Strings_Delete in Strings.o _Strings_Insert in Strings.o ... and many more. While libtool knows about the ld option to lift that requirement, there seems to be no way to activate it. For now, I've just manually added LDFLAGS = -Wl,-undefined -Wl,dynamic_lookup to the various libgm2 Makefiles. I suspect something along the lines of libitm/configure.tgt or libsanitizer/configure.tgt will be necessary to handle this for real. However, the best way would be to make the libs self-contained, actually, so the issue would just vanish.
[Bug modula2/107629] runtime libs don't link on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107629 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
[Bug modula2/107630] New: runtime libs should be self-contained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107630 Bug ID: 107630 Summary: runtime libs should be self-contained Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Prompted by PR modula2/107629, I checked the runtime libs on Solaris and Linux, and (not unexpectedly) found the same issue: with the exception of libm2min.so, none of the gm2 runtime libs are self-contained, each containing tons of undefined references. This is considered bad style at least (cf. the libtool manual, among others), and with a small (and intentional) exception in libgo.so, all other gcc runtime libs are, as they should be. It would be good if libgm2 would follow suite, making PR modula2/107629 vanish. I've had a quick look myself, but things seem not so easy since some of the unresolved symbols are defined in several of the other runtime libs, plus there are references to completely difference libs (libm2pim -> libstdc++) or objects (libm2pim -> gm2-gcc/init.o).
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #5 from Richard Biener --- Did you try -fstrict-enums?
[Bug middle-end/107626] STRICT_ALIGNMENT and TARGET_SLOW_UNALIGNED_ACCESS usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107626 --- Comment #2 from Richard Biener --- Some backends use TARGET_SLOW_UNALIGNED_ACCESS to indicate that some modes adhere to STRICT_ALIGNMENT and unaligned accesses will trap though to avoid setting STRICT_ALIGNMENT which applies to all modes.
[Bug tree-optimization/89430] A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 Tamar Christina changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Tamar Christina --- Fixed in GCC 11
[Bug rtl-optimization/46279] cmov not hoisted out of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46279 Bug 46279 depends on bug 89430, which changed state. Bug 89430 Summary: A missing ifcvt optimization to generate csel https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 89430, which changed state. Bug 89430 Summary: A missing ifcvt optimization to generate csel https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug target/107627] [13 Regression] int128_t shift generates extra xor/or.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107627 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-11-11 Status|UNCONFIRMED |NEW
[Bug modula2/107631] New: many tests don't link on Mac OS X 10.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631
Bug ID: 107631
Summary: many tests don't link on Mac OS X 10.7
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: iains at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-apple-darwin11.4.2
Target: x86_64-apple-darwin11.4.2
Build: x86_64-apple-darwin11.4.2
After I got gm2 and libgm2 to build on Mac OS X 10.7, test results aren't too
bad:
=== gm2 Summary for unix ===
# of expected passes11604
# of unexpected failures108
# of unresolved testcases 66
=== gm2 Summary for unix/-m32 ===
# of expected passes10380
# of unexpected failures708
# of unresolved testcases 690
=== gm2 Summary ===
# of expected passes21984
# of unexpected failures816
# of unresolved testcases 756
Fortunately, the causes for failure are limited:
* 64-bit:
/vol/gcc/src/hg/master/modula-2/gcc/testsuite/gm2/iso/pass/realbitscast.mod: In
function '_M2_realbitscast_init':
/vol/gcc/src/hg/master/modula-2/gcc/testsuite/gm2/iso/pass/realbitscast.mod:66:11:
error: cannot convert expression, only base types can be converted
compiler exited with status 1
FAIL: gm2/iso/pass/realbitscast.mod, -g
Undefined symbols for architecture x86_64:
"_scalbf", referenced from:
_Builtins_scalbf in libm2pim.a(Builtins.o)
(maybe you meant: _Builtins_scalbf)
"_scalbl", referenced from:
_Builtins_scalbl in libm2pim.a(Builtins.o)
(maybe you meant: _Builtins_scalbl, _Builtins_scalblnf , _Builtins_scalbln
, _Builtins_scalblnl )
"_significandf", referenced from:
_Builtins_significandf in libm2pim.a(Builtins.o)
(maybe you meant: _Builtins_significandf)
"_significandl", referenced from:
_Builtins_significandl in libm2pim.a(Builtins.o)
(maybe you meant: _Builtins_significandl)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gm2/iso/run/pass/long.mod compilation, -g
unsuccessful link
UNRESOLVED: gm2/iso/run/pass/long.mod execution, -g (link failed)
and many more instances, always those four. Source is
gcc/m2/gm2-libs/Builtins.{def,mod}.
* 32-bit:
/var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//ccxlVpeL.s:553:non-relocatable
subtraction expression, "__M2_termios_ctor" minus "L7$pb"
/var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//ccxlVpeL.s:553:symbol:
"__M2_termios_ctor" can't be undefined in a subtraction expression
/var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//ccxlVpeL.s:545:non-relocatable
subtraction expression, "__M2_errno_ctor" minus "L7$pb"
/var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//ccxlVpeL.s:545:symbol:
"__M2_errno_ctor" can't be undefined in a subtraction expression
/var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//ccxlVpeL.s:492:non-relocatable
subtraction expression, "__M2_RTco_ctor" minus "L7$pb"
/var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//ccxlVpeL.s:492:symbol:
"__M2_RTco_ctor" can't be undefined in a subtraction expression
/var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//ccxlVpeL.s:466:non-relocatable
subtraction expression, "__M2_SysExceptions_ctor" minus "L7$pb"
/var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//ccxlVpeL.s:466:symbol:
"__M2_SysExceptions_ctor" can't be undefined in a subtraction expression
compiler exited with status 1
FAIL: gm2/complex/run/pass/arith3.mod compilation, -g
unsuccessful link
UNRESOLVED: gm2/complex/run/pass/arith3.mod execution, -g (link failed)
and many more. Affects
12 "__M2_cgetopt_ctor"
24 "__M2_cpp_ctor"
528 "__M2_dtoa_ctor"
1284 "__M2_errno_ctor"
180 "__M2_ErrnoCategory_ctor"
12 "__M2_KeyBoardLEDs_ctor"
528 "__M2_ldtoa_ctor"
612 "__M2_RTco_ctor"
216 "__M2_Selective_ctor"
1284 "__M2_SysExceptions_ctor"
1284 "__M2_termios_ctor"
12 "__M2_UnixArgs_ctor"
144 "__M2_wrapc_ctor"
[Bug c++/107632] New: has_facet does not work with -mlong-double-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107632
Bug ID: 107632
Summary: has_facet does not work with -mlong-double-64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
#include
#include
using namespace std;
int main(int argc, char *argv[]) {
locale oGlobalLocale;
if (!has_facet< num_get > >
>( oGlobalLocale ))
__builtin_abort ();
}
g++ t.cpp -o t && ./t -> works as expected
g++ t.cpp -o t -mlong-double-64 && ./t -> aborts
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622 --- Comment #6 from Wilhelm M --- (In reply to Richard Biener from comment #5) > Did you try -fstrict-enums? Yes, that doesn't change anything.
[Bug web/107610] Broken 'onlinedocs' after "Porting the Docs to Sphinx"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107610 --- Comment #5 from Martin Liška --- There's an alternative suggestion that would basically keep old documentation where it used to be. For the new one, we'll use a new url base: https://gcc.gnu.org/docs: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605722.html
[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 Gaius Mulley changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Gaius Mulley --- Excellent thanks for re-testing.
[Bug go/107491] Gccgo stack not resizing on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491 --- Comment #8 from Jakub Kulik --- Sure, this was just a quick first test. That said, GODEBUG is slightly more complex - is there an example of a C code where GODEBUG variables are being used you can point me to (I found only go sources with anything GODEBUG related)? As for the split stack, I will try looking into it and see if it works. Having overhead might solve the issue with no linker support, but it's indeed pretty wasteful (and might break what works currently)...
[Bug modula2/107631] many tests don't link on Mac OS X 10.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631 --- Comment #1 from Gaius Mulley --- an observation: all the affected modules listed are hand built C++ modules to mimic modula-2.
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #28 from Alexandre Oliva ---
Thanks for the fix. I'm missing something like this (untested) for x86_64-elf:
diff --git a/gcc/testsuite/gcc.target/i386/pr107304.c
b/gcc/testsuite/gcc.target/i386/pr107304.c
index 24d68795e7f1c..0043b7b21a32f 100644
--- a/gcc/testsuite/gcc.target/i386/pr107304.c
+++ b/gcc/testsuite/gcc.target/i386/pr107304.c
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O0 -march=tigerlake" } */
+/* { dg-require-ifunc "" } */
#include
[Bug rust/107633] New: [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 Bug ID: 107633 Summary: [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.11 Target: i386-pc-solaris2.11 Build: i386-pc-solaris2.11 I just tried bootstrapping the current devel/rust/master branch on Solaris/x86, but ran into quite number of failues: * For one, there were hundreds of instances of -Werror=unused-parameter, e.g. /vol/gcc/src/hg/master/rust/gcc/rust/lex/rust-lex.cc: In member function 'std::tuple Rust::Lexer::parse_utf8_escape(char)': /vol/gcc/src/hg/master/rust/gcc/rust/lex/rust-lex.cc:1326:32: error: unused parameter 'opening_char' [-Werror=unused-parameter] 1326 | Lexer::parse_utf8_escape (char opening_char) | ~^~~~ /vol/gcc/src/hg/master/rust/gcc/rust/ast/rust-ast-dump.cc: In member function 'virtual void Rust::AST::Dump::visit(Rust::AST::AttrInputMetaItemContainer&)': /vol/gcc/src/hg/master/rust/gcc/rust/ast/rust-ast-dump.cc:243:42: error: unused parameter 'input' [-Werror=unused-parameter] 243 | Dump::visit (AttrInputMetaItemContainer &input) | ^ * With those worked around (see below), there still a couple of -Werror=dangling-reference errors: /vol/gcc/src/hg/master/rust/gcc/rust/typecheck/rust-hir-type-check-type.cc: In member function 'Rust::TyTy::BaseType* Rust::Resolver::TypeCheckType::resolve_segments(Rust::NodeId, Rust::HirId, std::vector >&, std::size_t, Rust::TyTy::BaseType*, const Rust::Analysis::NodeMapping&, Location)': /vol/gcc/src/hg/master/rust/gcc/rust/typecheck/rust-hir-type-check-type.cc:465:13: error: possibly dangling reference to a temporary [-Werror=dangling-reference] 465 | auto &candidate = *candidates.begin (); | ^ /vol/gcc/src/hg/master/rust/gcc/rust/typecheck/rust-hir-type-check-type.cc:465:44: note: the temporary was destroyed at the end of the full expression 'candidates.std::set::begin().std::_Rb_tree_const_iterator::operator*()' 465 | auto &candidate = *candidates.begin (); | I've hacked around both by adding -Wno-error=unused-parameter -Wno-error=dangling-reference to gcc/rust/Make-lang.in (RUST_CXXFLAGS), but this is supposed to work out of the box. The build is in stage 2 now.
[Bug modula2/107611] mc-boot-ch/Gtermios.cc etc. don't compile on Mac OS X 10.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107611 Rainer Orth changed: What|Removed |Added Attachment #53867|0 |1 is obsolete|| --- Comment #1 from Rainer Orth --- Created attachment 53880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53880&action=edit Revised patch libgm2/libm2pim/termios.cc has the same issue.
[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #23 from Martin Liška --- (In reply to Sam Mish from comment #22) > I'm hitting an issue similar to this in one of my projects: > > gcc-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0 > > > When linking with lto on a optimized build, gcc12 is crashing (apologies for > the long link line) > Good! Can you please provide steps how to build the reproducer project?
[Bug libstdc++/107632] has_facet does not work with -mlong-double-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107632 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||ABI Last reconfirmed||2022-11-11 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Component|c++ |libstdc++ --- Comment #1 from Jonathan Wakely --- Almost certainly due to my changes for PR 103755
[Bug libstdc++/107632] [13 Regression] has_facet does not work with -mlong-double-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107632 Jonathan Wakely changed: What|Removed |Added Summary|has_facet does not work |[13 Regression] has_facet |with -mlong-double-64 |does not work with ||-mlong-double-64 Priority|P3 |P1 Target Milestone|--- |13.0
[Bug libstdc++/107632] [13 Regression] has_facet does not work with -mlong-double-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107632 --- Comment #2 from Jonathan Wakely --- I'm kinda tempted to just disable the new optimization on these targets, the handling of compat facets for different float ABIs is impossible to get right.
[Bug libstdc++/107632] has_facet does not work with -mlong-double-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107632 Jonathan Wakely changed: What|Removed |Added Known to fail||12.1.0, 13.0, 6.3.1, 9.1.0 Summary|[13 Regression] has_facet |has_facet does not work |does not work with |with -mlong-double-64 |-mlong-double-64| Target Milestone|13.0|--- --- Comment #3 from Jonathan Wakely --- Oh wait, not a regression, at least not caused by me this week. This has failed since at least gcc 6.
[Bug libstdc++/107632] has_facet does not work with -mlong-double-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107632 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug other/107634] New: Very long filenames and URLs for sphinx-based docs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 Bug ID: 107634 Summary: Very long filenames and URLs for sphinx-based docs Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Although mostly I'm very happy with how our docs look after migration to sphinx, the new filenames (and thus URLs) for the sphinx-based docs seem overly long. I just added a new option to -fanalyzer. Previously I had to edit: gcc/doc/invoke.texi and the generated HTML would be in: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Static-Analyzer-Options.html Now I have to edit: gcc/doc/gcc/gcc-command-options/options-that-control-static-analysis.rst and the generated HTML is in: https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/options-that-control-static-analysis.html which repeats "gcc" and "options". Some of them are: options-that-* and others are: options-for-* and: options-to-* and: options-controlling-* Perhaps this is just unfamiliarity with the new system, but it seems like the filenames could be much shorter, so e.g. rather than: gcc/doc/gcc/gcc-command-options/options-that-control-static-analysis.rst we could have: gcc/doc/gcc/options/analyzer.rst or somesuch. Similar, we have: gcc/doc/gcc/gcc-command-options/machine-dependent-options/aarch64-options.rst https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/machine-dependent-options/aarch64-options.html which has "options" 3 times; perhaps it could be: gcc/doc/gcc/options/target/aarch64.rst or somesuch. ...and yet another set of redirects for the HTML, I guess :-/
[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 --- Comment #9 from Jonathan Wakely --- This causes an ABI regression on powerpc64le: FAIL: libstdc++-abi/abi_check
[Bug tree-optimization/107554] [10/11/12/13 Regression] Segmentation fault during GIMPLE pass: strlen (tree-ssa-strlen.cc:4772)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107554 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- going to test / push the fix
[Bug tree-optimization/84646] Missed optimisation for hoisting conditions outside nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84646 --- Comment #12 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:be2c74fdcd0e8d66c3667008ba2561ab5dcc379b commit r13-3897-gbe2c74fdcd0e8d66c3667008ba2561ab5dcc379b Author: Richard Biener Date: Thu Nov 10 15:04:10 2022 +0100 Make last DCE remove empty loops The following makes the last DCE pass CD-DCE and in turn the last CD-DCE pass a DCE one. That ensues we remove empty loops that become empty between the two. I've also moved the tail-call pass after DCE since DCE can only improve things here. The two testcases were the only ones scanning cddce3 so I've changed them to scan the dce7 pass that's now in this place. The testcases scanning dce7 also work when that's in the earlier position. PR tree-optimization/84646 * tree-ssa-dce.cc (pass_dce::set_pass_param): Add param wheter to run update-address-taken. (pass_dce::execute): Honor it. * passes.def: Exchange last DCE and CD-DCE invocations. Swap pass_tail_calls and the last DCE. * g++.dg/tree-ssa/pr106922.C: Continue to scan earlier DCE dump. * gcc.dg/tree-ssa/20030808-1.c: Likewise.
[Bug tree-optimization/107618] Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107618 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:af96500eea72c674a5686b35c66202ef2bd9688f commit r13-3898-gaf96500eea72c674a5686b35c66202ef2bd9688f Author: Richard Biener Date: Fri Nov 11 10:12:28 2022 +0100 tree-optimization/107618 - enhance copy propagation of constants The following enhances copy propagation of constants to also see through simple operations like conversions but also operations with otherwise constant operands. That's required to fulfill the promise /* Copy propagation also copy-propagates constants, this is necessary to forward object-size and builtin folding results properly. */ NEXT_PASS (pass_copy_prop); and avoid false diagnostics as shown in the testcase. We're using gimple_fold_stmt_to_constant_1 with not following SSA edges and accordingly adjust what stmts we simulate during SSA propagation. PR tree-optimization/107618 * tree-ssa-copy.cc (stmt_may_generate_copy): Simulate all assignments with a single SSA use. (copy_prop_visit_assignment): Use gimple_fold_stmt_to_constant_1 to perform simple constant folding. (copy_prop::visit_stmt): Visit all assignments. * gcc.dg/pr107618.c: New testcase.
[Bug tree-optimization/107618] Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107618 Richard Biener changed: What|Removed |Added Known to work||13.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||12.2.0, 4.8.5, 7.5.0 --- Comment #5 from Richard Biener --- Should be fixed for GCC 13, it doesn't seem to be a regression.
[Bug other/107634] Very long filenames and URLs for sphinx-based docs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #1 from Richard Biener --- Finding the relevant sources to edit is indeed cumbersome (for those who remember the previous file names). I've also used the texi sources themselves as documentation - that's now nearly impossible due to the hugely fragmented source base :(
[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 --- Comment #1 from Jonathan Wakely --- (In reply to Rainer Orth from comment #0) > /vol/gcc/src/hg/master/rust/gcc/rust/typecheck/rust-hir-type-check-type.cc: > In member function 'Rust::TyTy::BaseType* > Rust::Resolver::TypeCheckType::resolve_segments(Rust::NodeId, Rust::HirId, > std::vector >&, std::size_t, > Rust::TyTy::BaseType*, const Rust::Analysis::NodeMapping&, Location)': > /vol/gcc/src/hg/master/rust/gcc/rust/typecheck/rust-hir-type-check-type.cc: > 465:13: error: possibly dangling reference to a temporary > [-Werror=dangling-reference] > 465 | auto &candidate = *candidates.begin (); This should probably be: auto first = candidates.begin (); auto &candidate = *first; so that the iterator persists as long as its value is needed.
[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 Jonathan Wakely changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- Oh wait, that's a std::set::iterator? Then the warning is wrong. Its operator* returns a reference to something that outlives the iterator itself.
[Bug fortran/107635] New: [Coarray] Allocatable components of types defined in module's interface are not handled correctly when used in coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107635 Bug ID: 107635 Summary: [Coarray] Allocatable components of types defined in module's interface are not handled correctly when used in coarrays. Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vehre at gcc dot gnu.org Target Milestone: --- Created attachment 53881 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53881&action=edit Example demonstrating the issue. When defining a type with an allocatable component in a module's interface (it doesn't really matter where the implementation is given either in the same module or a submodule) and using gfortran with -fcoarray=lib (for example in combination with opencoarrays), then the alloc.comp. is not treated correctly when used in a coarray. The issue is, that during internal type generation the coarray attr is not set for the type and therefore no member for the (sub-)caf_token is assigned. This leads to segfaults in the calling code. See attached example and issue https://github.com/sourceryinstitute/OpenCoarrays/issues/739 from opencoarrays.
[Bug tree-optimization/105142] [12 Regression] Wrong code with -O2 since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142 --- Comment #14 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4b3874d803e7961f38b22fa798517a63171bb985 commit r13-3904-g4b3874d803e7961f38b22fa798517a63171bb985 Author: Richard Biener Date: Tue Jul 26 11:52:49 2022 +0200 tree-optimization/105142 - improve maybe_fold_comparisons_from_match_pd fix The following improves on the fix for PR105142 which restricted the expression lookup used for maybe_fold_comparisons_from_match_pd to avoid picking up flow-sensitive info for use in places where guarding conditions do not hold. Instead of not allowing to expand SSA definitions there the following temporarily clears flow-sensitive info on the SSA names and restores it when finished matching. PR tree-optimization/105142 * gimple-fold.cc (fosa_unwind): New global. (follow_outer_ssa_edges): When the SSA definition to follow is does not dominate fosa_bb, temporarily clear flow-sensitive info. Make sure to not expand stmts with not defined overflow. (maybe_fold_comparisons_from_match_pd): Set up unwind stack for follow_outer_ssa_edges and unwind flow-sensitive info clearing after matching.
[Bug tree-optimization/107554] [10/11/12/13 Regression] Segmentation fault during GIMPLE pass: strlen (tree-ssa-strlen.cc:4772)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107554 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:81de4037454275f8ed6d858fbc129e832c6147ef commit r13-3905-g81de4037454275f8ed6d858fbc129e832c6147ef Author: Richard Biener Date: Fri Nov 11 14:28:52 2022 +0100 tree-optimization/107554 - fix ICE in stlen optimization The following fixes a wrongly typed variable causing an ICE. PR tree-optimization/107554 * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes): Use unsigned HOST_WIDE_INT type for the strlen. * gcc.dg/pr107554.c: New testcase. Co-Authored-By: Nikita Voronov
[Bug tree-optimization/107618] Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107618 --- Comment #6 from Yann Droneaud --- (In reply to Richard Biener from comment #5) > Should be fixed for GCC 13, it doesn't seem to be a regression. I've tested with a fresh rebuild of GCC's trunk, and the warning is no more reported at -Og level. Thanks.
[Bug libstdc++/107636] New: [13 regression] r13-3761-ga239a63f868e29 breaks build on powerpc64le with __float128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107636
Bug ID: 107636
Summary: [13 regression] r13-3761-ga239a63f868e29 breaks build
on powerpc64le with __float128 support
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: enrico.seiler+gccbugs at outlook dot com
Target Milestone: ---
The following does not compile:
```
#define __STDCPP_FLOAT128_T__
#define _GLIBCXX_HAVE_FLOAT128_MATH
#define _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT
#include
int main()
{}
```
```
include/c++/13.0.0/charconv: In function ‘std::to_chars_result
std::to_chars(char*, char*, _Float128)’:
include/c++/13.0.0/charconv:890:5: error: expected primary-expression before
‘return’
890 | return to_chars(__first, __last, static_cast<__float128>(__value));
| ^~
include/c++/13.0.0/charconv: In function ‘std::to_chars_result
std::to_chars(char*, char*, _Float128, chars_format)’:
include/c++/13.0.0/charconv:897:5: error: expected primary-expression before
‘return’
897 | return to_chars(__first, __last, static_cast<__float128>(__value),
__fmt);
| ^~
include/c++/13.0.0/charconv: In function ‘std::to_chars_result
std::to_chars(char*, char*, _Float128, chars_format, int)’:
include/c++/13.0.0/charconv:904:5: error: expected primary-expression before
‘return’
904 | return to_chars(__first, __last, static_cast<__float128>(__value),
__fmt,
| ^~
```
Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107562
It seems there are a few __extension__ where they should not be:
inline to_chars_result
to_chars(char* __first, char* __last, _Float128 __value) noexcept
{
__extension__
return to_chars(__first, __last, static_cast<__float128>(__value));
}
[Bug libstdc++/107636] [13 regression] r13-3761-ga239a63f868e29 breaks build on powerpc64le with __float128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107636 --- Comment #1 from Enrico Seiler --- The `#define`s can also be omitted. Then the error will occur when compiling with -std=c++23
[Bug c++/107637] New: C++23: Implement P2644R1 - Final Fix of Broken Range‐based for Loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107637
Bug ID: 107637
Summary: C++23: Implement P2644R1 - Final Fix of Broken
Range‐based for Loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Testcase:
// P2644R1 - Final Fix of Broken Range‐based for Loop
// { dg-do run { target c++11 } }
extern "C" void abort ();
struct S
{
S () { ++s; }
S (const S &) { ++s; }
~S () { --s; }
static int s;
};
int S::s;
struct T
{
T (const S &, const S &) { ++t; }
T (const T &) { ++t; }
~T () { --t; }
static int t;
};
int T::t;
int a[4];
int *
begin (const S &)
{
return &a[0];
}
int *
end (const S &)
{
return &a[4];
}
int *
begin (const T &)
{
return &a[0];
}
int *
end (const T &)
{
return &a[4];
}
const S &
foo (const S &x)
{
return x;
}
const T &
foo (const T &x)
{
return x;
}
int
main ()
{
if (S::s != 0)
abort ();
for (auto x : S ())
{
if (S::s != 1)
abort ();
}
if (S::s != 0)
abort ();
for (auto x : foo (S ()))
{
if (S::s != (__cpp_range_based_for >= 202211L))
abort ();
}
if (S::s != 0)
abort ();
if (T::t != 0)
abort ();
for (auto x : T (S (), S ()))
{
if (S::s != 2 * (__cpp_range_based_for >= 202211L) || T::t != 1)
abort ();
}
if (S::s != 0 || T::t != 0)
abort ();
for (auto x : foo (T (S (), S (
{
if (S::s != 2 * (__cpp_range_based_for >= 202211L)
|| T::t != (__cpp_range_based_for >= 202211L))
abort ();
}
if (S::s != 0 || T::t != 0)
abort ();
}
if I understand the paper well.
Tried to play with it, but:
--- gcc/cp/decl.cc.jj 2022-11-11 08:43:28.296462815 +0100
+++ gcc/cp/decl.cc 2022-11-11 13:53:19.071246170 +0100
@@ -7809,7 +7809,14 @@ initialize_local_var (tree decl, tree in
gcc_assert (building_stmt_list_p ());
saved_stmts_are_full_exprs_p = stmts_are_full_exprs_p ();
- current_stmt_tree ()->stmts_are_full_exprs_p = 1;
+ // P2644R1 - for-range-initializer in C++23 should have temporaries
+ // destructed only at the end of the whole range for loop.
+ if (cxx_dialect >= cxx23
+ && DECL_ARTIFICIAL (decl)
+ && DECL_NAME (decl) == for_range__identifier)
+ current_stmt_tree ()->stmts_are_full_exprs_p = 0;
+ else
+ current_stmt_tree ()->stmts_are_full_exprs_p = 1;
finish_expr_stmt (init);
current_stmt_tree ()->stmts_are_full_exprs_p =
saved_stmts_are_full_exprs_p;
--- gcc/cp/semantics.cc.jj 2022-11-09 11:22:42.612628127 +0100
+++ gcc/cp/semantics.cc 2022-11-11 15:49:30.569832414 +0100
@@ -1408,7 +1408,10 @@ finish_for_stmt (tree for_stmt)
}
}
- add_stmt (do_poplevel (scope));
+ tree bind = do_poplevel (scope);
+ if (range_for_decl[0] && cxx_dialect >= cxx23)
+bind = maybe_cleanup_point_expr_void (bind);
+ add_stmt (bind);
/* If we're being called from build_vec_init, don't mess with the names of
the variables for an enclosing range-for. */
ICEs, not sure why the outer CLEANUP_POINT_EXPR doesn't catch those TARGET_EXPR
cleanups.
But, I think it could interact badly with the cleanups for extended lifetime
references.
So shall something walk init in cp_finish_decl of for_range__identifier decls,
look similarly to wrap_cleanups init and look for cleanups on TARGET_EXPRs not
nested inside of CLEANUP_POINT_EXPRs and somehow extend their lifetime (perhaps
move them out of the TARGET_EXPRs just into normal cleanups)?
Giving up on this...
[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633
--- Comment #3 from Marek Polacek ---
I thought this had been fixed by
commit 32a06ce38a38bf37db468f0e6c83520fcc221534
Author: Marek Polacek
Date: Tue Nov 1 17:05:52 2022 -0400
c++: Quash -Wdangling-reference for member operator* [PR107488]
-Wdangling-reference complains here:
std::vector v = ...;
std::vector::const_iterator it = v.begin();
while (it != v.end()) {
const int &r = *it++; // warning
}
is the operator* here a non-member function?
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
--- Comment #7 from Marc Glisse ---
(Wilhelm, when you post testcases, please post the full file including the
#include lines)
(In reply to Richard Biener from comment #5)
> Did you try -fstrict-enums?
IIUC, even if optimizations using -fstrict-enums were implemented, they would
only help with the first testcase if the number of enum values was a power of
2. For {A,B,C}, -fstrict-enums still considers 3 a valid value.
I have long wanted an attribute to specify that a particular enum is only
allowed to take the values explicitly listed, though I cannot find a relevant
issue in bugzilla at the moment.
Comment #4 is an independent issue where gcc fails to notice that since the
static variable does not escape, it can be replaced with a local constant.
[Bug c++/107638] New: [13 Regression] options.h:239:36: error: token "." is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107638 Bug ID: 107638 Summary: [13 Regression] options.h:239:36: error: token "." is not valid in preprocessor expressions Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: ppalka at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 The following problem was introduced by commit d0a492faa6478c99d325fa4a7ed2e5633cef7529: g++ -std=c++11 -fno-PIE -c -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions - fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -W cast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I . -Icp -I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include -I../../gcc /gcc/../libcpp/include -I../../gcc/gcc/../libcody -I/opt/gnu64/gcc/gmp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecn umber -I../../gcc/gcc/../libbacktrace -I/opt/gnu64/gcc/gmp/include -o cp/tree.o -MT cp/tree.o -MMD -MP -MF cp/.deps/tree.TPo ../../gcc/gcc/cp/tree.cc In file included from ../../gcc/gcc/tree.h:24, from ../../gcc/gcc/cp/tree.cc:24: ./options.h:239:36: error: token "." is not valid in preprocessor expressions 239 | #define target_flags global_options.x_target_flags |^ ./options.h:8725:25: note: in expansion of macro 'target_flags' 8725 | #define TARGET_GNU_LD ((target_flags & MASK_GNU_LD) != 0) | ^~~~ ../../gcc/gcc/config/pa/pa64-hpux.h:358:33: note: in expansion of macro 'TARGET_GNU_LD' 358 | #define SUPPORTS_INIT_PRIORITY (TARGET_GNU_LD ? 1 : 0) | ^ ../../gcc/gcc/cp/tree.cc:5039:5: note: in expansion of macro 'SUPPORTS_INIT_PRIORITY' 5039 | #if SUPPORTS_INIT_PRIORITY | ^~ make[3]: *** [Makefile:1135: cp/tree.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/home/dave/gnu/gcc/objdir64/gcc' make[2]: *** [Makefile:4915: all-stage1-gcc] Error 2 make[2]: Leaving directory '/home/dave/gnu/gcc/objdir64' make[1]: *** [Makefile:25469: stage1-bubble] Error 2 make[1]: Leaving directory '/home/dave/gnu/gcc/objdir64' make: *** [Makefile:25822: bootstrap] Error 2 Fri Nov 11 09:17:16 EST 2022 On hppa64-hpux, we have the following define for SUPPORTS_INIT_PRIORITY: #define SUPPORTS_INIT_PRIORITY (TARGET_GNU_LD ? 1 : 0) The goal was to support the init_priority attribute with GNU ld and not with HP ld. The documentation doesn't indicate whether C statements are allowed or not for SUPPORTS_INIT_PRIORITY.
[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 --- Comment #4 from Marek Polacek --- Actually, the patch I plan to post in a little bit should fix the problem above because the reference we're initializing here is non-const.
[Bug libstdc++/107636] [13 regression] r13-3761-ga239a63f868e29 breaks build on powerpc64le with __float128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107636
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-11-11
--- Comment #2 from Jakub Jelinek ---
Created attachment 53882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53882&action=edit
gcc13-pr107636.patch
Untested fix.
I've just tested that
int bar ();
int
foo ()
{
return __extension__ bar ();
}
is accepted by both g++ and clang++.
[Bug tree-optimization/107554] [10/11/12 Regression] Segmentation fault during GIMPLE pass: strlen (tree-ssa-strlen.cc:4772)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107554 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- I agree. For prep != NULL, we know it must fit into unsigned int, we don't even support longer STRING_CSTs, but for NULL prep it can be larger.
[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #24 from Sam Mish --- > Good! Can you please provide steps how to build the reproducer project? Unfortunately, this project uses a large and unconventional build system, so it's difficult to reproduce. I could upload the `.ii` files, but each of the libraries in that /home/sam/code/serac_libs_gcc12/gcc-12.1.0/ directory were built custom (and might be relevant to the failure) I can look into trying to reproduce the issue in a docker image-- would that be helpful?
[Bug tree-optimization/107639] New: GCC unable to reason about range of idx/len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639
Bug ID: 107639
Summary: GCC unable to reason about range of idx/len
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jmuizelaar at mozilla dot com
Target Milestone: ---
Clang 14 is able to optimize this function to just 'ret'. GCC 12.2 is not.
#include
void do_checks(const int* begin, const size_t len){
size_t idx = 0;
const auto end = begin + len;
for (const int* it = begin; it!=end; ++it, ++idx){
if (idx <= len){
// Do something useful
}
else
{
throw 5;
}
}
}
https://godbolt.org/z/f7PjjqG9T
[Bug tree-optimization/107639] GCC unable to reason about range of idx/len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639 --- Comment #1 from Jeff Muizelaar --- This test case comes from https://github.com/llvm/llvm-project/issues/56612
[Bug other/107634] Very long filenames and URLs for sphinx-based docs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #2 from Andrew Pinski --- Hmm, I thought at one point we were producing also one big HTML for the manual but maybe that was just binutils. Also sphinx does not produce postscript? Just PDFs? Seems a downgrade. And yes I used to go into invoke.texi and do a search for the options too. Splitting it up into different files is a HUGE downgrade.
[Bug other/107620] Build errors when using sphinx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2022-11-11 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed. Btw. what revision do you build and what command do you use?
[Bug ipa/107640] New: IPA-CP drops known values passed by reference when the reference is to a global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107640
Bug ID: 107640
Summary: IPA-CP drops known values passed by reference when the
reference is to a global variable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
Combining IPA-CP of (scalar) parameter values and of values passed by reference
(aggregate values) does not work in the same function parameter, we drop the
aggregate values on the floor.
The following aborts when compiled with -O2 -DFAIL
struct S
{
int a, b, c;
};
volatile int gi;
void __attribute__((noipa))
consume_s (struct S *p)
{
gi = p->a;
}
static void __attribute__((noinline))
foo (struct S *p)
{
if (!__builtin_constant_p (p->b))
__builtin_abort ();
consume_s (p);
}
static struct S __attribute((used)) gs;
int main (int argc, char *argv[])
{
struct S *p;
#ifdef FAIL
p = &gs;
#else
struct S s;
p = &s;
#endif
p->a = 10;
p->b = 20;
foo (p);
return 0;
}
[Bug libgomp/107641] New: libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107641 Bug ID: 107641 Summary: libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- I'm seeing a bootstrap failure on mingw-w64 ../../../gcc/libgomp/env.c: In function 'parse_unsigned_long': ../../../gcc/libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 286 | unsigned upper = (unsigned long) params[2]; |^ cc1: all warnings being treated as errors unsigned long is 32-bit on Windows.
[Bug c++/107638] [13 Regression] options.h:239:36: error: token "." is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107638 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |13.0 Last reconfirmed||2022-11-11 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Whoops, sorry for the build breakage, I had wrongly assumed SUPPORTS_INIT_PRIORITY is always a simple constant. Instead of trying to statically exclude init_priority from the attribute table, I guess we should just special case init_priority in the __has_attribute handling.
[Bug middle-end/107642] New: LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642
Bug ID: 107642
Summary: LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: documentation, internal-improvement,
missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
LOGICAL_OP_NON_SHORT_CIRCUIT is defined as:
@defmac LOGICAL_OP_NON_SHORT_CIRCUIT
Define this macro if a non-short-circuit operation produced by
@samp{fold_range_test ()} is optimal. This macro defaults to true if
@code{BRANCH_COST} is greater than or equal to the value 2.
@end defmac
Some targets define it to 0 or something else:
apinski@xeond:~/src/upstream-gcc-git/gcc/gcc/config$ git grep
LOGICAL_OP_NON_SHORT_CIRCUIT */*.h
arc/arc.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT \
arm/arm.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT
\
csky/csky.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT \
loongarch/loongarch.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
mips/mips.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
msp430/msp430.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
nds32/nds32.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
pru/pru.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
riscv/riscv.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
rs6000/rs6000.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
visium/visium.h:#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
arc.h:
#define LOGICAL_OP_NON_SHORT_CIRCUIT \
(BRANCH_COST (optimize_function_for_speed_p (cfun), \
false) > 9)
arm.h:
#define LOGICAL_OP_NON_SHORT_CIRCUIT\
((optimize_size) \
? (TARGET_THUMB ? false : true) \
: TARGET_THUMB ? static_cast
(current_tune->logical_op_non_short_circuit_thumb) \
: static_cast (current_tune->logical_op_non_short_circuit_arm))
csky.h (which is the default it seems):
#define LOGICAL_OP_NON_SHORT_CIRCUIT \
(csky_default_logical_op_non_short_circuit ())
...
bool
csky_default_logical_op_non_short_circuit (void)
{
return BRANCH_COST (optimize_function_for_speed_p (cfun), false) >= 2;
}
LOGICAL_OP_NON_SHORT_CIRCUIT is used in many few places than fold_range_test
these days too.
fold-const.cc:#ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
fold-const.cc:#define LOGICAL_OP_NON_SHORT_CIRCUIT \
fold-const.cc: bool logical_op_non_short_circuit =
LOGICAL_OP_NON_SHORT_CIRCUIT;
fold-const.cc: bool logical_op_non_short_circuit =
LOGICAL_OP_NON_SHORT_CIRCUIT;
tree-ssa-ifcombine.cc:#ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
tree-ssa-ifcombine.cc:#define LOGICAL_OP_NON_SHORT_CIRCUIT \
tree-ssa-ifcombine.cc:bool logical_op_non_short_circuit =
LOGICAL_OP_NON_SHORT_CIRCUIT;
fold_truth_andor in fold-const.cc
ifcombine_ifandif in tree-ssa-ifcombine.cc
What LOGICAL_OP_NON_SHORT_CIRCUIT is trying to say is that expansion (from
gimple to RTL) of
things like `a & b` (where a and b are bools) is cheaper than expanding out
using jumps.
Note this is not exactly true as there is code which does that again in
dojump.cc:
/* High branch cost, expand as the bitwise OR of the conditions.
Do the same if the RHS has side effects, because we're effectively
turning a TRUTH_OR_EXPR into a TRUTH_ORIF_EXPR. */
if (BRANCH_COST (optimize_insn_for_speed_p (), false) >= 4
|| TREE_SIDE_EFFECTS (TREE_OPERAND (exp, 1)))
[Bug web/107643] New: [13 Regression] sphix generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Bug ID: 107643 Summary: [13 Regression] sphix generated indexes are not working at all Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation Severity: blocker Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/onlinedocs/gccint/indices-and-tables.html https://gcc.gnu.org/onlinedocs/gcc/indices-and-tables.html All say TODO
[Bug web/107643] [13 Regression] sphix generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug web/107643] [13 Regression] sphix generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 --- Comment #1 from Andrew Pinski --- I had used these to find the options and other keywords for GCC 12 manual all the time. Because searching to find the right page is hard. Especially if it is 2 layers down.
[Bug web/107644] New: [13 Regression] Sphinx generated web pages is not using the full width of the window
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107644 Bug ID: 107644 Summary: [13 Regression] Sphinx generated web pages is not using the full width of the window Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Created attachment 53883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53883&action=edit screen shot of my chrome window I have an ultra wide screen so I can read left to right without scrolling. With the current way sphinx generated web pages are, they are centered in the window even and just fill up part a small part of the window rather than the full left to right. If we can disable this centering and forcing only part of the window to be use that would be great.
[Bug web/107644] [13 Regression] Sphinx generated web pages is not using the full width of the window
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107644 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug libgomp/107641] [13 Regression] libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107641 Jonathan Wakely changed: What|Removed |Added CC||marcel at codesourcery dot com Target||*mingw* Known to fail||13.0 Summary|libgomp/env.c:286:20: |[13 Regression] |error: cast from pointer to |libgomp/env.c:286:20: |integer of different size |error: cast from pointer to |[-Werror=pointer-to-int-cas |integer of different size |t] |[-Werror=pointer-to-int-cas ||t] Known to work||12.2.0 Target Milestone|--- |13.0 --- Comment #1 from Jonathan Wakely --- Presumably started with r13-2545-g9f2fca56593a2b
[Bug target/107645] New: internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in symbolic_operand_1, at config/m68k/predicates.md:144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107645 Bug ID: 107645 Summary: internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in symbolic_operand_1, at config/m68k/predicates.md:144 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jcmvbkbc at gcc dot gnu.org Target Milestone: --- Created attachment 53884 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53884&action=edit _gcov_indirect_call_profiler_v4.i Building gcc with --enable-checking=all for target=m68k-linux-uclibc breaks with the following error message: gcc/libgcc/libgcov-profiler.c: In function ‘__gcov_indirect_call_profiler_v4’: gcc/libgcc/libgcov-profiler.c:173:1: internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in symbolic_operand_1, at config/m68k/predicates.md:144 It can be reproduced with the following command line and the attached source: cc1 -O2 -fPIC -g -fno-stack-protector -mcpu=68040 _gcov_indirect_call_profiler_v4.i Bisection points to the following revision: r0-93570-g75df395f15f2
[Bug web/107644] [13 Regression] Sphinx generated web pages is not using the full width of the window
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107644 --- Comment #1 from Andrew Pinski --- Note sphinx is not the only one which hates my ultrawide screen too. Madoko hates it too as witness by https://p4.org/p4-spec/docs/P4-16-working-spec.html#sec-actions
[Bug analyzer/107646] New: RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 Bug ID: 107646 Summary: RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin? Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- My gcc-python-plugin implements a crude static analysis of CPython code, using symbolic execution in a manner similar to how -fanalyzer works, but it's been bitrotting for years, and is slow (being written in Python itself): https://gcc-python-plugin.readthedocs.io/en/latest/cpychecker.html I *think* this could now be reimplemented as a plugin to GCC's -fanalyzer (in C++), where -fanalyzer provides most of the framework needed, and we'd mostly just need to write the CPython-specific parts. It would make an interesting GSoC project (albeit perhaps a challenging one).
[Bug other/107634] Very long filenames and URLs for sphinx-based docs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-11-11 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #3 from Eric Botcazou --- Indeed, there are now 746 files under doc/ with ridiculously long names for a bunch of them. I don't think that's even remotely manageable.
[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 --- Comment #1 from David Malcolm --- In particular, reference-count checking would probably be the most interesting aspect of the project.
[Bug other/107634] Very long filenames and URLs for sphinx-based docs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 Eric Botcazou changed: What|Removed |Added Severity|normal |critical
[Bug tree-optimization/107647] New: GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
Bug ID: 107647
Summary: GCC 12.2.0 may produce FMAs even with
-ffp-contract=off
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bartoldeman at users dot sourceforge.net
Target Milestone: ---
I stumped upon an example where GCC generates FMA instruction even when FMAs
are disabled using -ffp-contract=off (extracted from
https://github.com/xianyi/OpenBLAS/blob/develop/kernel/x86_64/cscal.c)
$ cat cscal.c
void cscal(int n, float da_r, float *x)
{
for (int i = 0; i < n; i += 4)
{
float temp0 = da_r * x[i] - x[i+1];
float temp1 = da_r * x[i+2] - x[i+3];
x[i+1] = da_r * x[i+1] + x[i];
x[i+3] = da_r * x[i+3] + x[i+2];
x[i] = temp0;
x[i+2] = temp1;
}
}
$ gcc -S -march=haswell -O2 -ffp-contract=off cscal.c
$ grep fma cscal.s
vfmaddsub231ps %xmm0, %xmm2, %xmm1
I would expect there to be no FMA instructions in there.
[Bug tree-optimization/107647] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #1 from bartoldeman at users dot sourceforge.net --- According to godbolt it's still producing FMAs on trunk: https://godbolt.org/z/aWh6d1E4E
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 Andrew Pinski changed: What|Removed |Added Blocks||53947 Summary|GCC 12.2.0 may produce FMAs |[12/13 Regression] GCC |even with -ffp-contract=off |12.2.0 may produce FMAs ||even with -ffp-contract=off Target Milestone|--- |12.3 Keywords||wrong-code Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-11-11 --- Comment #2 from Andrew Pinski --- Confirmed. It is SLP that is doing it. At -O3 even GCC 11 is working ok. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug middle-end/107642] LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-11-11 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- Nice catch, thanks for the report. This is due to g:7d810646d421 The documentation should clarify that patterns correspond to basic fma instructions (without intermediate rounding), and SLP pattern matching should check flag_fp_contract_mode != FP_CONTRACT_OFF.
[Bug libgomp/107641] [13 Regression] libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107641 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2022-11-11 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 53885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53885&action=edit gcc13-pr107641.patch Untested fix. Using unsigned for upper is also quite suspicious, because the code then does if (upper <= UCHAR_MAX) something; else if (upper <= UINT_MAX) something else; else something different; but if upper is unsigned, then upper <= UINT_MAX is always true.
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #4 from Andrew Pinski --- (In reply to Alexander Monakov from comment #3) > Nice catch, thanks for the report. This is due to g:7d810646d421 > > The documentation should clarify that patterns correspond to basic fma > instructions (without intermediate rounding), and SLP pattern matching > should check flag_fp_contract_mode != FP_CONTRACT_OFF. I don't think they should. Because __builtin_fma (and fma and fmaf) should be able to be used from an user program and still get FMA instructions. And even the SLP instruction patterns can be generating using those.
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Alexander Monakov from comment #3)
> > Nice catch, thanks for the report. This is due to g:7d810646d421
> >
> > The documentation should clarify that patterns correspond to basic fma
> > instructions (without intermediate rounding), and SLP pattern matching
> > should check flag_fp_contract_mode != FP_CONTRACT_OFF.
>
> I don't think they should. Because __builtin_fma (and fma and fmaf) should
> be able to be used from an user program and still get FMA instructions. And
> even the SLP instruction patterns can be generating using those.
That is:
void f(float *a, float *b, float *c)
{
float t0 = __builtin_fmaf(a[0], b[0], c[0]);
float t1 = __builtin_fmaf(a[1], b[1], c[1]);
a[0] = t0;
a[1] = t1;
}
Should produce:
vmovq xmm0, QWORD PTR [rdi]
vmovq xmm2, QWORD PTR [rsi]
vmovq xmm1, QWORD PTR [rdx]
vfmadd132ps xmm0, xmm1, xmm2
vmovlps QWORD PTR [rdi], xmm0
ret
Even with -ffp-contract=off -march=haswell -O3
[Bug go/107491] Gccgo stack not resizing on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491 --- Comment #9 from Ian Lance Taylor --- I would suggest adding a new field to the GODEBUG parsing in go/runtime/runtime1.go and then calling a new C function defined in libgo/runtime/proc.c to store the value in a C static variable.
[Bug c++/107597] LTO causes static inline variables to get a non-uniqued global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107597 --- Comment #2 from Jan Hubicka --- Hi, What happens is that we read the symbol as: Visibility: externally_visible semantic_interposition prevailing_def_ironly_exp public weak comdat comdat_group:_ZN12NonTemplated1xE one_only While in visibility pass we promote it to: Visibility: externally_visible semantic_interposition prevailing_def_ironly_exp public comdat So we disolve comdat group and turn off weak. This leads to better code generation and we know it does not affect dynamic linking since in shared library all symbols are interposable. So this is kind of feature. How the ODR violations are detected? I wonder if keeping weak flag disturbs something.
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #6 from Alexander Monakov --- Sure, but I was talking specifically about the pattern matching introduced by that commit.
[Bug libstdc++/95048] [10/11/12/13 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 --- Comment #18 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b331bf303bdc1edead41e2b3d11d1a7804b433cf commit r13-3909-gb331bf303bdc1edead41e2b3d11d1a7804b433cf Author: Jonathan Wakely Date: Fri Nov 11 15:22:02 2022 + libstdc++: Fix wstring conversions in filesystem::path [PR95048] In commit r9-7381-g91756c4abc1757 I changed filesystem::path to use std::codecvt for conversions from all wide strings to UTF-8, instead of using std::codecvt_utf8. This was done because for 16-bit wchar_t, std::codecvt_utf8 only supports UCS-2 and not UTF-16. The rationale for the change was sound, but the actual fix was not. It's OK to use std::codecvt for char16_t or char32_t, because the specializations for those types always use UTF-8 , but std::codecvt uses the current locale's encodings, and the narrow encoding is probably ASCII and can't support non-ASCII characters. The correct fix is to use std::codecvt only for char16_t and char32_t. For 32-bit wchar_t we could have continued using std::codecvt_utf8 because that uses UTF-32 which is fine, switching to std::codecvt broke non-Windows targets with 32-bit wchar_t. For 16-bit wchar_t we did need to change, but should have changed to std::codecvt_utf8_utf16 instead, as that always uses UTF-16 not UCS-2. I actually noted that in the commit message for r9-7381-g91756c4abc1757 but didn't use that option. Oops. This replaces the unconditional std::codecvt with a type defined via template specialization, so it can vary depending on the wide character type. The code is also simplified to remove some of the mess of #ifdef and if-constexpr conditions. libstdc++-v3/ChangeLog: PR libstdc++/95048 * include/bits/fs_path.h (path::_Codecvt): New class template that selects the kind of code conversion done. (path::_Codecvt): Select based on sizeof(wchar_t). (_GLIBCXX_CONV_FROM_UTF8): New macro to allow the same code to be used for Windows and POSIX. (path::_S_convert(const EcharT*, const EcharT*)): Simplify by using _Codecvt and _GLIBCXX_CONV_FROM_UTF8 abstractions. (path::_S_str_convert(basic_string_view, const A&)): Simplify nested conditions. * include/experimental/bits/fs_path.h (path::_Cvt): Define nested typedef controlling type of code conversion done. (path::_Cvt::_S_wconvert): Use new typedef. (path::string(const A&)): Likewise. * testsuite/27_io/filesystem/path/construct/95048.cc: New test. * testsuite/experimental/filesystem/path/construct/95048.cc: New test.
[Bug libstdc++/95048] [10/11/12 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 Jonathan Wakely changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |wstring-constructor of |wstring-constructor of |std::filesystem::path |std::filesystem::path |throws for non-ASCII|throws for non-ASCII |characters |characters Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #19 from Jonathan Wakely --- Thanks for the patch, but I've fixed this slightly differently. The conditional logic was a mess, I hope it's easier to follow now. The fix has also been applied to experimental::filesystem::path. The fix still needs to be backported to the release branches. Thanks to everybody who helped me understand what the right conversions were here.
[Bug libstdc++/102839] filesystem::path::wstring runs in C locale / practically always throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102839 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Jonathan Wakely --- Dup of PR 95048 which is now fixed on trunk. *** This bug has been marked as a duplicate of bug 95048 ***
[Bug libstdc++/95048] [10/11/12 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 Jonathan Wakely changed: What|Removed |Added CC||jengelh at inai dot de --- Comment #20 from Jonathan Wakely --- *** Bug 102839 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #7 from Andrew Pinski --- (In reply to Alexander Monakov from comment #6) > Sure, but I was talking specifically about the pattern matching introduced > by that commit. The general rule for pattern matching is if you don't have a FMA (or FMA-like) don't try to generate a FMA when -ffp-contract=off is supplied. The target backend should NOT know about flag_fp_contract_mode for the FMA like patterns. It is up to the middle-end optimizers to produce the correct thing.
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 --- Comment #21 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:52672be7d328df50f9a05ce3ab44ebcae50fee1b commit r13-3910-g52672be7d328df50f9a05ce3ab44ebcae50fee1b Author: Nathaniel Shead Date: Fri Nov 11 22:23:31 2022 +1100 libstdc++: Set active union member in constexpr std::string [PR103295] Clang still complains about using std::string in constexpr contexts due to the changes made in commit 98a0d72a. This patch ensures that we set the active member of the union as according to [class.union.general] p6. libstdc++-v3/ChangeLog: PR libstdc++/103295 * include/bits/basic_string.h (_M_use_local_data): Set active member to _M_local_buf. Signed-off-by: Nathaniel Shead
[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106061
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #6 from Yann Droneaud ---
I'm reaching this bug too, compiling the following smaller reproducer:
extern void a(void);
inline void b(int c) { if (c) a(); }
void d(void) { b(0); }
[Bug libstdc++/107636] [13 regression] r13-3761-ga239a63f868e29 breaks build on powerpc64le with __float128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107636 Andrew Pinski changed: What|Removed |Added Keywords||build Target Milestone|--- |13.0
[Bug target/95885] LOCAL_DECL_ALIGNMENT and TARGET_LOWER_LOCAL_DECL_ALIGNMENT macro documentation should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95885 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Summary|LOCAL_DECL_ALIGNMENT macro |LOCAL_DECL_ALIGNMENT and |documentation is incorrect. |TARGET_LOWER_LOCAL_DECL_ALI ||GNMENT macro documentation ||should be improved Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- There is now TARGET_LOWER_LOCAL_DECL_ALIGNMENT which was added by r11-2259-g 0a9d711df36b42 . We should provide examples of when one should be used vs the other. And maybe even better describe why there are two target hooks that seems like does the same thing now. I am going to try to this for GCC 14 with the other target macro/hooks cleanups I am doing.
[Bug c++/105221] [10/11/12/13 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Started with r241944 most likely.
[Bug c++/107484] [13 Regression] ICE: Segmentation fault (in decls_match)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107484 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-11-11 Priority|P1 |P2 Ever confirmed|0 |1 CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Invalid -> not P1. Started with r13-3550-g38a628f52cf0ff commit 38a628f52cf0ff5db6708578248484d50a50b366 Author: Jason Merrill Date: Fri Oct 28 10:45:06 2022 -0400 c++: apply friend attributes sooner
[Bug target/107645] internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in symbolic_operand_1, at config/m68k/predicates.md:144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107645
--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
ICE in the reproducer is generated when predicate 'symbolic_operand' is applied
to the 'const' node in the following rtl:
(insn 342 341 343 35 (set (reg:SI 97)
(mem/u:SI (plus:SI (reg:SI 13 %a5)
(const:SI (unspec:SI [
(symbol_ref:SI ("__gcov_kvp_dynamic_pool_index")
[flags 0x40] )
(const_int 0 [0])
] 6))) [0 S4 A8])) "gcc/libgcc/libgcov.h":472:44 55
{*movsi_m68k2}
(expr_list:REG_EQUAL (symbol_ref:SI ("__gcov_kvp_dynamic_pool_index")
[flags 0x40] )
(nil)))
Wrapping symbolic expressions into the unspec was added in the commit that
implemented TLS for m68k, but the 'CONST' case in the predicate code was not
updated to filter wrapped expressions out.
[Bug tree-optimization/107523] [13 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu since r13-3628-g6fd485d15c1a2c42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107523 --- Comment #2 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:0a7b437ca71e2721e9bcf070762fc54ef7991aeb commit r13-3911-g0a7b437ca71e2721e9bcf070762fc54ef7991aeb Author: Andrew MacLeod Date: Fri Nov 11 12:22:33 2022 -0500 Don't add dependencies in update_stmt. gimple_ranger::update_stmt has no idea what the context of an update is, and should not be adding relations when it re-evaluates a stmt. PR tree-optimization/107523 gcc/ * gimple-range.cc (gimple_ranger::update_stmt): Use fur_stmt rather than fur_depend. gcc/testsuite/ * gcc.dg/pr107523.c: New.
[Bug tree-optimization/107523] [13 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu since r13-3628-g6fd485d15c1a2c42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107523 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Macleod --- fixed.
[Bug middle-end/107642] LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642 --- Comment #1 from Andrew Pinski --- A --param option was added in 2018 to override the setting of LOGICAL_OP_NON_SHORT_CIRCUIT : https://gcc.gnu.org/legacy-ml/gcc-patches/2018-11/msg02604.html But the way it is implemented is such that the override needs to happen in each place that LOGICAL_OP_NON_SHORT_CIRCUIT is used. This is fragil too.
[Bug middle-end/107642] LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642 --- Comment #2 from Andrew Pinski --- LOGICAL_OP_NON_SHORT_CIRCUIT has to be defined (if not already defined) in each file that uses it too. fold-const.cc:#ifndef LOGICAL_OP_NON_SHORT_CIRCUIT tree-ssa-ifcombine.cc:#ifndef LOGICAL_OP_NON_SHORT_CIRCUIT It would be better if it is defined in one place or better yet changed really to a target hook.
[Bug middle-end/107642] LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=17107 --- Comment #3 from Andrew Pinski --- r0-49401-g85e50b6ba8ca22 introduced RANGE_TEST_NON_SHORT_CIRCUIT. r0-63607-gb8610a53763f72 renamed it to LOGICAL_OP_NON_SHORT_CIRCUIT. r0-126134-g5d2a9da9a7f7c1 introduced LOGICAL_OP_NON_SHORT_CIRCUIT to tree-ssa-ifcombine.c to basically do what was done in fold-const.c at the time. But again as mentioned dojump.c still undid what was done on the gimple level.
