[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #13 from Segher Boessenkool --- (In reply to Bill Schmidt from comment #11) > As I mentioned privately, we could do with an audit of our implementation of > standard patterns in general, since we tend to find such missing cases more

[Bug target/93453] PPC: rldimi not taken into account to avoid shift+or

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453 --- Comment #5 from Segher Boessenkool --- (In reply to HaoChen Gui from comment #4) > (define_insn_and_split "*rotl3_insert_8" > [(set (match_operand:GPR 0 "gpc_reg_operand" "=r") > (plus_ior_xor:GPR (ashift:GPR (match_operand:GPR 1 "g

[Bug target/93453] PPC: rldimi not taken into account to avoid shift+or

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453 --- Comment #7 from Segher Boessenkool --- (In reply to HaoChen Gui from comment #6) > Yes, I found that the nonzero_bits doesn't return exact value in other > pass. It returns a different value. Neither is "exact". The version used by combi

[Bug target/102239] powerpc suboptimal boolean test of contiguous bits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239 --- Comment #3 from Segher Boessenkool --- (In reply to luoxhu from comment #2) > (In reply to Segher Boessenkool from comment #1) > > Confirmed. > > > > So the relevant insn > > > > (parallel [(set (reg:CC 123) > > (compare:CC

[Bug target/93453] PPC: rldimi not taken into account to avoid shift+or

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453 --- Comment #9 from Segher Boessenkool --- Yeah that looks better already, thanks. Please get rid of the debug stuff still in here, and send to gcc-patches@?

[Bug target/102239] powerpc suboptimal boolean test of contiguous bits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239 --- Comment #5 from Segher Boessenkool --- (In reply to luoxhu from comment #4) > Simply adjust the sequence of dot instruction could produce expected code, > is this correct? No it isn't. Sorry. > foo: > .LFB0: > .cfi_startproc >

[Bug target/102239] powerpc suboptimal boolean test of contiguous bits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239 --- Comment #8 from Segher Boessenkool --- (In reply to luoxhu from comment #6) > > > foo: > > > .LFB0: > > > .cfi_startproc > > > rldicr. 3,3,29,1 > > > beq 0,.L2 > > > > This is fine, but only because it tests the EQ b

[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org

[Bug target/54063] [9/10/11/12 regression] on powerpc64 gcc 4.9/8 generates larger code for global variable accesses than gcc 4.7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063 --- Comment #23 from Segher Boessenkool --- Trunk does lookup: .quad .L.lookup,.TOC.@tocbase,0 .previous .type lookup, @function .L.lookup: .LFB0: .cfi_startproc addis 9,2,.LANCHOR0@toc@ha ld 9

[Bug target/102239] powerpc suboptimal boolean test of contiguous bits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239 --- Comment #10 from Segher Boessenkool --- (In reply to luoxhu from comment #9) > > It does matter, if what you are want to see is if it is smaller than zero or > > greater than zero. CCmode includes those things. There is a CCEQmode for > >

[Bug target/103568] sub-optimal vector construction with two loaded doubles on Power10

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103568 --- Comment #1 from Segher Boessenkool --- Confirmed. This is cheaper in GPRs until we had the lxvrdx insn, which is power10 (ISA 3.1) itself. Wrt dword 1 being zeroed by fp insns. ISA 3.1 has a note saying this was true on all earlier implem

[Bug target/103568] sub-optimal vector construction with two loaded doubles on Power10

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103568 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug rtl-optimization/101995] [9/10/11/12 Regression] regression built-in memset missed-optimization arm -Os since r9-3594

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995 --- Comment #7 from Segher Boessenkool --- I don't see any problem with aarch64 fwiw. If RA decides it does not want to tie the new pseudo to the argument register, it may have a reason for it? Or suboptimal heuristics. What is this REG_RETUR

[Bug rtl-optimization/101995] [9/10/11/12 Regression] regression built-in memset missed-optimization arm -Os since r9-3594

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995 --- Comment #8 from Segher Boessenkool --- Also, what is fragile here? This is *removing* fragility and premature choices!

[Bug rtl-optimization/101995] [9/10/11/12 Regression] regression built-in memset missed-optimization arm -Os since r9-3594

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995 --- Comment #9 from Segher Boessenkool --- (In reply to Segher Boessenkool from comment #7) > What is this REG_RETURNED thing? Ah, something added in ira-lives.c, and you call *that* code fragile? I agree :-)

[Bug target/100736] ICE: unrecognizable insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736 --- Comment #3 from Segher Boessenkool --- Send patches to gcc-patches@, please. Or is there a question? Ask that question then, please :-)

[Bug rtl-optimization/101995] [9/10/11/12 Regression] regression built-in memset missed-optimization arm -Os since r9-3594

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995 --- Comment #11 from Segher Boessenkool --- Yeah, that could be much more robust. OTOH this stuff is completely opportunistic in the first place: it handles only function return values, not any other hard registers (like local register vars).

[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624 --- Comment #5 from Segher Boessenkool --- It should work for 32-bit though?

[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624 --- Comment #8 from Segher Boessenkool --- (In reply to Bill Schmidt from comment #6) > We have __builtin_darn_32 for the 32-bit case. The changes for the two > 64-bit-only interfaces reflect the previous behavior. No, that has nothing to do w

[Bug d/103739] New: Bootstrap broken on powerpc64-linux

Assignee: ibuclaw at gdcproject dot org Reporter: segher at gcc dot gnu.org Target Milestone: --- gdc -fno-PIE -c -g -O2 -fversion=IN_GCC -Wall -Wdeprecated -fno-common -o d/access.o -MT d/access.o -MMD -MP -MF d/.deps/access.TPo -I/home/segher/src/gcc/gcc/d -J/home/segher/src

[Bug d/103739] Bootstrap broken on powerpc64-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103739 --- Comment #2 from Segher Boessenkool --- Hi! I have no idea why not. $ gdc --version gdc (GCC) 9.3.1 20200410 and it says Configured with: /home/segher/src/gcc/configure --prefix=/home/segher/tot --enable-languages=c,c++,fortran,ada,d,objc

[Bug d/103739] Bootstrap broken on powerpc64-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103739 --- Comment #4 from Segher Boessenkool --- Thanks. But the point of this PR is that bootstrapping trunk is broken. That needs fixing some way.

[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624 Segher Boessenkool changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug rtl-optimization/68150] postreload-gcse ignores partially clobbered registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68150 Segher Boessenkool changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281 --- Comment #12 from Segher Boessenkool --- This is my g:72b2f3317b44, two years and a day old :-)

[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281 --- Comment #13 from Segher Boessenkool --- If we need more than three insns to create a constant we are better off loading it from memory, in all cases. Maybe three is too much already, at least on some processors?

[Bug target/102127] [12 Regression] ICE when compiling (m32) powerpc/440-mulchw-1.c since g:ff6bb9dde10ab665a35bb75527313cd9f7d52f8e

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127 --- Comment #4 from Segher Boessenkool --- Program received signal SIGSEGV, Segmentation fault. 0x10f9b10c in ._Z19build_function_typeP9tree_nodeS0_ () (gdb) bt #0 0x10f9b10c in ._Z19build_function_typeP9tree_nodeS0_ () #1 0x00

[Bug rtl-optimization/102062] powerpc suboptimal unrolling simple array sum

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062 --- Comment #15 from Segher Boessenkool --- This should be fixed now, please confirm. Thanks!

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #9 from Segher Boessenkool --- So that is something older from the GCC 11 branch, aha.

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #10 from Segher Boessenkool --- (In reply to Segher Boessenkool from comment #9) > So that is something older from the GCC 11 branch, aha. And I cannot reproduce it with anything that has been on the GCC 11 branch, either.

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #15 from Segher Boessenkool --- (In reply to HaoChen Gui from comment #9) > For this example, let's suppose that we set mcpu=power8 and mno-vsx in the > command line. Thus, _ARCH_PWR8 should be defined as mcpu=power8. But if the > Po

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #16 from Segher Boessenkool --- (In reply to wschmidt from comment #14) > I disagree with that.  You should use __VSX__ && _ARCH_PWR9 to check for > P9 vector support, etc.  The __POWERn_VECTOR__ things really are not > great and I

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #13 from Segher Boessenkool --- /* If we need to save CR, put it into r12 or r11. Choose r12 except when r12 will be needed by out-of-line gpr save. */ cr_save_regno = ((DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2)

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 Segher Boessenkool changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 --- Comment #14 from Segher Boessenkool --- (In reply to Jonathan Wakely from comment #13) > Is this also the cause of several libstdc++ FAILs on ppc64le? Yes. I have asked for reversion of g:d2874d905647:

[Bug target/97142] __builtin_fmod not optimized on POWER

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 --- Comment #14 from Segher Boessenkool --- (In reply to Peter Bergner from comment #13) > (In reply to luoxhu from comment #12) > > Patch submitted: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568143.html > > Looks like Will r

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 --- Comment #25 from Segher Boessenkool --- (In reply to Peter Bergner from comment #24) > (In reply to Segher Boessenkool from comment #23) > > Anyway, patch in testing. > > Did your patch fix the problem or do we need to take another run at th

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #16 from Segher Boessenkool --- (Hopefully) fixed on trunk, but it needs backports.

[Bug target/102231] New: includes unconditionally

Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- Instead, it should do something like #if __STDC_HOSTED__ #include #endif as Clang does, because only exists on hosted environments (which is good, because it itself uses , etc.) A

[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 --- Comment #4 from Segher Boessenkool --- Since you closed PR102231 (which has a lot more detail), let me paste that here: includes unconditionally Instead, it should do something like #if __STDC_HOSTED__ #include #endif as Clang doe

[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 --- Comment #7 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #6) > And the "somehow" is now possible too, we can use __has_include(). Including it with -ffreestanding in effect is always wrong. Even if the header exists it

[Bug target/97142] __builtin_fmod not optimized on POWER

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 --- Comment #18 from Segher Boessenkool --- +/* { dg-final { scan-assembler-not {(?n)\mb.*fmod} } } */ +/* { dg-final { scan-assembler-not {(?n)\mb.*fmodf} } } */ +/* { dg-final { scan-assembler-not {(?n)\mb.*remainder} } } */ +/* { dg-final { sc

[Bug target/97142] __builtin_fmod not optimized on POWER

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 --- Comment #19 from Segher Boessenkool --- (In reply to Peter Bergner from comment #17) > The Version about is to 10.2, does that mean we're going to back port this > to the release branches, or are we calling it good with trunk? This is a pret

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 --- Comment #17 from Segher Boessenkool --- (In reply to Hongtao.liu from comment #15) > as discussed in > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578437.html, allow > specific float-int subreg seems weird. Indiscriminately allowi

[Bug target/102239] powerpc suboptimal boolean test of contiguous bits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2021-09-09 Ever confirmed|0

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 --- Comment #20 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #18) > So I wonder if it makes sense to allow lowpart subregs of any mode when > the inner mode is integer. We really really really should make a separate b

[Bug target/102211] [12 regression] ICE introduced by r12-3277

, ||segher at gcc dot gnu.org --- Comment #6 from Segher Boessenkool --- (In reply to Jim Wilson from comment #4) > Yes, moving SI/DI values to FP regs is OK. However, RISC-V requires that FP > values in FP registers be stored NaN-boxed. So an SFmode

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 --- Comment #23 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #21) > > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error: > > unrecognizable insn: > > 704 | func parseFloatPrefix(s string, bitSize in

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 --- Comment #26 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #24) > > The expander should never create such code in the first place, it is > > premature > > optimisation! At expand time this should be separate statem

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 --- Comment #27 from Segher Boessenkool --- (In reply to Hongtao.liu from comment #22) > > Btw, I think this is a subreg that would be reasonable to handle. > > It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI > > ..) 0).

[Bug c/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185 --- Comment #12 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #11) > as mentioned in another bug, this is more of a documentation issue and the > internal details on how inline-asm works. Yup. I suggest we advice to always

[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org

[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306 --- Comment #8 from Segher Boessenkool --- The patch in c#5 looks good. Since you test added_sets_0 and added_sets_1 as well, does this mean it could happen before this patch as well? We already did have some things that did combine 2->2 (via

[Bug target/102107] protocol register (r12) corrupted before a tail call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #22 from Segher Boessenkool --- Backported to 11 and 10. Not doing GCC 9; the problem is older than that, and the backport wouldn't be completely trivial. Paul, please close if everything is okay now?

[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140 --- Comment #4 from Segher Boessenkool --- Confirmed. Doesn't need -mlittle or -mabi=elfv2, or -mcpu=power8 even, but does need -mvsx.

[Bug c/94428] Reintroduce -Wzero-length-array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428 --- Comment #3 from Segher Boessenkool --- (In reply to Martin Sebor from comment #1) > With the introduction of -Wzero-length-bounds in GCC 10 (which, > incidentally, was added specifically to ease the adoption of the stricter > array bounds che

[Bug target/102169] powerpc64 int memory operations using FP instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org

[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730 --- Comment #7 from Segher Boessenkool --- (In reply to Richard Biener from comment #5) > Not sure whether targets should have a special-case pattern here or whether > that's for combine to un-canonicalize it? Is the shift defined anywhere as th

[Bug target/102485] -Wa,-many no longer has any effect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485 --- Comment #3 from Segher Boessenkool --- (In reply to Paul Clarke from comment #2) > GCC putting the base ".machine" directive at the beginning of the file makes > any command-line use of "-many" (-Wa,-many) be ignored. Is that OK? If peopl

[Bug target/102485] -Wa,-many no longer has any effect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485 --- Comment #5 from Segher Boessenkool --- (In reply to Peter Bergner from comment #4) > (In reply to Segher Boessenkool from comment #3) > > (In reply to Paul Clarke from comment #2) > > > "-many" is supposed to make those black boxes just work

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104 --- Comment #12 from Segher Boessenkool --- (In reply to Patrick McGehearty from comment #8) > My challenge is that the very old glibc on gcc135.fsffrance.org > does not know about _TF_ vs _KF_ and _IF_. It refused to > build the new libgcc/conf

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104 --- Comment #14 from Segher Boessenkool --- (In reply to Patrick McGehearty from comment #13) > I may be mistaken about the source of the issue being glibc. > Perhaps it is a system include file issue? Here are some > more details. > > Here are

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2021-10-15 Ever confirmed|0

[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 --- Comment #6 from Segher Boessenkool --- (In reply to Richard Earnshaw from comment #5) > We have the type > type size > unit-size > and movmisalign pattern is enabled for this. > > but the vectorization cost doesn't

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783 --- Comment #7 from Segher Boessenkool --- (In reply to Richard Biener from comment #5) > Even out-of-line does not help if there are visible CSE/association > opportunities across such call. Yeah, good point. > A workaround is to make the out

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783 --- Comment #8 from Segher Boessenkool --- (In reply to jos...@codesourcery.com from comment #6) > Generically (and if the command-line options are such that floating-point > control / status bits are to be respected by optimizations), *any* >

[Bug libffi/102923] [12 Regression] powerpc64 (BE) linux all languages bootstrap broken after libffi 3.4.2 import.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923 --- Comment #4 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #1) > The stvx stuff is guarded by #ifdef __VEC__, so perhaps the lvx stuff should > be too, or there should be .machine push; .machine power7; ... .machine pop;

[Bug other/102440] Uinteger Opt/Param but the underlying type is signed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440 --- Comment #6 from Segher Boessenkool --- (In reply to Martin Liška from comment #5) > All right, so the meaning of the UInteger type is actually that users can't > set the flag/param to a negative value: > > $ gcc -fabi-version=-3 a.c > gcc:

[Bug other/102440] Uinteger Opt/Param but the underlying type is signed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440 --- Comment #7 from Segher Boessenkool --- The documentation for UInteger also says Positive values of the argument in excess of @code{INT_MAX} wrap around zero. so C "unsigned" types are natural for it.

[Bug libffi/102923] [12 Regression] powerpc64 (BE) linux all languages bootstrap broken after libffi 3.4.2 import.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923 --- Comment #8 from Segher Boessenkool --- Created attachment 51664 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51664&action=edit proposed patch This is the patcgh I am currently testing.

[Bug other/102440] Uinteger Opt/Param but the underlying type is signed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440 --- Comment #9 from Segher Boessenkool --- (In reply to Martin Liška from comment #8) > > We could make the "UInteger" type mean it is implemented with an "unsigned > > int" > > C type (or some other unsigned integer type). > > This would lead

[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 --- Comment #15 from Segher Boessenkool --- (In reply to Peter Bergner from comment #14) > (In reply to Martin Liška from comment #13) > > Created attachment 51668 [details] > > Patch candidate > > > > Please test the patch on a power10 machine

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353 --- Comment #5 from Segher Boessenkool --- Please revert until it is fixed? It breaks way too many targets.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #16 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #15) > PowerPC I think does, not sure about s390. Does what?

[Bug c/102989] Implement C2x's n2763 (_BitInt)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #20 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #18) > (In reply to Segher Boessenkool from comment #16) > > (In reply to Jakub Jelinek from comment #15) > > > PowerPC I think does, not sure about s390. > > >

[Bug c/102989] Implement C2x's n2763 (_BitInt)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #21 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #19) > (In reply to Segher Boessenkool from comment #16) > > (In reply to Jakub Jelinek from comment #15) > > > PowerPC I think does, not sure about s390. > > >

[Bug target/93177] PPC: Missing many useful platform intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177 --- Comment #18 from Segher Boessenkool --- (In reply to Sergey Fedorov from comment #16) > For Darwin, PPC intrinsics already is there in Apple headers. Can it be > added into current GCC? If it is in the Apple headers already, why would you ne

[Bug rtl-optimization/105586] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105586 --- Comment #8 from Segher Boessenkool --- Please do that together with the follow-up fix only? PR107171.

[Bug rtl-optimization/105586] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105586 --- Comment #9 from Segher Boessenkool --- I read as approval to backport, fwiw :-)

[Bug tree-optimization/107412] Miss to fold LEN_{LOAD,STORE} when the specified length equal to vector length

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107412 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org

[Bug rtl-optimization/105586] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105586 --- Comment #11 from Segher Boessenkool --- Ah. It's a nasty bug, so "safe side" is to *do* fix it, in my reading. But you can also say "not doing anything" (so, staying susceptible to the bug) is safer. It happens rather infrequently after al

[Bug target/107606] rs6000: Option not to use parameter save area in variadic function implementations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107606 --- Comment #1 from Segher Boessenkool --- Hi Florian, What do you want such an option to do? The PSA is used only when it is needed, do you want to have the compiler error out in such cases? This is very unpredictable to the user, so it shou

[Bug target/107606] rs6000: Option not to use parameter save area in variadic function implementations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107606 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug target/107692] [13 regression] r13-3950-g071e428c24ee8c breaks many test cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692 --- Comment #3 from Segher Boessenkool --- Hi! (In reply to Hongyu Wang from comment #2) > I've tested the patch with cross-compler and all the fails disappeared, but > I don't have a powerpc to do full bootstrap & regtest (I'm still applying >

[Bug target/107692] [13 regression] r13-3950-g071e428c24ee8c breaks many test cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692 --- Comment #8 from Segher Boessenkool --- (In reply to Jiu Fu Guo from comment #5) > > -munroll-only-small-loops does not turn on or off -funroll-loops, and it > > should not, so that it does what it says, if nothing else. > > Yes, and -funrol

[Bug target/107692] [13 regression] r13-3950-g071e428c24ee8c breaks many test cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug target/107692] [13 regression] r13-3950-g071e428c24ee8c breaks many test cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692 --- Comment #10 from Segher Boessenkool --- (In reply to Hongyu Wang from comment #9) > The difference is, -mno-unroll-only-small-loops -O2 would cause > rtl-loop-unroll takeing effect, No. -m{no-,}unroll-only-small-loops does not enable or di

[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 #13 from Segher Boessenkool --- DEBUG_INSNs should never influence any scheduling decisions, or any other decisions that influence what machine code we generate.

[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 #15 from Segher Boessenkool --- Yup. I don't consider DEBUG_INSNs to be scheduled at all, only real things are, but that is just vague terminology :-)

[Bug c++/108103] New: c++tools remains after make distclean

++ Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- $ ll c++tools/ total 3688 -rw-rw-r-- 1 segher segher4840 Nov 25 19:46 Makefile -rw-rw-r-- 1 segher segher4998 Oct 21 03:51 config.cache

[Bug bootstrap/101834] make distclean forgets ./c++tools/

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #3 from Segher Boessenkool --- I never build in the source tree. I use distclean a lot.

[Bug modula2/108143] LONGREAL and powerpc64le-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108143 --- Comment #4 from Segher Boessenkool --- (In reply to Richard Biener from comment #1) > Since the frontend is "new" we might want to say m2 only supports IEEE long > double on powerpc? No, the vast majority of powerpc*-* targets only supports

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147 --- Comment #3 from Segher Boessenkool --- >0x10ffc2e0 <+0>: lis r2,4563 >0x10ffc2e4 <+4>: addir2,r2,29696 >0x10ffc2e8 <+8>: mflrr0 >0x10ffc2ec <+12>: std r30,-16(r1) >0x

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147 Segher Boessenkool changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147 --- Comment #9 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #8) > Short test that shows that on powerpc64le-linux: > void foo (int, ...); > void bar (int); > int baz (void) { foo (1); return 0; } > int qux (void) { bar (1)

[Bug target/108149] New: rs6000: e500mc64 was never released

Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- We should find a way to steer users away from using it (we cannot just remove it, there are users who do use it!) See <https://lore.kernel.org/all/20221216222359.74i6otxszwanf

[Bug target/108149] rs6000: e500mc64 was never released

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108149 Segher Boessenkool changed: What|Removed |Added Target||powerpc* Severity|normal

<    24   25   26   27   28   29   30   31   32   33   >