Re: [PATCH v6 0/4] P1689R5 support
On Fri, Jun 16, 2023 at 23:55:53 -0400, Jason Merrill wrote: > I see the same thing with patch 4 on x86_64-pc-linux-gnu, e.g. > > FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (test for excess errors) > Excess errors: > /home/jason/gt/gcc/testsuite/g++.dg/modules/ben-1_a.C:9:1: internal > compiler error: Segmentation fault > 0x19e2f3c crash_signal > /home/jason/gt/gcc/toplev.cc:314 > 0x340f3f8 mkdeps::vec::size() const > /home/jason/gt/libcpp/mkdeps.cc:57 > 0x340dc1f apply_vpath > /home/jason/gt/libcpp/mkdeps.cc:194 > 0x340e08e deps_add_dep(mkdeps*, char const*) > /home/jason/gt/libcpp/mkdeps.cc:318 > 0xea7b51 module_client::open_module_client(unsigned int, char const*, > mkdeps*, void (*)(char const*), char const*) > /home/jason/gt/gcc/cp/mapper-client.cc:291 > 0xef2ba8 make_mapper > /home/jason/gt/gcc/cp/module.cc:14042 > 0xf0896c get_mapper(unsigned int, mkdeps*) > /home/jason/gt/gcc/cp/module.cc:3977 > 0xf032ac name_pending_imports > /home/jason/gt/gcc/cp/module.cc:19623 > 0xf03a7d preprocessed_module(cpp_reader*) > /home/jason/gt/gcc/cp/module.cc:19817 > 0xe85104 module_token_cdtor(cpp_reader*, unsigned long) > /home/jason/gt/gcc/cp/lex.cc:548 > 0xf467b2 cp_lexer_new_main > /home/jason/gt/gcc/cp/parser.cc:756 > 0xfc1e3a c_parse_file() > /home/jason/gt/gcc/cp/parser.cc:49725 > 0x11c5bf5 c_common_parse_file() > /home/jason/gt/gcc/c-family/c-opts.cc:1268 Thanks. I missed a `nullptr` check before calling `deps_add_dep`. I think I got misled by `make check` returning a zero exit code even if there are failures. Thanks, --Ben
Re: Followup on PR/109279: large constants on RISCV
On 6/12/23 13:32, Vineet Gupta wrote: Gave this a try and it seems to fix Andrew's test, but then regresses the actual large const case: 0x1010101_01010101 : the mem to const_int transformation was being done in cse1 which no longer happens and the const pool from initial expand remains all the way into asm generated. I don't think we want to go back to that state Was that with just -O1/-Og? I have vague memories of seeing that kind of behavior. If it was just with -O1 that might be a reasonable tradeoff. Ok. From reading gccint it seems REG_EQUIV is a stronger form of equivalence and seems to be prefered by post reload passes, while REG_EQUAL is more of use in pre-reload. That's a reasonable way to look at it. In fact it's the allocators that promote REG_EQUAL to REG_EQUIV when its's safe to do so. I would also look at reload_cse_regs which should give us some chance at seeing the value reuse if/when IRA/LRA muck things up. I'll be out of office for the rest of week, will look into this once I'm back. NP. jeff
gcc-13-20230617 is now available
Snapshot gcc-13-20230617 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20230617/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision 4ca87c85ce285fac10caa98f2f430096f29b1fb6 You'll find: gcc-13-20230617.tar.xz Complete GCC SHA256=43ce82ff3ad9a9a59e4877bb164d50f7743cb1cf59a27f57767523d58694fb45 SHA1=9dcc2a210581f2481537c6c0f526eb022f7396ac Diffs from 13-20230610 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
