[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #12 from Alexandre Oliva --- Fixed
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 Alexandre Oliva changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #12 from Alexandre Oliva --- *** Bug 108602 has been marked as a duplicate of this bug. ***
[Bug c++/108602] FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108602 Alexandre Oliva changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Alexandre Oliva --- I've bisected the fail, that also occurred on arm-eabi, and that led me to the second patch for bug 112580. I'm thus marking this as a dupe. *** This bug has been marked as a duplicate of bug 112580 ***
[Bug c++/108602] FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108602 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Alexandre Oliva --- FWIW, I'm getting the same errors with gcc-13 on arm-vx7r2, but not on other vx7r2 targets. Some debugging showed that basic_format_args gets read from the module as __as_base, for reasons yet to be determined.
[Bug inline-asm/10153] [3.3/3.4 regression] selection of %dil or %sil on ia32 by valid C source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10153 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #13 from Alexandre Oliva --- FTR, the fix and the testcases were for bug 101534.
[Bug rtl-optimization/113660] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fnon-call-exceptions -fharden-control-flow-redundancy on invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113660 --- Comment #1 from Alexandre Oliva --- There's nothing specific about -fharden-control-flow-redundancy here, FWIW. ISTM that it just adds enough EH-related stuff to the function that an EH note gets attached to the impossible asm, a stmt then insn at the end of a block. Then, when vregs realizes that the asm has impossible constraints, it deletes it, and that loses the REG_EH_REGION note attached to it, which triggers the error. I'm not sure what the correct behavior would be, but presumably the note would have to be preserved/moved, or not required.
[Bug target/114059] ICE in extract_insn, at recog.cc:2812 | sme2 vs -fsanitize=address -mtrack-speculation -fharden-control-flow-redundancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114059 --- Comment #1 from Alexandre Oliva --- ISTM that -fharden-control-flow-redundancy is only instrumental to trigger the latent problem, but the real problem is in the back end: aarch64_restore_za emits a aarch64_cbnedi1 unconditionally, but insn aarch64_cb1 is disabled on aarch64_track_speculation, which the test uses.
[Bug debug/113777] ICE: in add_child_die_after, at dwarf2out.cc:5785 with -g -fsso-struct=big-endian and __attribute__((__hardbool__))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113777 --- Comment #1 from Alexandre Oliva --- Eric, I think this is yours. It fails while trying to add a reversed version of the hbool type to the context of the struct, but the struct doesn't have children yet, and add_child_die_after requires the context to have children already. The assumption that the original, unreversed type was introduced in the same context doesn't hold.
[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938 --- Comment #10 from Alexandre Oliva --- Thanks, yeah, I can duplicate the problem using the original testcase.
[Bug target/114137] ICE when building lua-5.4.6 with -fharden-control-flow-redundancy on x86 (error: invalid rtl sharing found in the insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114137 --- Comment #6 from Alexandre Oliva --- Thanks for the report. Something's very rotten here. cfrvisited is an automatic variable, why oh why would we have GOTOFF unspecs for it?!? I'd be interested in a preprocessed testcase that will trigger the problem. Failing that, I suppose I could try to drive a remote debug session if you're up for it. If it is indeed something related with GC as suggested (and it sounds plausible), the exact details of when it hits will depend on local hardware details and not necessarily carry over to other machines.
[Bug target/111935] gcc ICE with risc-v vector intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111935 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #4 from Alexandre Oliva --- Does the test pass in gcc-13 for anyone? ISTM that it doesn't. I bisected it and got to commit 973eb0deb467c79cc21f265a710a81054cfd3e8c AKA r14-3535, for bug 110943, as the first in which the test generates the expected number of matches of the vs... pattern.
[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988 --- Comment #10 from Alexandre Oliva --- Reasoning that the concurrent stores invoke undefined behavior would enable us to assume that the stores don't alias, which invalidates the reasoning in comment 1. Alas, I don't think gimple preserves enough information for us to tell that two statements used to be concurrent so as to derive optimization opportunities from them.
[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #9 from Alexandre Oliva --- ISTM that the test invokes undefined behavior because the assignment and the increment in the loop both modify the same storage without an intervening sequence point. ISTM that the dynamic type of that storage is thus uncertain, and accessing it afterwards, without an intervening store that resolves its type either way, would also invoke undefined behavior.
[Bug debug/113394] ICE: 'verify_type' failed: type variant with 'TYPE_ALIAS_SET_KNOWN_P' with -fstrub=internal -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113394 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Alexandre Oliva --- Fixed
[Bug debug/113394] ICE: 'verify_type' failed: type variant with 'TYPE_ALIAS_SET_KNOWN_P' with -fstrub=internal -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113394 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Last reconfirmed||2024-01-29 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Alexandre Oliva --- Mine
[Bug middle-end/112917] Most strub execution tests FAIL on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Alexandre Oliva --- Fixed
[Bug rtl-optimization/113002] ICE in commit_one_edge_insertion, at cfgrtl.cc:2095 with new -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113002 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Alexandre Oliva --- Fixed
[Bug rtl-optimization/113002] ICE in commit_one_edge_insertion, at cfgrtl.cc:2095 with new -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113002 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #3 from Alexandre Oliva --- Created attachment 56907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56907=edit candidate patch under test
[Bug rtl-optimization/113002] ICE in commit_one_edge_insertion, at cfgrtl.cc:2095 with new -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113002 Alexandre Oliva changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-12-20 --- Comment #2 from Alexandre Oliva --- Mine. memset gets expanded into a loop and inserted in an edge, and when committing the insertion, we complain that the sequence ends in a jump. AFAICT it's fine if it does during expand, we'll break up blocks at suitable spots only after committing the edge inserts from PHI nodes. Relaxing the assert...
[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Alexandre Oliva --- Fixed.
[Bug middle-end/112917] Most strub execution tests FAIL on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917 --- Comment #4 from Alexandre Oliva --- Ok, I understand the issues now. The problem on sparc32 is indeed the large register save area that __strub_leave allocates, that overlaps with stack space it's expected to scrub, and that thus doesn't get scrubbed. There's no inherent reason for __strub_leave to allocate a stack frame, the only reason it does is because of -fPIC. Compiling strub.c with -fno-PIC on sparc solves the problem, without any ill effects on libgcc_s.so (no global variables, no function calls), so I'm probably going with it. I have a patch that gets all strub tests to pass. The remaining problem on sparc64 is the bias in the stack pointer: the used stack space is usually outside the range delimited by the biased stack pointers. My plan to fix this is to modify __builtin_stack_address to return the unbiased address, as long as __builtin_frame_address is unbiased, or otherwise introduce target-specified unbiasing for them where the strub machinery currently uses the stack-pointing (biased) registers.
[Bug middle-end/112917] Most strub execution tests FAIL on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917 --- Comment #2 from Alexandre Oliva --- Nevermind, I've managed to log into the cfarm machines running solaris/sparc.
[Bug target/112334] ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Alexandre Oliva --- Fixed, though there's an (optional) followup, posted along with the fix, that's not clearly approved.
[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938 --- Comment #4 from Alexandre Oliva --- Patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640252.html
[Bug target/112778] ICE in ppc64-linux-gnu crosscompiler in store_by_pieces since r14-5946-g1ff6d9f7428b06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112778 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Alexandre Oliva --- Fixed
[Bug middle-end/112784] ICE in smallest_mode_for_size, at stor-layout.cc:356 | -finline-stringops -mavx512cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112784 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Alexandre Oliva --- Fixed
[Bug target/112804] ICE in aarch64 crosscompiler in plus_constant, at explow.cc:102 with -mabi=ilp32 and -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804 --- Comment #4 from Alexandre Oliva --- Fixed. Thanks for the notes and testing, Andrew, here and in the mailing list.
[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #3 from Alexandre Oliva --- Mine, thanks for the report, and for the reduced testcases!
[Bug middle-end/112917] Most strub execution tests FAIL on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917 Alexandre Oliva changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Last reconfirmed||2023-12-09 --- Comment #1 from Alexandre Oliva --- Hello, Rainer, The bulk of the documentation about strub is not at the options, that are indeed mostly developer-oriented implementation details, but in the attribute, referenced from the first of the strub options. It's about stack scrubbing, and the execution tests all follow roughly the same pattern: there's a body that gets a certain string onto the stack, a check before scrubbing that the string is there, and a check after scrubbing that the string is no longer there. I'm afraid I haven't had access to sparc hardware in a very long time; the sparc machines in the compile farm that I used before have long been down, and the solaris ones there aren't letting me in for some reason. I've looked at the asm output for the tests, and I see nothing particularly wrong. What's probably happening is that the test_string, stored in the s buffer within leak_string(), is getting into the stack range that, when the deferred_at_calls calls strub_leave, is used by strub_leave itself, so it doesn't get cleared. sparc is quite stack hungry in this regard, and ISTM that, if the register window doesn't get flushed, that range won't be overwritten at all, and the copy of test_string will remain there. If this theory is correct, this is a severe vulnerability in the stack scrubbing implementation on sparc. I'd envisioned overwriting some fixed stack range after an out-of-line strub_update (hand-coded assembly tail-called from strub_update could accomplish this), to catch just this kind of situation, but strub_update has been so lean in stack use that this didn't seem necessary. Now, for sparc, this seems to be essential. Could you please help me confirm this theory? Since it is likely that GDB would cause register window flushes that wouldn't occur in normal execution, inspecting the stack range would be little use, but checking the addresses would likely confirm it. Here's a debug session (on x86_64) that I'd appreciate if you could mirror on sparc. gdb strub-defer-O1 b 32 run p /x [7] b strub.c:103 continue p /x base p /x end If the theory is wrong, [7] will be between base and end, but if it's correct, it will be above end, and increasing PAD enough in the testcase would likely be enough to move the string out of the register window saving part of __strub_leave's frame, and make this (and other tests that define PAD) pass, confirming what we need for a proper fix. Thanks,
[Bug target/112778] ICE in ppc64-linux-gnu crosscompiler in store_by_pieces since r14-5946-g1ff6d9f7428b06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112778 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #2 from Alexandre Oliva --- Mine. Patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639987.html
[Bug target/112804] ICE in aarch64 crosscompiler in plus_constant, at explow.cc:102 with -mabi=ilp32 and -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804 Alexandre Oliva changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-12-09 --- Comment #2 from Alexandre Oliva --- Mine. Patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639986.html
[Bug middle-end/112784] ICE in smallest_mode_for_size, at stor-layout.cc:356 | -finline-stringops -mavx512cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112784 Alexandre Oliva changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Last reconfirmed||2023-12-09 --- Comment #1 from Alexandre Oliva --- Mine. Patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639985.html
[Bug target/112334] ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-12-06 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Alexandre Oliva --- The testcase changes silenced the noise that made the problem visible, but the latent bug is still lurking. The patch that cures the underlying bug is at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/638949.html
[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from Alexandre Oliva --- Thanks for the report, sorry about the regressions. The faulty patch was reverted, another patch with this and other problems fixed will be pushed shortly, once testing completes. I am not, however, taking this PR because this issue is pretty much resolved, and I understand there's another nvptx issue with weakundef symbols yet to be resolved, so I'm leaving this PR for that.
[Bug target/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411 --- Comment #4 from Alexandre Oliva --- yeah, its intended use case is for debugging -fcompare-debug fails, reducing superfluous differences between rtl dumps. In theory GCC may overflow insn uids regardless of this param, and if guarding against that is important, there should be code to check for it when incrementing insn uids, but I suppose we can live without that. Such limit values are definitely not useful for fuzz testing, but I'd be curious whether values that do not cause overflows would cause any codegen differences. I think not, and it really shouldn't, but this thought makes me hesitant to recommend against using this option for fuzz testing.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #44 from Alexandre Oliva ---
All configure --with-* and --enable-* options are stored in shell variables
named with_* and enable_*, respectively, so it's just a matter of testing for
yes (for --enable) or rather for no (for explicit --disable). Look for e.g.
--enable-initfini-array around line 1932 in $top_srcdir/gcc/configure.ac, or
with_avrlibc around line 1495 in gcc/config.gcc; you can do something similar
in gcc/config.host, without any explicit argument passing, because the
config.{host,gcc} files are sourced by configure, so they inherit all shell
variables.
[Bug debug/107169] [13/14 Regression] -fcompare-debug failure at -O and above since r13-2921-gf1adf45b17f7f1ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107169 --- Comment #5 from Alexandre Oliva --- It looks like r14-5257-g61d2b4746300a604469df15789194d0a7c73791b fixes this.
[Bug libstdc++/110807] [13 Regression] Copy list initialisation of a vector raises a warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110807 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #11 from Alexandre Oliva --- > The new test fails with -m32 I've looked a bit into why. The memmove is optimized out by vrp (or, if that's disabled, by dom) on lp64, because it's guarded by two conditions: _10 > sizeof(long), and !(_14 > 1), where _10 is a signed long (ptrdiff_t) computed as the difference between the _M_p of _M_finish and _M_start in the preexisting vector, and _14 = (unsigned long)(_10*8 + _8), where _8 is the vector's finish offset. in order for the _14 condition to hold, _14 must be 0ul..1ul. Since _10 is long, _8 promotes to long in lp64, the addition is performed as a signed long, and then converted to unsigned long. _8 is loaded from memory as an unsigned int, and nothing is known about it, so its promoted operand is 0l..0xl. In order for _14 to be <= 1ul, _10 * 8 must be in the range -0xl..1l, and therefore _10 must be <= 0x1fffl..0l, which enables folding of the _10 condition as the entire range is <= sizeof(long). In the lp32 case, _10 is int, so _10*8 promotes to unsigned int for the addition, whose result is then NOPped to unsigned long. _8 is also loaded from memory as unsigned int, but because unsigned addition wraps around and _8 covers the full range, nothing can be inferred about the range of _10*8, and thus _10's range is only limited by overflow-avoidance in the signed multiplication: -0x1fffl..0x1ffl. Therefore, the _10 compare cannot be folded, and the memmove call remains. I think the missed optimization and the overall problem stems from the fact that optimizers don't know the actual range of _M_offset. Ensuring it's visibly normalized at uses in which out-of-range _M_offsets might sneak in might be enough to avoid the warning and enable further optimizations.
[Bug tree-optimization/111943] ICE in gimple_split_edge, at tree-cfg.cc:3019 on 20050510-1.c with new -fharden-control-flow-redundancy with computed gotos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111943 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Alexandre Oliva --- Fixed
[Bug debug/109411] missing debug information with statement frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109411 --- Comment #2 from Alexandre Oliva --- AFAICT there are mentions to test.h line numbers both with and without -gstatement-frontiers, and the mentions are the same. The problem is two-fold: - there aren't any stmt markers for the lines in the template instantiation from test.h. absent stmt markers, is_stmt remains at zero throughout the function, except for its entry on line 6 - GDB appears to disregard !is_stmt locs entirely when setting breakpoints I suppose getting markers for the instantiation would fix the problem, but I don't have any insight into why they're not generated.
[Bug tree-optimization/111520] [14 Regression] ICE: verify_flow_info failed (error: probability of edge 3->8 not initialized) with -O -fsignaling-nans -fharden-compares -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111520 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexandre Oliva --- Fixed.
[Bug tree-optimization/111943] ICE in gimple_split_edge, at tree-cfg.cc:3019 on 20050510-1.c with new -fharden-control-flow-redundancy with computed gotos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111943 Alexandre Oliva changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-10-26 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #1 from Alexandre Oliva --- Created attachment 56315 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56315=edit candidate patch under test Mine. Thanks for the report, testing a fix.
[Bug middle-end/111942] ICE in rtl_split_edge, at cfgrtl.cc:1943 on pr98096.c with new -fharden-control-flow-redundancy with asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111942
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-10-26
Ever confirmed|0 |1
--- Comment #1 from Alexandre Oliva ---
Thanks for the report.
This latent bug is independent from -fharden-control-flow-redundancy.
The issue is that volatile asm stmts are considered throw points when
-fnon-call-exceptions is enabled.
I'm not sure where C++ wires non-call exceptions to enclosing handlers, but it
appears that it doesn't: even with a handler added around f's body, no EH edges
are added.
However, inlining f() into another function with a handler for the call will
wire all escaping exceptions to that handler, creating the same arrangement of
3 outgoing edges (fallthrough, asm jmp, and EH) that the rtl splitter barfs at.
/* compile with -fnon-call-exceptions */
int i, j;
int f(void) {
asm goto ("# %0 %2" : "+r" (i) ::: jmp);
i += 2;
asm goto ("# %0 %1 %l[jmp]" : "+r" (i), "+r" (j) ::: jmp);
jmp: return i;
}
int inline __attribute__ ((__always_inline__)) f(void);
int g(void) {
try {
return f();
} catch (...) {
i++;
throw;
}
}
./xgcc -B./ pr98096.cc -fno-harden-control-flow-redundancy
-fnon-call-exceptions
during RTL pass: expand
pr98096.cc: In function ‘int g()’:
pr98096.cc:19:1: internal compiler error: in rtl_split_edge, at cfgrtl.cc:1943
19 | }
[Bug tree-optimization/111520] [14 Regression] ICE: verify_flow_info failed (error: probability of edge 3->8 not initialized) with -O -fsignaling-nans -fharden-compares -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111520 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Alexandre Oliva --- Mine. Testing a fix.
[Bug middle-end/111904] Miscompilation with -O3 -fharden-control-flow-redundancy?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111904 Alexandre Oliva changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Alexandre Oliva --- AFAICT the test expects stackbuf to remain unchanged across do_secret_stuff calls, even though it's free stack space, but calling the hardcfr checker may scribble over it. But the real kicker is that, at -O3, do_secret_stuff gets two different versions for each of the pass numbers, and in the specialization for odd passes the stackbuf is optimized away entirely, and the visited bitmap ends up assigned at stack space that overlaps with the stackbuf allocated during the previous even pass, and that's what gets memcmp to fail at every execution. Adding attributes noclone and noipa to do_secret_stuff avoids the specializations, and then the test passes even at -O3.
[Bug libstdc++/109822] Converting std::experimental::simd masks yields an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #7 from Alexandre Oliva --- This test fails on powerpc targets when VSX support is unavailable.
[Bug debug/108784] '-fcompare-debug' failure (length) w/ --param ira-simple-lra-insn-threshold=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108784 --- Comment #2 from Alexandre Oliva --- Hello, Arseny, I have a hunch this could possibly be related with fixed bug 108573. Is this one by any chance fixed for you?
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 --- Comment #3 from Alexandre Oliva --- dump files now consistently take the base name from the output name, when not overridden since in this case gcc is called for (compiling and) linking, and the final output name is a.* (.out or .exe, depending on the platform), the prefix for dump files is taken to be 'a'. since there could be multiple source files, the source file name is then appended to the prefix to form each compilation's dump file base name. using the randomized temporary output names for each compilation wouldn't make for predictable dump file names, which was a primary motivator for this implementation. enabling separate dump files from multiple compilations of the same source file was another. change can be surprising, but the previous behaviors (they changed over time) were very often undesirable, now (because we have tons of tests for the current behavior) it will hopefully settle down, and will eventually feel intuitive and just "right" :-) thanks for bearing with us,
[Bug libstdc++/104852] std::[j]thread::detach() still gives segmentation faults with glibc 2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from Alexandre Oliva --- Should be fixed in the trunk (targeting 13). AFAIK it fails with 12 and 11. I know the patch works with 12, I've tested it there.
[Bug c++/105224] [modules] g++.dg/modules/virt-2_a.C: inline key methods: c++ modules and arm aapcs clash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105224 Alexandre Oliva changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2022-April/5 |il/gcc-patches/2023-Februar |92763.html |y/612175.html --- Comment #1 from Alexandre Oliva --- https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612175.html has a refreshed and retested (xfail) patch.
[Bug libstdc++/77760] get_time needs to set tm_wday amd tm_yday
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760 --- Comment #8 from Alexandre Oliva --- https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612198.html has a simple-minded implementation, that should make it clear what I mean by scratch: get() pays no regard to the incoming bits in tm, it initializes them with a zeroed-out state. Now, I realize that do_get, if called by a derived class with an uninitialized tm, might do weird things, because it would take some of those bits as state. Is this something of concern? As in, how internal and reserved for the implementation is the intermediate state of tm between get and do_get?
[Bug libstdc++/77760] get_time needs to set tm_wday amd tm_yday
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760 --- Comment #5 from Alexandre Oliva --- I'm not entirely sure what the point of testing for __clang__ is, really. Is libstdc++ used with, or supposed to be used (say, as a system library) with __clang__? If so, wouldn't it be useful if it actually worked as expected? Currently, the code compiles just fine, though it fails to parse %I%p if compiled with the actual __clang__ (or when __clang__ is defined on other compilers for whatever reasons, but that's besides the point). My thinking is that either libstdc++ headers are to work with clang, in which case there's an error in that bit, or they aren't, in which case the preprocessor test is superfluous and, in this oddball case, harmful. As for tm bits, my suggestion was to overwrite tm fields internally, not to expose that externally. They'd be used as scratch bits. As in, member functions in the public interface would not use incoming tm bits as __time_get_state, but rather a zeroed-out __time_get_state structure, as today, but when calling the internal implementation primitive do_get, they'd *blindly* *overwrite* some of the tm bits with those from __time_get_state, and when do-get returns, they'd pull them back into __time_get_state and out of tm. They'd be used as scratch bits, which AFAICT is permissible. do_get, being protected and thus more of an internal implementation bit, could make use of those scratch bits. do_get overriders could tweak them, for better or worse, but since this use would be nonstandard, we could probably get away with assuming any such uses to be libstdc++-specific. It would probably not be wise for users to rely on this internal extension, though, since one can hope the standard will eventually make room for an implementation of time_get that is both standard-compliant and compatible with reasonable strptime expectations.
[Bug libstdc++/77760] get_time needs to set tm_wday amd tm_yday
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #3 from Alexandre Oliva --- I'm looking at a case in which __clang__ is defined, despite compiling with GCC, and "%I...%p" parsing fails because the hack to pass state around doesn't work when __clang__ is defined. This got me thinking that there are more than enough bits in struct tm to encode all of __time_get_state in it, even with redundancy, so that overwritten fields could get recovered. I'm thinking that, before calling do_get, get would transfer its state onto struct tm in such a recoverable way, and, after calling it, it would restore state from struct tm and remove the extra out-of-range encodings. Our do_get, in turn, would extract state from struct tm, do its current job, and then pack the state back into struct tm. AFAICT this could be put in in an ABI-compatible way, dropping the hack and enabling libstdc++-specific do_get specializations to deal with such extended states, should we document them. Has anything along these lines already been considered and ruled out?
[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746 --- Comment #20 from Alexandre Oliva --- The bug is now either fixed or latent in the trunk, I'm not sure which, because I have not got as far as figuring out why removing unnecessary address cselib lookups in debug insns made a difference to memory overlap checks between nondebug insns. So I'm not sure whether to close this PR or leave it open. Thoughts?
[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746 --- Comment #17 from Alexandre Oliva --- Created attachment 54272 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54272=edit patch that fixes the problem for reasons not fully understood It seems that looking up the MEM exprs in DEBUG_INSNs disturbs something in cselib and causes pending MEMs to conflict that, in the non-debug case, don't. There's no need for these lookups in debug insns, the results aren't used, and I thought I'd just queue up this improvement but, to my surprise, it made the problem go away.
[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746 --- Comment #16 from Alexandre Oliva --- Sorry it took me so long to react, I'd missed the question. IIRC the scheduler was the hardest part of GCC to make work with debug insns. The general strategy is that nondebug insns never depend on debug insns, while debug insns depend on the preceding insns and on the previous debug insn, besides the deps it would have if it were a regular insn. This generally enables debug insns to be issued right after the insn that produces the side effect it notes, but if the nondebug insn is pulled ahead, the ordering WRT other debug insns keeps the debug views consistent with the ordering of side effects in source code. They shouldn't, however, prevent a nondebug insn from being pulled ahead of them. We take note of conflicts to invalidate the expression in the debug insn, rather than to prevent reordering. That's the theory, and there have been plenty of deviations from that caught by -fcompare-debug and fixed during the VTA development, but it was tricky enough that selective scheduling could never be made VTA-safe. It's not what's in use for x86, though, so this must be something else.
[Bug c++/107873] New: C++ without SUPPORTS_ONE_ONLY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107873
Bug ID: 107873
Summary: C++ without SUPPORTS_ONE_ONLY
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
Created attachment 53967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53967=edit
working patch with SUPPORTS_ONE_ONLY, incomplete fix for !SUPPORTS_ONE_ONLY
I've attempted disabling SUPPORTS_ONE_ONLY to use a linker that supported weak
symbols but had some issues with comdat, and that didn't go well.
Several symbols with vague linkage, and that thus should be output as weak
definitions, were issued as strong definitions instead. The scenarios involved
make_decl_one_only's checking of DECL_INITIAL before it was set, such as when
deciding between .common or .weak for typeinfo objects and for static variables
in inlined functions. The attached patch fixes that, and bootstraps on
x86_64-linux-gnu with SUPPORTS_ONE_ONLY, and also on another non-pthreads
target without SUPPORTS_ONE_ONLY.
Without SUPPORTS_ONE_ONLY, the GNU/Linux bootstrap fails because pthread_once
is not weakref'ed in libstdc++: flag_weak is set to false, so we define
__GXX_WEAK__=0. According to my reading of the documentation, __GXX_WEAK__
means whether symbols with vague linkage can be output as unifiable definitions
in multiple translation units (so SUPPORTS_ONE_ONLY could have it enabled
through comdat even with -fno-weak), so I tried this patchlet:
diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index 333f3e138d611..15ef47c0c04f5 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -939,7 +939,15 @@ c_cpp_builtins (cpp_reader *pfile)
if (c_dialect_cxx ())
{
- if (flag_weak && SUPPORTS_ONE_ONLY)
+ /* __GXX_WEAK__'s name is misleading, the documentation says it
+tests for one-only spuport, but SUPPORTS_ONE_ONLY is also
+slightly misleading, because weak symbols can be used for
+one-only support even if !SUPPORtS_ONE_ONLY. Here we
+approximate the supprots_one_only() test that may clear
+flag_weak, but we use the flag_weak result instead of
+TARGET_SUPPORTS_WEAK, because the user may have disabled weak
+symbols with -fno-weak. */
+ if (flag_weak || SUPPORTS_ONE_ONLY)
cpp_define (pfile, "__GXX_WEAK__=1");
else
cpp_define (pfile, "__GXX_WEAK__=0");
However, libstdc++ also uses it as telling whether weak undef / weakref is
available at all, a significant latent ambiguity that seems tricky and risky to
resolve without introducing two new macros, one for each independent meaning.
(there are tests in g++.dg and libstdc++ testsuites that use it in one meaning
or the other)
Without SUPPORTS_ONE_ONLY, despite the availability of weak symbols, and
regardless of arranging for flag_weak to remain enabled, some symbols with
vague linkage fail to be output. I have not investigated further, but one
example of simple test that fails in this configuration is g++.dg/abi/vtt1.C.
So the attached patch, though fixing some latent problems and not introducing
any to comdat-enabled C++, doesn't go all the way in making a comdat-less C++
compiler possible, so I'm not planning on submitting it for inclusion at this
point. However, since I don't have plans to pursue this further, I hereby
contribute it as a starting point for anyone who might be interested in taking
it towards completion.
[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 c++/106898] New: ECF_NOTHROW for __cxa_deleted_virtual or not for __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106898 Bug ID: 106898 Summary: ECF_NOTHROW for __cxa_deleted_virtual or not for __cxa_pure_virtual Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aoliva at gcc dot gnu.org Target Milestone: --- I see no reason for the difference WRT ECF_NOTHROW between __cxa_deleted_virtual and __cxa_pure_virtual library declarations pushed in decl.cc and class.cc, respectively. Their implementations behave essentially the same, I suppose both might be user-overridable (though I see no evidence that this is indeed the case), and neither promises not to throw in the C++ ABI document (but I realize throwing from either one could be problematic if the virtual method happens to be nothrow). Unless there's good reason to keep this flag difference, IMHO it would be desirable to resolve the inconsistency one way or another.
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #18 from Alexandre Oliva --- on x86_64 with -fPIC or -fpic, my_guard's address is indeed loaded from the GOT with @GOTPCREL indeed on x86_64 with -fPIE or -fpie, however, it is used just as expected by the testcase. which should be fine as long as my_guard is required to be a link-time defined constant. but if it is, then there's no point in loading its address from the GOT, not on x86_64 PIC, not on ia32 PIC/PIE. thus my question. something's fishy there.
[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782 --- Comment #10 from Alexandre Oliva --- sorry, I typoed the failing test. it's in g++.dg/ext, and it has a .C extesion. how unfortunate that there was another test matching the lower-case name I typoed.
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 Alexandre Oliva changed: What|Removed |Added Status|RESOLVED|REOPENED CC||aoliva at gcc dot gnu.org Resolution|FIXED |--- --- Comment #15 from Alexandre Oliva --- Uroš, stack-prot-sym.c fails on ia32 with PIC/PIE: the address/value of my_guard is loaded from the GOT, instead of appearing as %gs:my_guard. After being confused by the expectation that my_guard should be a LE TLS symbol, I'm coming to the conclusion that my expectation was incorrect, and it is indeed supposed to be a plain offset, so the code is correct, if not as efficient as on PDC. Does that sound right? I'm undecided as to whether avoiding the GOT reference, and requiring the symbol to be usable as a link-time constant, would be desirable/doable. Thoughts?
[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #8 from Alexandre Oliva ---
I'm running into some problems that are related with this PR.
First off, on i686-linux-gnu with --enable-default-pie, attr-ifunc-3.c fails to
link with e.g. binutils 2.30 (the linker in Trisquel 9), from before binutils
commit 4ec0995016801cc5d5cf13baf6e10163861e6852. The error was "relocation
R_386_GOTOFF against STT_GNU_IFUNC symbol `foo' isn't supported".
Using a binutils 2.38.50 from May 2022, it doesn't fail to link, but it fails
at runtime. The @GOTOFF relocation to the IFUNC appears to be handled
correctly only in PDEs.
I figured @GOTOFF for IFUNCs was an unreliable feature to use on x86, and
patched predicates.md:local_symbolic_operand to return !ix86_call_use_plt_p
(op) instead of true for SYMBOL_REF_LOCAL_P. That got (pun not intended)
attr-ifunc-3.c to pass, but regressed the testcases named after this PR.
I started looking into how it was supposed to work, and how it managed to work
on x86_64, and understood the reasoning of forcing into existence and using the
PLT entry as the canonical address for the IFUNC. That works for hidden
visibility, but I wondered, what if the symbol bound locally in a shared lib,
but was still visible to the main executable, i.e., protected visibility?
Alas, even on x86_64, that resolves the IFUNC to different canonical addresses.
Specifically, compiling and linking pr83782-1.c s/hidden/protected/ into a
shared library, and then compiling and linking the following main program with
this library, the function calls succeed, but the pointer compare fails:
extern void foo (void);
extern void *bar(void);
int main() {
void (*p)(void) = bar();
p();
foo();
if (p != foo)
__builtin_abort ();
}
ISTM the test has to be stricter than binding locally, it has to either be
known to be part of the main executable (-fPIE/-fpie) or known not to be
visible to other loadable modules.
As for x86, I don't see that it's prudent to use @GOTOFF for IFUNC even with
-fPIC: even if the PIE linker bug is fixed, regular PIC may be used in PIE, and
linkers since 2018 will silently misresolve the relocation. WDYT?
[Bug target/81652] [meta-bug] -fcf-protection=full bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 85620, which changed state. Bug 85620 Summary: Missing ENDBR after swapcontext https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug middle-end/85620] Missing ENDBR after swapcontext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620 Alexandre Oliva changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED CC||aoliva at gcc dot gnu.org --- Comment #10 from Alexandre Oliva --- ISTM that if you have to insert an endbr over indirect_return, a call should only be eligible for sibcall if the caller is also marked with indirect_return, otherwise the callee will indirectly return directly to an upstack caller that may not have an endbr after the call, no?
[Bug tree-optimization/105665] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105665 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #5 from Alexandre Oliva --- Mine. The problem is that the undef name may appear deep in a chain of phis, instead of appearing directly in the base expr.
[Bug rtl-optimization/105455] ICE: verify_flow_info failed (error: verify_flow_info: REG_BR_PROB does not match cfg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105455 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Alexandre Oliva --- Fixed, trunk and gcc-12.
[Bug rtl-optimization/105455] ICE: verify_flow_info failed (error: verify_flow_info: REG_BR_PROB does not match cfg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105455 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #2 from Alexandre Oliva --- Created attachment 52951 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52951=edit Candidate patch Mine. This patch appears to cure it. Regstrapping...
[Bug c++/105324] std::from_chars() assertion at floating_from_chars.cc:78 when parsing 1.11111111....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105324 Alexandre Oliva changed: What|Removed |Added Status|REOPENED|RESOLVED Component|libstdc++ |c++ Resolution|--- |FIXED --- Comment #10 from Alexandre Oliva --- Testcase adjustments are all in.
[Bug c++/105324] std::from_chars() assertion at floating_from_chars.cc:78 when parsing 1.11111111....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105324 Alexandre Oliva changed: What|Removed |Added Status|RESOLVED|REOPENED CC||aoliva at gcc dot gnu.org Resolution|FIXED |--- --- Comment #5 from Alexandre Oliva --- The from_chars overloads for floating-point types are guarded by #if _GLIBCXX_HAVE_USELOCALE The test fails with ugly overload resolution and template substitution messages over the template from_chars for integral types when the macro is not defined to nonzero. Should the test use a similar conditional? (I'll be happy to submit a patch)
[Bug target/105359] _Float128 expanders and builtins disabled on ppc targets with 64-bit long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105359 --- Comment #1 from Alexandre Oliva --- pr82748-1.c is another victim of this issue. do_copysign_ld needs to convert between (64-bit) long double and __ieee128 for __builtin_copysignq, and since the expanders for these conversions are conditioned on TARGET_LONG_DOUBLE_128, we end up issuing libcalls, but the test doesn't want any 'bl' opcode.
[Bug testsuite/105267] [12 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105267 --- Comment #3 from Alexandre Oliva --- HaoChen Gui posted a proposal for a narrower pattern here https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593389.html
[Bug target/105359] New: _Float128 expanders and builtins disabled on ppc targets with 64-bit long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105359 Bug ID: 105359 Summary: _Float128 expanders and builtins disabled on ppc targets with 64-bit long double Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: aoliva at gcc dot gnu.org Target Milestone: --- Target: rs6000 As described elsewhere, some tests fail on targets with 64-bit long double, because of patterns that (IMHO incorrectly) use TARGET_LONG_DOUBLE_128 in their conditions, and because of type compatibility tests that only accept _Float128 types under the same condition. https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593257.html https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593515.html There doesn't seem to be a reason for the patterns to conditioned on long double being a 128-bit type: that's too strict. A laxer condition, covering the requirements for _Float128 to be *supported*, ought to be enough. Furthermore, there doesn't seem to be any reason for -mlong-double-64 to disable those patterns even on target variants that use 128-bit long double. It's too late to fix this for GCC 12, but hopefully some rs6000/powerpc maintainer will agree that there's no reason to tie support for insn patterns and builtins for _Float128 with long double's being the same type as _Float128. It looks like all of the troublesome patterns have TARGET_HARD_FLOAT && TARGET_LONG_DOUBLE_128. I hope this problem could be fixed by replacing the latter with TARGET_FLOAT128_TYPE, but I'll defer to more knowledgeable port maintainers.
[Bug target/102146] [11 regression] several test cases fails after r11-8940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #6 from Alexandre Oliva --- I confirm that segher's patch restores the expected insns in prefix-no-update.
[Bug c++/105224] New: [modules] g++.dg/modules/virt-2_a.C: inline key methods: c++ modules and arm aapcs clash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105224 Bug ID: 105224 Summary: [modules] g++.dg/modules/virt-2_a.C: inline key methods: c++ modules and arm aapcs clash Product: gcc Version: unknown URL: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/5 92763.html Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aoliva at gcc dot gnu.org Blocks: 103524 Target Milestone: --- Target: arm-eabi g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets that use the AAPCS variant. ARM is the only target that overrides TARGET_CXX_KEY_METHOD_MAY_BE_INLINE. It's not clear to me which way the clash between AAPCS and C++ Modules design should be resolved, but currently it favors AAPCS and thus the test fails. Skipping the test or conditionally dropping the inline keyword breaks subsequent tests. The patchlet in the URL XFAILs the expectations of the keyed symbols on arm*-*-*. https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592763.html Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug debug/105161] variable constant-folded in its uses appears as optimized out depending on where it is assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105161 --- Comment #2 from Alexandre Oliva --- Debug binds in edges was something I considered for some time, but concluded it would be unlikely to bring useful debug information: the confluence operator for debug-bind-capable decls during var-tracking dataflow analysis intersects incoming bindings, so whatever we placed in a single edge would likely end up discarded. Conditional locations might preserve that, but it's not clear those would be representable in DWARF. I suppose a path for improvement would be, instead of dropping the debug binds or adding resets to all blocks, to introduce some analysis to come up with a better bind, using e.g. PHI nodes in the outgoing blocks. I'm afraid I don't have a clue as to how to implement that efficiently, or at all, though :-/
[Bug debug/104564] '-fcompare-debug' failure w/ -std=c++20 -O1 -fharden-conditional-branches -fopenacc -gno-statement-frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104564 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexandre Oliva --- Fixed
[Bug middle-end/104975] ICE in execute, at gimple-harden-conditionals.cc:577 and returns_twice and pure attributes on the same function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104975 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Alexandre Oliva --- Fixed
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #17 from Alexandre Oliva --- The patch went in on 2022-03-02, commit 12f8dc0b642db5edc702f252af1a5231606b29db, but I failed to tag this PR in the commit message.
[Bug debug/104564] '-fcompare-debug' failure w/ -std=c++20 -O1 -fharden-conditional-branches -fopenacc -gno-statement-frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104564 Alexandre Oliva changed: What|Removed |Added Last reconfirmed||2022-03-24 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Alexandre Oliva --- Created attachment 52677 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52677=edit Candidate patch Mine. Looks like it's the copied identifiers that get -fcompare-debug to fail. We don't need them, and without them, the failure is gone.
[Bug middle-end/104975] ICE in execute, at gimple-harden-conditionals.cc:577 and returns_twice and pure attributes on the same function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104975 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Alexandre Oliva --- Created attachment 52676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52676=edit Candidate patch Mine. I'm testing this fix.
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 --- Comment #16 from Alexandre Oliva --- Created attachment 52518 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52518=edit Candidate patch The problem is in undo_optional_reloads. Here's a fix I'm testing.
[Bug target/104121] [12 Regression] v850: Infinite loop in find_reload_regno_insns() since r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Alexandre Oliva --- Fixed
[Bug tree-optimization/103845] ICE in execute, at gimple-harden-conditionals.cc:552 -fharden-compares -fno-ipa-pure-const and returns_twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103845 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Alexandre Oliva --- Already fixed, testcase added.
[Bug middle-end/104540] ICE: SIGSEGV in cfi_oprnd_equal_p with -O2 -fharden-conditional-branches -mforce-drap -mstackrealign --param=max-grow-copy-bb-insns=125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104540 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexandre Oliva --- Fixed
[Bug tree-optimization/103856] ICE during GIMPLE pass: hardcmp since r12-4759-g95bb87b2458bfab4 and -fnon-call-exceptions -fsignaling-nans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103856 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Alexandre Oliva --- Fixed
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 Alexandre Oliva changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- URL|https://gcc.gnu.org/piperma | |il/gcc-patches/2021-Decembe | |r/586370.html | --- Comment #14 from Alexandre Oliva --- The installed patch is wrong and will be reverted.
[Bug target/104121] [12 Regression] v850: Infinite loop in find_reload_regno_insns() since r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121 Alexandre Oliva changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103302 --- Comment #11 from Alexandre Oliva --- Ok, now I think the patch for bug 103302, that brought us this regression, is wrong. Unlike the old reload, lra computes live ranges for reload pseudos, and without the clobbers, they end up much longer, possibly overlapping, to the point that assignments become impossible. But this is unrelated with the loop. find_reload_regno_insns assumes single-insn input and output reloads, and it won't find sequences like those emitted by emit_move_multi_word (or emit_move_complex_parts, for that matter). That was fine when we had sequences that amounted to a clobber plus a pair of moves, because those plus start_insn added up to more than 3, the cut-off for find_reload_regno_insns before entering the endless loop. But an expander for a reload insn that issued two insns could, AFAICT, trigger the problem in which we find a first_insn and then loop forever looking for the second_insn after next_insn became NULL and prev_insn isn't looked at any more, or vice-versa for an output reload. Alas, neither of the fixes for that solve the problem: - getting the loop to terminate and return false when we won't find all of the reload insns with the current logic gets us an infinite loop one level up, as we attempt to spill the reg and assign it again indefinitely. - getting the loop to recognize the entire contiguous sequences, which is what we should probably do, enables progress, but then, we issue more reloads, and because of the extended live ranges, we also fail to assign them, and so on, until we hit the lra max iteration count. Restoring the clobber renders these changes unnecessary, and I guess that's what we should do. It will however bring back the obscure reloading problem we had on risc-v, that likely affects v850 as well, in which a shared register assignment crossing such a clobber could end up killing the source assigned to the same hardware register before copying it to the reload destination. That is far less common, but far more painful when it silently hits.
[Bug target/104121] [12 Regression] v850: Infinite loop in find_reload_regno_insns() since r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
--- Comment #10 from Alexandre Oliva ---
and then, as I reduced it myself down to the following and compared with the
minimized test, I've finally turned on both of my neurons ;-) and it finally
hit me: "only with -mv850e2v3" didn't mean "not with other multilibs", but
rather "without any optimization". of course, none of the minimized test would
survive with optimization. doh!
this one triggers with -O2 -g -mv850e2v3:
typedef float DFtype __attribute__ ((mode (DF)));
typedef _Complex float DCtype __attribute__ ((mode (DC)));
DCtype
__muldc3 (DFtype a, DFtype b, DFtype c, DFtype d)
{
DFtype x = __builtin_huge_val () * (a * c - b * d);
DFtype y = __builtin_huge_val () * (a * d + b * c);
DCtype res;
__real__ res = x;
__imag__ res = y;
return res;
}
[Bug target/104121] [12 Regression] v850: Infinite loop in find_reload_regno_insns() since r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from Alexandre Oliva --- Thanks, I've succeeded in duplicating the problem with the preprocessed testcase, both with the earlier tree and with a more recent one. Now I can look into it.
[Bug target/104121] [12 Regression] v850: Infinite loop in find_reload_regno_insns() since r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121 --- Comment #7 from Alexandre Oliva --- I mean, even with commit 50e8b0c9bca6cdc57804f860ec5311b641753fbb
[Bug target/104121] [12 Regression] v850: Infinite loop in find_reload_regno_insns() since r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121 --- Comment #6 from Alexandre Oliva --- No luck, even with commit ./xgcc -B./ -O2 -g pr104121.c -mv850e2v3 -mno-app-regs -msmall-sld -fbuilding-libgcc -fno-stack-protector do I actually need binutils to enable something essential in GCC to trigger the bug?
[Bug target/104121] [12 Regression] v850: Infinite loop in find_reload_regno_insns() since r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121 --- Comment #5 from Alexandre Oliva --- Do you still get this? I can't trigger the problem with the reduced testcase with -O2 -g -mv850e2v3, on a cross to v850-rtems hosted on x86_64-linux-gnu.
[Bug tree-optimization/103845] ICE in execute, at gimple-harden-conditionals.cc:552 -fharden-compares -fno-ipa-pure-const and returns_twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103845 --- Comment #5 from Alexandre Oliva --- Confirmed. The first patch there. I will still prepare a patch with the testcase to avoid an independent regression.
[Bug tree-optimization/103845] ICE in execute, at gimple-harden-conditionals.cc:552 -fharden-compares -fno-ipa-pure-const and returns_twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103845 Alexandre Oliva changed: What|Removed |Added Depends on||104263 --- Comment #4 from Alexandre Oliva --- I'm pretty sure it was the patch for bug 104263 that fixed it. Confirming... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104263 [Bug 104263] [10/11 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531
[Bug middle-end/104540] ICE: SIGSEGV in cfi_oprnd_equal_p with -O2 -fharden-conditional-branches -mforce-drap -mstackrealign --param=max-grow-copy-bb-insns=125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104540 --- Comment #2 from Alexandre Oliva --- Created attachment 52459 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52459=edit candidate patch under test Here's a candidate fix
[Bug middle-end/104540] ICE: SIGSEGV in cfi_oprnd_equal_p with -O2 -fharden-conditional-branches -mforce-drap -mstackrealign --param=max-grow-copy-bb-insns=125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104540 Alexandre Oliva changed: What|Removed |Added Last reconfirmed||2022-02-17 Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Alexandre Oliva --- Mine. Confirmed.
[Bug tree-optimization/103845] ICE in execute, at gimple-harden-conditionals.cc:552 -fharden-compares -fno-ipa-pure-const and returns_twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103845 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #2 from Alexandre Oliva --- Mine. I can't duplicate this with a current compiler.
[Bug tree-optimization/103856] ICE during GIMPLE pass: hardcmp since r12-4759-g95bb87b2458bfab4 and -fnon-call-exceptions -fsignaling-nans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103856 --- Comment #4 from Alexandre Oliva --- Created attachment 52458 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52458=edit candidate patch under test Here's a proposed fix
[Bug tree-optimization/103856] ICE during GIMPLE pass: hardcmp since r12-4759-g95bb87b2458bfab4 and -fnon-call-exceptions -fsignaling-nans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103856 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Alexandre Oliva --- Mine
