[Bug testsuite/99371] New: add_options_for_sqrt_insn is missing options that enable powerpc's fsqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99371 Bug ID: 99371 Summary: add_options_for_sqrt_insn is missing options that enable powerpc's fsqrt Product: gcc Version: unknown URL: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/5 65995.html Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: aoliva at gcc dot gnu.org Target Milestone: --- Target: powerpc*-*-* "dg-add-options feature" is meant to add flags that enable the desired feature, and to skip the test if that's not possible. Though the fsqrt insn is available when -mno-soft-float -mpowerpc-gpopt options are used, no options are added for the sqrt_insn feature on powerpc*-*-*. Regardless of bug 99352, adding these options would implement the intended functionality.
[Bug tree-optimization/99372] New: gimplefe-28.c ICEs when sqrt insn is not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99372 Bug ID: 99372 Summary: gimplefe-28.c ICEs when sqrt insn is not available Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aoliva at gcc dot gnu.org Target Milestone: --- Try to compile gimplefe-28.c from the testsuite with -mno-powerpc-gpopt or -msoft-float on a powerpc target, and it will ICE, because it doesn't check for the availability of the .SQRT instrinsic explicitly called in the test. Fixes for the See-Also bugs are likely to prevent the bug from showing up in test results.
[Bug tree-optimization/95401] [10 Regression] GCC produces incorrect instruction with -O3 for AVX2 since r10-2257-g868363d4f52df19d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95401 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #7 from Alexandre Oliva --- How important is it that the test added for this PR be split into two separate source files? I ask because, on targets that support vectors, but the vector unit is not enabled in the default configuration, vect.exp makes compile the default action, instead of run, and with additional sources, compile fails because one can't compile multiple sources into a single asm output.
[Bug target/99372] gimplefe-28.c ICEs when sqrt insn is not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99372 --- Comment #2 from Alexandre Oliva --- I didn't mean that the testcase didn't check, I meant that the gimple parser didn't check. It swallows the .SQRT call even though it the attempt to expand the call will ICE because there's no usable opcode: [aoliva@gcc1-power7 gcc]$ ./xgcc -B./ ../../gcc/testsuite/gcc.dg/gimplefe-28.c - fgimple -msoft-float during RTL pass: expand ../../gcc/testsuite/gcc.dg/gimplefe-28.c: In function ‘f1’: ../../gcc/testsuite/gcc.dg/gimplefe-28.c:6:1: internal compiler error: in expand _direct_optab_fn, at internal-fn.c:3360 6 | f1 (double x) | ^~ 0x10d017d7 expand_direct_optab_fn ../../gcc/internal-fn.c:3360 0x10d076bf expand_SQRT ../../gcc/internal-fn.def:256 0x10d09187 expand_internal_call(internal_fn, gcall*) ../../gcc/internal-fn.c:4079 0x10d091db expand_internal_call(gcall*) ../../gcc/internal-fn.c:4087 0x1087e637 expand_call_stmt ../../gcc/cfgexpand.c:2749 [...] internal-fn.c:3359: insn_code icode = direct_optab_handler (optab, TYPE_MODE (types.first)); gcc_assert (icode != CODE_FOR_nothing); As an altenative for the gimple parser's checking, I suppose we could have an expander that fell back to a regular function call, though the assert check suggests we didn't expect the intrinsic call to be present when the opcode is not available. cdce3.c suggests other parts of the compiler can tell, ahead of expand, whether a sqrt insn is available, to decide whether or not to shrink-wrap, so it might make sense to use the same test here. I haven't identified what the early test is.
[Bug tree-optimization/95401] [10 Regression] GCC produces incorrect instruction with -O3 for AVX2 since r10-2257-g868363d4f52df19d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95401 --- Comment #9 from Alexandre Oliva --- It is definitely a problem in the dg infrastructure that compile mode doesn't work with additional sources, but fixing that seems quite involved, more than I can tackle right now. I've tried to duplicate the problem with a single test source file, with the compiler commit mentioned in the initial report, but failed, and it wasn't just because of the type inconsistency between var_14 across the current units. I suppose the alignment miscomputation, that caused an aligned vector store insn to be incorrectly used, doesn't come up when the alignment is known, and much stricter than what can be assumed for an external symbol. Oh well...
[Bug testsuite/99371] add_options_for_sqrt_insn is missing options that enable powerpc's fsqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99371 Alexandre Oliva changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2021-March/5 |il/gcc-patches/2021-Februar |65995.html |y/565939.html --- Comment #1 from Alexandre Oliva --- Uhh, sorry, looks like I put the wrong URL in the initial report.
[Bug c++/96078] [10 Regression] flatten attribute on constructor and destructor causes spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96078 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #8 from Alexandre Oliva --- FWIW, I've just confirmed a fail of attr-flatten-1.c in gcc-10, targeting ppc64-vxw7r2. The expected warning is not issued. I haven't tried other targets or branches yet.
[Bug c/99363] [10,11 regression] gcc.dg/attr-flatten-1.c fails starting with r11-7469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99363 Alexandre Oliva changed: What|Removed |Added Resolution|FIXED |--- Summary|[11 regression] |[10,11 regression] |gcc.dg/attr-flatten-1.c |gcc.dg/attr-flatten-1.c |fails starting with |fails starting with |r11-7469|r11-7469 Status|RESOLVED|REOPENED CC||aoliva at gcc dot gnu.org --- Comment #5 from Alexandre Oliva --- Jason's patch was backported to gcc-10, but Jakub's patch AFAICT wasn't, so the fail remains there.
[Bug target/100228] New: repeated std::atomic::load() misoptimized by x87 peephole
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100228
Bug ID: 100228
Summary: repeated std::atomic::load() misoptimized by
x87 peephole
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: i686-pc-linux-gnu
compile this with -O2 -mfpmath=387 -mno-sse
#include
int main() {
std::atomic a0;
std::atomic a1(1.0);
a0 = a1.load();
if (a0.load() != a1.load())
__builtin_abort ();
}
it aborts because the first a1.load() is optimized by sync.md:398:
(define_peephole2
[(set (match_operand:DF 0 "memory_operand")
(match_operand:DF 1 "any_fp_register_operand"))
(set (mem:BLK (scratch:SI))
(unspec:BLK [(mem:BLK (scratch:SI))] UNSPEC_MEMORY_BLOCKAGE))
(set (match_operand:DF 2 "fp_register_operand")
(unspec:DF [(match_operand:DI 3 "memory_operand")]
UNSPEC_FILD_ATOMIC))
(set (match_operand:DI 4 "memory_operand")
(unspec:DI [(match_dup 2)]
UNSPEC_FIST_ATOMIC))]
"!TARGET_64BIT
&& peep2_reg_dead_p (4, operands[2])
&& rtx_equal_p (XEXP (operands[0], 0), XEXP (operands[3], 0))"
[(const_int 0)]
{
emit_insn (gen_memory_blockage ());
emit_move_insn (gen_lowpart (DFmode, operands[4]), operands[1]);
DONE;
})
the memory location operands[0] stored into by the first instruction is reused
and loaded again in the second a1.load(), but after this peephole, there's no
store before the load.
I don't think we have infrastructure in peephole to test whether there are any
other uses of a store, so I think we have to keep it. There are other
variations of this peephole around it, that appear to have the same problem.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Alexandre Oliva --- Mine
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #5 from Alexandre Oliva --- Created attachment 49427 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49427&action=edit patch that should fix the remaining s390 problem So, the issue is already fixed on aarch64-*, powerpc*-*, and sparc*-sun-solaris*. Stefan, could you possibly confirm that this patch fixes it on s390? I've put in the fix for sparc*-linux-gnu as well, for good measure.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Alexandre Oliva --- Fixed
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #17 from Alexandre Oliva --- Created attachment 49456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49456&action=edit fix for riscv targets > Still broken Sorry, it's the first I hear of this problem on riscv. The fix is target-specific. Here's one for riscv*.
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #18 from Alexandre Oliva --- The pr97060 test is failing for me, in the gcc-10 branch, at least on target arm-eabi. It passes when optimization is enabled, because then the DIE with the declaration tag, generated in resolve_addr, makes to the output. With optimization disabled, it's created and resolved, but doesn't make it. It looks like this only works at -O0 with the patch for bug 96383, but it hasn't been backported to gcc-10. Only Red Hat's gcc-10 branch has it, as stated in comment 6.
[Bug debug/96383] [8/9/10 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #27 from Alexandre Oliva --- FTR, the patch for bug 97060 was backported to gcc-10, but it depends on this patch to work at -O0.
[Bug rtl-optimization/97714] [8/9/10/11 Regression] ICE in notice_source_line, at final.c:3237 since r8-5241-g8697bf9f46f36168
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97714 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 49751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49751&action=edit patch I'm testing to fix the bug Mine. Thanks. Here's a minimal, most-conservative change to address the reported problem. I wish I could recall what motivated the introduction of that bit to begin with.
[Bug libstdc++/93456] No overflow check in __atomic_futex_unsigned_base::_M_futex_wait_until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93456 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #8 from Alexandre Oliva --- On arm-vxworks, that has 32-bit time_t, this also fails. The initial gthread_cond_timedwait sleeps for a second or two, then it times out and returns. However, the wider C++ types used in the condition_variable::__wait_until_impl check for a timeout and decide we have NOT timed out, so the __Predicate version of __wait_until sees the condition it's waiting for hasn't been met, and attempts to wait again. But since the timeout has already been reached, gthread_cond_wait returns immediately, and we busy-loop. Since vxworks won't preempt threads, and we're not in a SMP configuration, the async call never gets a chance to complete, and the test runs till the rlimit runs out. While investigating this, I noticed that adding __gthread_yield calls in the __wait_until_impl loop, the other thread gets enough cycles to complete, and the test passes, but I thought that would defeat the point of the test, right?
[Bug rtl-optimization/97714] [8/9/10/11 Regression] ICE in notice_source_line, at final.c:3237 since r8-5241-g8697bf9f46f36168
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97714 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexandre Oliva --- Fixed
[Bug tree-optimization/94092] Code size and performance degradations after -ftree-loop-distribute-patterns was enabled at -O[2s]+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092 Alexandre Oliva changed: What|Removed |Added Status|WAITING |ASSIGNED CC||aoliva at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #5 from Alexandre Oliva --- Mine
[Bug tree-optimization/94092] Code size and performance degradations after -ftree-loop-distribute-patterns was enabled at -O[2s]+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092 Alexandre Oliva changed: What|Removed |Added Assignee|aoliva at gcc dot gnu.org |unassigned at gcc dot gnu.org URL|https://gcc.gnu.org/piperma | |il/gcc-patches/2021-Februar | |y/565558.html | --- Comment #13 from Alexandre Oliva --- Since Jim Wilson says https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565558.html does not address the problem in this bug, after all, I'm removing myself as assignee.
[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 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&action=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 #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 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 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 --- 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 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++/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 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 #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 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/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 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 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/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 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 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&action=edit Candidate patch The problem is in undo_optional_reloads. Here's a fix I'm testing.
[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&action=edit Candidate patch Mine. I'm testing this fix.
[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&action=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 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 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 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 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 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 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 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 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] _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 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 --- 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 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 c++/104461] New: cody requires -fmodule-mapper hostname to have an IPv6 address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104461 Bug ID: 104461 Summary: cody requires -fmodule-mapper hostname to have an IPv6 address Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aoliva at gcc dot gnu.org CC: nathan at gcc dot gnu.org Blocks: 103524 Target Milestone: --- A host whose localhost maps to 127.0.0.1 but not ::1 fails bad-mapper-3.C because we get an error about name resolution rather than connection. This might be the reason for part of the errors in bug 99175. That's because mapper-client.cc calls netclient.cc OpenInet6, that insists on strict IPv6 addresses, rejecting even AI_V4MAPPED ones. Any reason to not go AF_UNSPEC instead, and use getaddrinfo's port-to-sockaddr conversion while at that? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug c++/104180] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104180 --- Comment #7 from Alexandre Oliva --- I've recommended before that, without any plan to implement consumers for this debug information, keeping it in place is mostly wasteful. AFAICT other debug stmts issued by front-ends could hit the same issue, but those are only theoretical IIRC. On the one hand, disabling the feature would hide the known problem that codegen is sensitive to such debug stmts, but on the other, we can cross that bridge if we get to it again.
[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
[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&action=edit candidate patch under test Here's a proposed fix
[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 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 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&action=edit candidate patch under test Here's a candidate fix
[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 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 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 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 #7 from Alexandre Oliva --- I mean, even with commit 50e8b0c9bca6cdc57804f860ec5311b641753fbb
[Bug tree-optimization/102988] ICE with -fharden-conditional-branches and C++ and pass by reference return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Alexandre Oliva --- Mine
[Bug debug/103241] Odd 0 length entries in location lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241 --- Comment #14 from Alexandre Oliva --- Hi, Will, Jakub, Martin, There's nothing particularly unusual about apparently empty ranges, especially when views are enabled, since the very point of location views is to enable multiple states to be distinguished at the same PC. It is a little odd that an additional location entry gets emitted for prot at function entry. I suppose inspection of gimple dumps will show some SSA assignment apparently setting some prot version, and that we end up outputting a new entry for it. The difference between the two locations, one without and the other with DW_OP_piece, suggests that some internal state change was perceived between one view and the other; it might be something about (do-nothing) promotions between the argument bindings for the prototype and the body. We might be able to get rid of the restatement of the binding with some more effort.
[Bug tree-optimization/102988] ICE with -fharden-conditional-branches and C++ and pass by reference return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988 --- Comment #5 from Alexandre Oliva --- Created attachment 51837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51837&action=edit candidate patch under test
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 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||2021-11-19 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Alexandre Oliva --- Mine
[Bug middle-end/103149] cc1: error: inconsistent operand constraints in an 'asm' with -fharden-conditional-branches and SVE turned on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103149 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 --- Huh, weird, we skip vector types. Aah, but only in -fharden-compares. Thanks for the report, will fix.
[Bug target/103097] ICE in move_for_stack_reg, at reg-stack.c:1186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103097 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #1 from Alexandre Oliva --- Mine, thanks for the report. I think the underlying cause for this one is the same as for bug 103149 (the "=g" constraint), and hopefully the fix will be the same as well, but I'll keep both open for now.
[Bug middle-end/100843] [12 Regression] ICE with -O1: in try_store_by_multiple_pieces, at builtins.c:6739 since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100843 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. bug 100518 seems related, but not necessarily the same issue.
[Bug target/100518] [12 Regression] ICE in copy_to_mode_reg with aarch64 ILP32 and memset with -mstrict-align -O2 since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100518 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
[Bug tree-optimization/102988] ICE with -fharden-conditional-branches and C++ and pass by reference return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Alexandre Oliva --- Fixed
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 --- Comment #5 from Alexandre Oliva --- Hello, Jim, Thanks for the investigation, that's useful. I guess the register allocator shouldn't choose to coalesce registers when there's a clobber afterwards, or it should drop the clobber, since otherwise it clobbers the coalesced set. Anyway, I'm reworking the asm that prevents optimization because of bug 103149 and bug 103097, it might end up avoiding this unfortunate situation. We'll see...
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 --- Comment #6 from Alexandre Oliva --- https://gcc.gnu.org/pipermail/gcc-patches/2021-December/585963.html appears to no longer hit this error, though I've only inspected the asm output, not tried to run it yet; can anyone confirm?
[Bug rtl-optimization/93027] ICE: in match_reload, at lra-constraints.c:1060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93027
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #6 from Alexandre Oliva ---
FWIW, with or without optimization, this testcase allocates inout f and in &w
to the same register in the .reload dump. If the asm code used %0, expecting
it to be initially 0 as it should, it would fail:
int main (void) {
int f = 0, w, z;
asm volatile(
"movl\t%0, %1"
: "+m&l"(f), "=g" (z)
: "0a"(&w)
);
if (z)
__builtin_abort ();
return 0;
}
[Bug rtl-optimization/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #4 from Alexandre Oliva ---
Andrew,
asm("":"=g"(tt):"g"(t));
asm("":"=g"(ii):"g"(i));
Make it "0" for the inputs:
asm("":"=g"(tt):"0"(t));
and AFAICT if you "detach" the immediate constant, you won't get the bug.
The problem occurs because (leu (compare reg imm)...) is turned into (ltu
(compare reg imm+1)...) for the trap_if, and then the immediate no longer fits
in the compare.
[Bug rtl-optimization/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028 --- Comment #6 from Alexandre Oliva --- This will probably avoid the error. valid_insn_p checks the alternatives, and fails for the invalid cmpdi_ccu that we attempt to create. Conceivably, this could be avoided by narrowing down the condition of the cbranch4 expander to reject unfit constants after reload. Alas, there doesn't seem to be any existing opportunity to adjust the canonicalized condition to fit md constraints, e.g. undoing the LEU to LTU transformation so that we could still get a conditional trap for this case: we don't go through the cbranch4 expander there. diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c index 017944f4f79aa..b0052f6c5ced3 100644 --- a/gcc/ifcvt.c +++ b/gcc/ifcvt.c @@ -4726,7 +4726,9 @@ find_cond_trap (basic_block test_bb, edge then_edge, edge else_edge) /* If that results in an invalid insn, back out. */ for (rtx_insn *x = seq; x; x = NEXT_INSN (x)) -if (recog_memoized (x) < 0) +if (reload_completed + ? !valid_insn_p (x) + : recog_memoized (x) < 0) return FALSE; /* Emit the new insns before cond_earliest. */
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 --- Comment #9 from Alexandre Oliva --- Thanks, this alternate testcase confirms my suspicion that the original issue was only going latent. It's clearly a preexisting register allocation issue on riscv, that was latent and that -fharden-compares exposed rather than introduced. If I understand correctly its pervasiveness, it may very well make -fharden-compares too risky to use on riscv, so I may be on the hook to fix it regardless. ISTM that a post-reload insn_and_split would at least avoid the problem. Is there any reason why this approach is not in use on riscv?
[Bug tree-optimization/103024] ICE in execute, at gimple-harden-conditionals.cc:424 with -fnon-call-exceptions -fharden-compares -fsignaling-nans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103024 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
[Bug middle-end/103530] ICE: in execute, at gimple-harden-conditionals.cc:397 with -O -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103530 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
[Bug target/103450] [12 Regression] ICE: SIGSEGV in memory_operand (recog.c:1818) with -Og -fharden-compares -fschedule-insns2 -fno-tree-dce -fno-tree-fre since r12-5536-g90cb088ece8d8cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103450 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 #2 from Alexandre Oliva --- Mine, I suppose
[Bug target/103450] [12 Regression] ICE: SIGSEGV in memory_operand (recog.c:1818) with -Og -fharden-compares -fschedule-insns2 -fno-tree-dce -fno-tree-fre since r12-5536-g90cb088ece8d8cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103450 Alexandre Oliva changed: What|Removed |Added Assignee|aoliva at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #3 from Alexandre Oliva --- Hmm, nope, I supposed incorrectly ;-)
[Bug rtl-optimization/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028 --- Comment #8 from Alexandre Oliva --- Fixed
[Bug rtl-optimization/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028 Alexandre Oliva changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Alexandre Oliva --- Fixed
[Bug middle-end/103149] cc1: error: inconsistent operand constraints in an 'asm' with -fharden-conditional-branches and SVE turned on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103149 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexandre Oliva --- Fixed
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 --- Comment #10 from Alexandre Oliva --- Created attachment 51947 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51947&action=edit candidate patch under testing Could the fix be as simple as this? The resulting code is awful, with such stuff as loading and storing back each word of multi-word pseudos that end up assigned to memory, but at least we don't clobber the asm outputs with these clobbers, which is what makes them look dead. Anyhow, comments at the top of emit_move_multi_word state: Note that you will get better code if you define such patterns, even if they must turn into multiple assembler instructions.
[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|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Alexandre Oliva --- Fixed
[Bug target/103097] ICE in move_for_stack_reg, at reg-stack.c:1186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103097 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Alexandre Oliva --- Fixed
[Bug middle-end/103530] ICE: in execute, at gimple-harden-conditionals.cc:397 with -O -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103530 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Alexandre Oliva --- Fixed
[Bug tree-optimization/103024] ICE in execute, at gimple-harden-conditionals.cc:424 with -fnon-call-exceptions -fharden-compares -fsignaling-nans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103024 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexandre Oliva --- Fixed
[Bug middle-end/100843] [12 Regression] ICE with -O1: in try_store_by_multiple_pieces, at builtins.c:6739 since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100843 --- Comment #4 from Alexandre Oliva --- Created attachment 51954 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51954&action=edit candidate patch under testing
[Bug target/100518] [12 Regression] ICE in copy_to_mode_reg with aarch64 ILP32 and memset with -mstrict-align -O2 since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100518 --- Comment #4 from Alexandre Oliva --- Created attachment 51955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51955&action=edit candidate patch under testing
[Bug middle-end/100843] [12 Regression] ICE with -O1: in try_store_by_multiple_pieces, at builtins.c:6739 since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100843 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Alexandre Oliva --- Fixed
[Bug target/100518] [12 Regression] ICE in copy_to_mode_reg with aarch64 ILP32 and memset with -mstrict-align -O2 since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100518 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alexandre Oliva --- Fixed
[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++/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&action=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 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 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 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&action=edit Candidate patch Mine. This patch appears to cure it. Regstrapping...
[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.
