[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #5 from Segher Boessenkool --- Correct, this certainly can not be done by combine, it see two independent pseudos here. For hard registers it *can* do many tricks, but not for pseudos like this.

[Bug bootstrap/109460] Build gcc for win32 failed in gcc13 master branch

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

[Bug bootstrap/109460] Build gcc for win32 failed in gcc13 master branch

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

[Bug libffi/109447] test case libffi.closures/cls_align_longdouble_split.c fails

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

[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW Priority|P3

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #9 from Segher Boessenkool --- (In reply to Segher Boessenkool from comment #8) > (In reply to Jonathan Wakely from comment #6) > > Also, after 'make clean' you can no longer do 'make all' > > Of course you cannot. Where do you

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #8 from Segher Boessenkool --- (In reply to Jonathan Wakely from comment #6) > Also, after 'make clean' you can no longer do 'make all' Of course you cannot. Where do you see this?

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #7 from Segher Boessenkool --- Thank you for looking at this! (In reply to Jonathan Wakely from comment #5) > c++tools/Makefile.in has: > > mostlyclean:: > rm -f $(MAPPER.O) > > clean:: > rm -f

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2023-03-30 Ever confirmed|0

[Bug target/109329] rs6000: New testcases {mul,div}ic3* should run on systems without QP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329 Segher Boessenkool changed: What|Removed |Added Priority|P3 |P4 Target|

[Bug target/109329] New: rs6000: New testcases {mul,div}ic3* should run on systems without QP

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- The testcases use ICmode, which exists fine on almost all systems. But we get the error cc1: error: '-mabi=ieeelongdouble

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628 --- Comment #7 from Segher Boessenkool --- (In reply to HaoChen Gui from comment #5) > The memory representation of IBM long double is not unique. It's actually > the sum of two 64-bit doubles. Yes, and the first of those two DP numbers is

[Bug target/109067] Powerpc GCC does not support __ibm128 complex multiply/divide if long double is IEEE 128-bit.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109067 --- Comment #1 from Segher Boessenkool --- Do you have a testcase please?

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007 --- Comment #17 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #16) > Or just make sure the libraries are still built with -mcpu=power8 even when > the compiler defaults to something else. That doesn't scale. > That said,

[Bug target/103784] suboptimal code for returning bool value on target ppc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784 --- Comment #12 from Segher Boessenkool --- What David says :-) We really could use something good for this, it has been a problem for all GCC targets since forever; it hurts rs6000 more than most though. Before RA this is a diamond, one side

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007 --- Comment #15 from Segher Boessenkool --- (In reply to bugreporter66 from comment #14) > I should be able to workaround that by emulating all LE targets on POWER9, > with a comment that building for POWER8 natively on target should work too.

[Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594 --- Comment #16 from Segher Boessenkool --- (In reply to Roger Sayle from comment #14) > This really is a regression, that points to a previously latent/unnoticed > bug in combine. > > In GCC 12, combine would take the input RTL and based on

[Bug rtl-optimization/109009] Shrink Wrap missed opportunity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009 --- Comment #4 from Segher Boessenkool --- Alternatively (or in addition), you can look how to make the shrink-wrap pass transform the code with some simple added move instructions, maybe even involving an extra pseudo, so that it can

[Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594 --- Comment #13 from Segher Boessenkool --- Hi! Either this should not be P1, or the proposed patch is taking completely the wrong direction. P1 means there is a regression. There is no regression in combine, in fact the proposed patch would

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007 --- Comment #13 from Segher Boessenkool --- (In reply to bugreporter66 from comment #10) > Yes, it seems so. They've switched to POWER9 by default in Ubuntu 22.04, so > it means that gcc itself (along with standard libraries) was compiled for >

[Bug target/108315] -mcpu=power10 changes ABI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #17 from Segher Boessenkool --- What makes you think we need to tell the user to do something? There is nothing that needs to be done as far as I can see? /confused

[Bug target/108315] -mcpu=power10 changes ABI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #15 from Segher Boessenkool --- (In reply to Alexander Monakov from comment #14) > Are you guys really sure you want to blame the user here, I apologise if this hasn't been a nice experience for you. I'm not blaming anyone, least

[Bug target/108315] -mcpu=power10 changes ABI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #13 from Segher Boessenkool --- (In reply to Alexander Monakov from comment #10) > (In reply to Rui Ueyama from comment #9) > > I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI > > because I didn't have an

[Bug rtl-optimization/109009] Shrink Wrap missed opportunity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009 --- Comment #1 from Segher Boessenkool --- This is very target-specific. Could you please attach a test case (with any significant compiler flags as well, and specific target mentioned, etc.) that shows the problem?

[Bug target/106770] powerpc64le: Unnecessary xxpermdi before mfvsrd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770 --- Comment #11 from Segher Boessenkool --- (In reply to Jens Seifert from comment #6) > The left part of VSX registers overlaps with floating point registers, that > is why no register xxpermdi is required and mfvsrd can access all (left) >

[Bug target/106770] PPCLE: Unnecessary xxpermdi before mfvsrd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Target|powerpc

[Bug target/108315] -mcpu=power10 changes ABI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #8 from Segher Boessenkool --- To expand a bit: st_other with value 1 was reserved before, and now it isn't anymore. Any tool that silently ignores the "special case" of reserved values will not work correctly (it might sometimes

[Bug target/108315] -mcpu=power10 changes ABI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 Segher Boessenkool changed: What|Removed |Added Resolution|--- |INVALID

[Bug target/106770] PPCLE: Unnecessary xxpermdi before mfvsrd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770 --- Comment #5 from Segher Boessenkool --- (In reply to Jens Seifert from comment #4) > PPCLE with no special option means -mcpu=power8 -maltivec (altivecle to be > mor precise). What? No. $ sh config.sub ppcle powerpcle-unknown-none

[Bug target/106770] PPCLE: Unnecessary xxpermdi before mfvsrd

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

[Bug target/108862] [13 Regression] CryptX miscompilation on power9 since r13-2107

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108862 --- Comment #3 from Segher Boessenkool --- With -fno-unroll-loops added we get foo: .LFB0: .cfi_startproc cmpwi 0,3,0 ble 0,.L4 mtctr 3 addi 10,4,-8 addi 5,5,8 li 3,0 .p2align

[Bug rtl-optimization/107949] PPC: Unnecessary rlwinm after lbzx

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949 --- Comment #6 from Segher Boessenkool --- We generate loads into QImode regs, so we need to explicitly convert it to whatever larger mode is wanted later. We also have define_insns to do a zero-extended load directly into a bigger pseudo, but

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #33 from Segher Boessenkool --- Yes, exactly. It was the X server I think? I try to forget such horrors :-)

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #31 from Segher Boessenkool --- Yes, there was a user who incorrectly used memcpy on non-memory memory. This is not valid, and never has been.

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #29 from Segher Boessenkool --- (In reply to Florian Weimer from comment #28) > Maybe this belongs in the ABI manual? For example, the POWER ABI says that > memcpy needs to work on device memory. Huh?! Where do you see this? The

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108787 --- Comment #9 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #7) > Created attachment 54460 [details] > gcc13-pr108787.patch That patch is preapproved, but please add a comment (before umaddditi4) saying we do not want

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108787 --- Comment #8 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #6) > we used to emit in GCC 12 4/4/4/5 instructions: > mulld 9,3,4 > mulhdu 4,3,4 > addc 3,9,5 > adde 4,4,6 > and >

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108787 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2023-02-14 Ever confirmed|0

[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108699 --- Comment #2 from Segher Boessenkool --- Right, it needs a vpopcntb or similar first.

[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #8 from Segher Boessenkool --- No, addition and subtraction are well defined for all inputs, for unsigned integers.

[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #6 from Segher Boessenkool --- No? Take a=59 as counterexample: (a - (N*M)) / N + M = (59 - 2*30)/30 + 2 = ~0UL/30 + 2 but a / N = 59/30 = 1 Integer division in C is division towards zero, almost no normal algebraic

[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N

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

[Bug middle-end/17308] nonnull attribute not as useful as it could be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308 --- Comment #24 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #23) > I also suspect many of these new warnings we are doing in recent years > really should not be part of -Wall because of how many false positives we > have.

[Bug middle-end/108623] We need to grow the precision field in tree_type_common for PowerPC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623 --- Comment #5 from Segher Boessenkool --- The failure was not detected, only things down the road broke up, can we add something for that? Just a strategically placed assert should do fine. Less important if we grow the field all the way to

[Bug middle-end/84514] powerpc sub optimal condition register reuse with extended inline asm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84514 --- Comment #2 from Segher Boessenkool --- Still happens with current trunk.

[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 #24 from Segher Boessenkool --- So this PR can be marked resolved now?

[Bug target/108491] cross compiler does not work: cc1: error: ‘-msecure-plt’ not supported by your assembler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491 Segher Boessenkool changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #7 from

[Bug analyzer/108432] Analyzer fails to detect out-of-bounds issues within loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432 --- Comment #3 from Segher Boessenkool --- (In reply to David Malcolm from comment #2) > Unfortunately, some analyzer warnings work better with optimization > *disabled*. -fanalyzer runs much later than most other static analyzers.

[Bug target/108491] cross compiler does not work: cc1: error: ‘-msecure-plt’ not supported by your assembler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491 --- Comment #1 from Segher Boessenkool --- This error is from sysv4.h SUBTARGET_OVERRIDE_OPTIONS. -msecure-plt is unconditionally required. It looks like an oversight that it is not required in the assembler you used (which is that?)

[Bug analyzer/108432] Analyzer fails to detect out-of-bounds issues within loops

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

[Bug c/108483] gcc warns about suspicious constructs for unevaluted ?: operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483 --- Comment #4 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #1) > I doubt this will be changed anytime soon, see PR 4210 for the history on > why. That PR is about an UB case though. In this case the code is perfectly

[Bug c/108483] gcc warns about suspicious constructs for unevaluted ?: operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483 --- Comment #2 from Segher Boessenkool --- The testcase needs a NULL defined as (void *)0 .

[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 #21 from Segher Boessenkool --- As far as we (me, you; everybody) can tell it is fixed now. If one day we get a testcase showing it has in fact not been fixed, the problem is still there, we can reopen or link the testcases or

[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #12 from Segher Boessenkool --- We really really REALLY should neuter -mmodulo. It is counter-productive to have command-line flags for separate instructions at all (as opposed to facilities), and it is downright destructive to

[Bug target/108396] [12/13 Regression] PPCLE: vec_vsubcuq missing since r12-5752-gd08236359eb229

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396 --- Comment #5 from Segher Boessenkool --- (In reply to Segher Boessenkool from comment #3) > Is it hard to add one for all (or many) of the legacy builtins? Do we want > to test more than just if it compiles? Btw, "legacy"... I thought

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415 --- Comment #1 from Segher Boessenkool --- Soft float does not conflict with anything (anything that does not need FP registers that is). But yes, we really should neuter -mmodulo.

[Bug target/108396] [12/13 Regression] PPCLE: vec_vsubcuq missing since r12-5752-gd08236359eb229

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396 --- Comment #3 from Segher Boessenkool --- (In reply to Kewen Lin from comment #2) > Yes, it's a typo, which makes the macro definition change to: > > #define vec_vsubcuqP __builtin_vec_vsubcuq Yup. > Unfortunately we don't have the testing

[Bug ipa/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb

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

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #7 from Segher Boessenkool --- -m64 requires 64-bit instructions. We will ICE if we try to generate code for -m64 without support for 64-bit insns enabled in the compiler. For example, the stdu insn is required to implement the

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #4 from Segher Boessenkool --- (In reply to Kewen Lin from comment #3) > With the culprit commit r13-4894, we always implicitly enable powerpc64 for > both explicit and implicit 64 bit, it's the same as before for the explicit > 64

[Bug middle-end/108298] Wrong optimization of volatile access from gcc 11 and beyond

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298 --- Comment #9 from Segher Boessenkool --- It cannot be a duplicate: this bug was introduced much later than when PR69482 was filed! But glad the same patch seems to have fixed both, sure :-)

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

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

[Bug rtl-optimization/107949] PPC: Unnecessary rlwinm after lbzx

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

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

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

[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298 --- Comment #5 from Segher Boessenkool --- This is not x86-specific. Like on powerpc64 we get addi 3,3,3 # 11 [c=4 l=4] *addsi3/1 extsw 3,3# 17 [c=4 l=4] extendsidi2/1 blr # 25 [c=4

[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2023-01-05 Ever confirmed|0

[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298 --- Comment #4 from Segher Boessenkool --- But please use PR33053 for that, or open a new PR? Let's keep this one for just this actual bug :-)

[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond

||2023-01-05 Status|RESOLVED|NEW Ever confirmed|0 |1 CC||segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- This is not a dup of 33053 (see PR33053#c5

[Bug c/33053] adopt accesses through a volatile-casted pointer as a GNU C extension

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053 --- Comment #6 from Segher Boessenkool --- (In reply to Daniel Lundin from comment #5) > This ought to result in stricter optimizing behavior from gcc, not the other > way around. Well, GCC did implement this already. My request was that we

[Bug target/103784] suboptimal code for returning bool value on target ppc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784 --- Comment #7 from Segher Boessenkool --- I do get that exact same code with everything from GCC 6 to GCC 12 as well though (modulo a small regression in GCC 10).

[Bug target/103784] suboptimal code for returning bool value on target ppc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784 --- Comment #6 from Segher Boessenkool --- Ugh, this PR is for GCC 12 only, ignore me please :-)

[Bug target/103784] suboptimal code for returning bool value on target ppc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784 --- Comment #5 from Segher Boessenkool --- I get simply subfic 3,3,2 srdi 3,3,63 xori 3,3,0x1 blr for this code. Did you use -O0 or similar?

[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 --- Comment #20 from Segher Boessenkool --- (In reply to Segher Boessenkool from comment #18) > But! We do not support 2.00 at all since quite a while (-mcpu=power4 > does not mean 2.00, it means 2.02, i.e. POWER4+ actually), so this macro >

[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 --- Comment #18 from Segher Boessenkool --- We have (since ten years or sp already) /* ISA 2.01 allowed FCFID to be done in 32-bit, previously it was 64-bit only. Enable 32-bit fcfid's on any of the switches for newer ISA machines. */

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

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

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #9 from Segher Boessenkool --- That patch looks good btw :-)

[Bug modula2/108153] Profiled lto bootstrap failure with modula2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #8 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #5) > So, I bet there must be some mismatch on whether M2Options_OverrideLocation > returns a signed or unsigned 32-bit value. > I believe the powerpc64le-linux

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147 --- Comment #13 from Segher Boessenkool --- (In reply to Gaius Mulley from comment #11) > Yes is looks as if '%' could be propagated though into the first parameter. > Changes could be made to m2linemap.cc to bump the parameters as you say with

[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*

[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 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

[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 #3 from Segher Boessenkool --- >0x10ffc2e0 <+0>: lis r2,4563 >0x10ffc2e4 <+4>: addir2,r2,29696 >0x10ffc2e8 <+8>: mflrr0 >0x10ffc2ec <+12>: std r30,-16(r1) >

[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

[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 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 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 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 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

[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 #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

[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/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/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

[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

[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 #9 from Segher Boessenkool --- I read as approval to backport, fwiw :-)

[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 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

[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. > >

<    1   2   3   4   5   6   7   8   9   10   >