[Bug tree-optimization/88055] [9 regression] ICE in extract_insn, at recog.c:2305 on ppc64le

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 --- Comment #10 from Segher Boessenkool --- Author: segher Date: Fri Apr 19 16:58:01 2019 New Revision: 270460 URL: https://gcc.gnu.org/viewcvs?rev=270460&root=gcc&view=rev Log: tree-call-cdce: If !HONOR_NANS do not make code with NaNs (PR88055)

[Bug tree-optimization/88055] [9 regression] ICE in extract_insn, at recog.c:2305 on ppc64le

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

[Bug c/90167] invalid example in GCC documentation wrt. effective type rules

||segher at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Segher Boessenkool --- The code accesses d, of type double, as an int. That is not a compatible type. It does not matter how it got there, what pointer casts trickery

[Bug target/90193] [8/9 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2

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

[Bug target/90193] [8/9 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193 --- Comment #6 from Segher Boessenkool --- It emits an insn instead if a jump_insn in the asm, during split1, in (define_split [(match_operand 0 "tls_address_pattern")] "TARGET_TLS_DIRECT_SEG_REFS" [(match_dup 0)] "operands[0] = ix86_rew

[Bug target/90193] [8/9 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193 --- Comment #7 from Segher Boessenkool --- The same splitter is what causes the bb of the asm to be marked as always falling through, which is why that non-fallthrough label is eventually deleted.

[Bug target/90193] [8/9 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193 --- Comment #8 from Segher Boessenkool --- (As Alexander said in comment 1... I need to learn how to read some day).

[Bug inline-asm/90181] Feature request: provide a way to explicitly select specific named registers in constraints

||2019-04-20 CC||segher at gcc dot gnu.org Resolution|WONTFIX |--- Ever confirmed|0 |1 --- Comment #4 from Segher Boessenkool --- (In reply to nfxjfg from comment #0

[Bug c/89774] Add flag to force single precision

||2019-04-22 CC||segher at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90070

[Bug tree-optimization/89804] optimization opportunity: move variable from stack to register

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

[Bug tree-optimization/89811] uint32_t load is not recognized if shifts are done in a fixed-size loop

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

[Bug target/88474] Inline built-in hypot for -ffast-math

||segher at gcc dot gnu.org Resolution|FIXED |--- --- Comment #4 from Segher Boessenkool --- It isn't implemented for any other targets yet. When I use __builtin_hypot with -ffast-math (I tried on powerpc64-linux) I get a call to __hypot_f

[Bug tree-optimization/89847] Simplify subexpressions of % constant

||2019-04-22 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- They didn't test the right targets ;-) While for x86_64 you get movl%edi,

[Bug c/90167] invalid example in GCC documentation wrt. effective type rules

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90167 --- Comment #3 from Segher Boessenkool --- But you are not accessing as the union type. You do the access with the type of one of its members. And that is UB. The part of the standard you quote is about things like union a_union f(double *p)

[Bug inline-asm/90181] Feature request: provide a way to explicitly select specific named registers in constraints

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 --- Comment #7 from Segher Boessenkool --- (In reply to nfxjfg from comment #6) > Yes, it's clear that that the constraint can't be _just_ the register name, > since they'll clash with builtin constraints now or with future > architectures (which

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #59 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #58) > If we don't want to go with #c35 at least for GCC 9, would the #c44 patch be > still useful without it (does it ever trigger say on the kernel where it > d

[Bug rtl-optimization/90249] [9 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249 Segher Boessenkool changed: What|Removed |Added Summary|[9/10 Regression] Code size |[9 Regression] Code size

[Bug other/90257] 8% degradation on cpu2006 403.gcc starting with r270484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #1 from Segher Boessenkool --- This patch from a few days ago craters our specint scores by a few percent. I'm marking this P1.

[Bug other/90257] 8% degradation on cpu2006 403.gcc starting with r270484

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

[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #14 from Segher Boessenkool --- I committed as r270601, on gcc-9-branch 2019-04-26 Segher Boessenkool PR other/90257 Revert the revert: 2019-04-21 H.J. Lu PR target/90178 Revert:

[Bug target/87213] ICE in final_scan_insn_1, at final.c:3070

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87213 Segher Boessenkool changed: What|Removed |Added Target||powerpc*-*-* Status|UNC

[Bug c/90036] [8/9/10 Regression] false positive: directive argument is null [-Werror=format-overflow=]

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

[Bug rtl-optimization/90249] [9/10 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249 --- Comment #4 from Segher Boessenkool --- That is code *size*. Code size is expected to grow a tiny bit, because of *better* register allocation. But we could not do make_more_copies at -Os, if that helps? (The hard register changes themselve

[Bug rtl-optimization/90249] [9/10 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249 --- Comment #6 from Segher Boessenkool --- (In reply to Wilco from comment #5) > (In reply to Segher Boessenkool from comment #4) > > That is code *size*. Code size is expected to grow a tiny bit, because of > > *better* register allocation. > >

[Bug c/90036] [8/9/10 Regression] false positive: directive argument is null [-Werror=format-overflow=]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036 --- Comment #6 from Segher Boessenkool --- (In reply to Martin Sebor from comment #5) > A conversion specification is what follows the % character (i.e., just the > 's' in in something like "%3s", with the 's' being called a conversion > specifie

[Bug rtl-optimization/89721] __builtin_mffs sometimes optimized away

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721 --- Comment #5 from Segher Boessenkool --- No, it needs backports. Thanks for reminding me!

[Bug target/65342] [7/8/9/10 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9/10 after r210201

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

[Bug target/71390] PowerPC GCC should warn if use does -mcpu=, and an old assembler was used

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

[Bug target/90323] powerpc should convert equivalent sequences to vec_sel()

|UNCONFIRMED |WAITING Last reconfirmed||2019-05-06 CC||segher at gcc dot gnu.org Version|8.3.0 |10.0 Summary|ppc should convert |powerpc should convert

[Bug target/90363] or1k: Extra mask insn after load from memory

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

[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Segher Boes

[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 --- Comment #7 from Segher Boessenkool --- From the combine dump of without_sel: Trying 8, 9 -> 10: 8: r127:V4SI=r124:V4SI^r131:V4SI REG_DEAD r131:V4SI 9: r122:V4SI=r127:V4SI&r130:V4SI REG_DEAD r130:V4SI REG_DEAD r127:V

[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90418 --- Comment #8 from Segher Boessenkool --- It also fails all over on powerpc-linux. Pretty much all targets just do something like /* Extra stack adjustment for exception handler return. */ if (crtl->calls_eh_return) emit_insn (gen_add

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410 --- Comment #24 from Segher Boessenkool --- (In reply to Jonny Grant from comment #23) > Would it be better if I created a separate PR for this? #line 0 ? Yes please, it's a separate issue, and will get lost here. Thanks.

[Bug c/90476] prepossessor should error if #line 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90476 --- Comment #3 from Segher Boessenkool --- Where is it documented (in GCC). then? I can't find it.

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #6 from Segher Boessenkool --- Confirmed. We have for the thunk .set.LTHUNK0,_ZN12Intermediate1vEv .align 2 .p2align 4,,15 .globl _ZThn8_N12Intermediate1vEv .type _ZThn8_N12Intermediat

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

|UNCONFIRMED |WAITING Last reconfirmed||2019-05-18 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- What does "32<->64" mean?

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90453 --- Comment #3 from Segher Boessenkool --- What should the semantics of this be? There are four 32-bit elts each in packedl and packedr, which of those go where in unpacked? I think what you want to do can be expressed with just two or maybe th

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

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

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90453 --- Comment #7 from Segher Boessenkool --- Note that vec_pack works for unsigned as well. For vec_unpack[hl] of unsigned you can do a vec_merge[hl] instead (with the first arg a zero vector).

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #9 from Segher Boessenkool --- With a local entry offset? Do you mean it has non-zero top three bits of st_other?

[Bug sanitizer/90639] [10 Regression] Boostrap failure with recent trunk on POWER9

|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-26 CC||segher at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0

[Bug other/90381] New test case gcc.dg/tree-ssa/pr88676-2.c fails with its introduction in r270934

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

[Bug target/90407] Compilation error of a C function generated from Simulink

||segher at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Segher Boessenkool --- I don't know why anything decided that pattern needs splitting -- it matches alternative 2 just fine afaics. You don't show what decided

[Bug target/90639] [10 Regression] Boostrap failure with recent trunk

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90639 --- Comment #2 from Segher Boessenkool --- Author: segher Date: Mon May 27 19:12:19 2019 New Revision: 271668 URL: https://gcc.gnu.org/viewcvs?rev=271668&root=gcc&view=rev Log: rs6000: Fix sanitizer build (PR90639) The assembler code needs to s

[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong

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

[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689 --- Comment #1 from Segher Boessenkool --- I cannot reproduce this (on a native compiler). Do you use some non-default defaults, maybe? And, what SVN revision did you test?

[Bug c/90680] Misleading fixit warning with pointers to pointers

||2019-06-01 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed.

[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2019-05-31 0

[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689 --- Comment #4 from Segher Boessenkool --- rs6000.c does if (HAVE_AS_PLTSEQ && DEFAULT_ABI == ABI_ELFv2 && GET_CODE (func_desc) == SYMBOL_REF) { rtvec v = gen_rt

[Bug target/90639] [10 Regression] Boostrap failure with recent trunk

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

[Bug fortran/89531] Possible memory corruption in the gfortran front-end

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

[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'

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

[Bug inline-asm/90791] optimization accepts invalid inline-asm (more operands than is specified) due to dead code

||2019-06-09 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Do we want to error for a template containing a reference to a non-existing operand, even when this

[Bug target/90823] PowerPC command line switches don't work with #pragma CPU target or target attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90823 --- Comment #1 from Segher Boessenkool --- We can now remove most or all of the uses of -mpower9-vector and the like from the testsuite, since we now have -mdejagnu-cpu=. And then we can start to make -mpower9-vector not do anything.

[Bug target/90822] Remove PowerPC lfiwax and lfiwzx patterns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90822 --- Comment #1 from Segher Boessenkool --- gen_lfiwax is called by the splitters of floatsi2_lfiwax and floatsi2_lfiwax_mem, which you say can go away (nice :-) ); but it is also called by *round322_fprs, which needs to be dealt with first (and s

[Bug target/90823] PowerPC command line switches don't work with #pragma CPU target or target attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90823 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/90824] PowerPC should generate better code for SFmode splats for power8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90824 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #19 from Segher Boessenkool --- Also, please post proper patches, to the gcc-patches mailing list, as detailed in , if you want those patches to be approved.

[Bug target/88952] The asm operator modifiers for rs6000 should be documented like they are for x86

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

[Bug target/88952] The asm operator modifiers for rs6000 should be documented like they are for x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952 --- Comment #14 from Segher Boessenkool --- Ah no, that is all understood. What I am commenting on is that you have an odd-even register pair (9 and 10), while every GCC I know of and/or tested uses an even-odd pair (10 and 11 usually). Curious

[Bug inline-asm/90907] Binary crashes if both asm() and __thread are used in the same code

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

[Bug debug/90944] combine debug file created when it shouldn't be

||2019-06-19 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed.

[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #13 from Segher Boessenkool --- addis 9,2,.LC1@toc@ha ld 9,.LC1@toc@l(9) ... ld 9,0(9) ... ld 10,0(9) ... mtctr 10 ... bctrl .LC1: .quad __f_MOD_c_ So that symbol is derefe

[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #17 from Segher Boessenkool --- sched2 swaps the two insns (37 and 40 for me -- use -dp to see the numbers in your .s file, use -da if you want lots of dumps, -dap together). So why did sched2 decide it can swap these? They are in t

[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #18 from Segher Boessenkool --- -mno-power8-fusion seems to fix this. Can you confirm?

[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug rtl-optimization/88233] combine fails to merge insns leaving unneeded reg copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233 --- Comment #2 from Segher Boessenkool --- Currently full lower_subreg runs only after the first splitter pass. This is much too late to be effective for this testcase. Running it before combine (I put it immediately after loop2) works, for all

[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #11 from Segher Boessenkool --- Such a rewrite function would be great I think. I don't want the -mdejagnu-cpu thing to need any deeper code changes, but this attacks the one problem the simple -mcpu override did not: specs. (I cann

[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #12 from Segher Boessenkool --- Ah, common/config/aarch64/aarch64-common.c .

[Bug c/91092] Error on implicit function declarations by default

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

[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #24 from Segher Boessenkool --- Is that disallowed? Is there any way to prevent that from happening, in general?

[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #25 from Segher Boessenkool --- At expand time, the assignment is ;; c_ = c; (insn 35 34 36 (set (reg/f:DI 140) (unspec:DI [ (symbol_ref:DI ("*.LANCHOR1") [flags 0x182]) (reg:DI 2 2)

[Bug c/89072] -Wall -Werror should be defaults

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

[Bug target/91102] [9/10 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102 --- Comment #2 from Segher Boessenkool --- 91102.c: In function 'foo': 91102.c:7:1: warning: control reaches end of non-void function [-Wreturn-type] 7 | } | ^ so ice-on-invalid-code? Although, hrm, inserting "return 3;" there still I

[Bug target/91102] [9/10 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102 --- Comment #3 from Segher Boessenkool --- Before combine there were also (insn 8 7 9 3 (set (reg/v:DI 95 [ c ]) (reg:DI 92 [ b$h ])) "91102.c":18:15 47 {*movdi_aarch64} (nil)) (insn 11 10 12 3 (set (reg:DI 100) (subreg:DI (

[Bug c/91092] Error on implicit function declarations by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug rtl-optimization/88233] combine fails to merge insns leaving unneeded reg copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233 --- Comment #3 from Segher Boessenkool --- Author: segher Date: Mon Jul 8 17:35:12 2019 New Revision: 273240 URL: https://gcc.gnu.org/viewcvs?rev=273240&root=gcc&view=rev Log: subreg: Add -fsplit-wide-types-early (PR88233) Currently the second

[Bug rtl-optimization/88233] combine fails to merge insns leaving unneeded reg copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233 --- Comment #4 from Segher Boessenkool --- Author: segher Date: Mon Jul 8 20:38:46 2019 New Revision: 273245 URL: https://gcc.gnu.org/viewcvs?rev=273245&root=gcc&view=rev Log: rs6000: Add testcase for PR88233 This testcase tests that with -mcp

[Bug target/91116] New: bad register choices for rs6000 -m32

Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- In the new testcase pr88233.c, which is typedef struct { double a[2]; } A; A foo (const A *a) { return *a; } we currently get as generated code for -m32 addi 10,4,4

[Bug target/91135] __linux__ not defined with -mcall-aixdesc on 9.x and ppc64

||2019-07-10 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confimed. Testcase: :|gcc -E -dM - -mcall-aixdesc|grep linux

[Bug target/91135] [9/10 Regression] __linux__ not defined with -mcall-aixdesc on 9.x and ppc64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135 --- Comment #4 from Segher Boessenkool --- You still haven't said what the kernel uses it for, when, in what way. It probably shouldn't. But, -mcall-* should not change whether __linux__ and friends are defined.

[Bug target/91148] PowerPC build gets several warnings due to -Wformat-diag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148 --- Comment #3 from Segher Boessenkool --- 12593 |"internal error: builtin function %qs already processed", That's a fatal_error; users will never see that, *no one* will ever see that. 14747 | error ("builtin function %qs is only vali

[Bug target/91148] PowerPC build gets several warnings due to -Wformat-diag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148 --- Comment #4 from Segher Boessenkool --- And I am quite serious about that last point: I have to redirect stderr to file and search that with a text editor to find the errors, there are a dozen screenfuls of useless warnings (about two screens

[Bug target/91135] [9/10 Regression] __linux__ not defined with -mcall-aixdesc on 9.x and ppc64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135 --- Comment #8 from Segher Boessenkool --- -mcall-* should change the calling convention, not anything else OS-related. -mcall-aixdesc is the *default* for powerpc64-linux.

[Bug target/91148] PowerPC build gets several warnings due to -Wformat-diag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148 --- Comment #5 from Segher Boessenkool --- I have a patch removing "builtin function" where that is redundant.

[Bug target/91148] PowerPC build gets several warnings due to -Wformat-diag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148 --- Comment #6 from Segher Boessenkool --- Author: segher Date: Sat Jul 13 15:57:21 2019 New Revision: 273468 URL: https://gcc.gnu.org/viewcvs?rev=273468&root=gcc&view=rev Log: rs6000: Shut up -Wformat-diag somewhat We currently get lot of buil

[Bug target/91148] PowerPC build gets several warnings due to -Wformat-diag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148 --- Comment #7 from Segher Boessenkool --- Author: segher Date: Sun Jul 14 08:24:38 2019 New Revision: 273475 URL: https://gcc.gnu.org/viewcvs?rev=273475&root=gcc&view=rev Log: rs6000: Shut up -Wformat-diag a little more PR target/9114

[Bug target/86285] We don't mangle __ieee128 correctly using -mlong-double-64 -mabi=ieeelongdouble

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86285 --- Comment #5 from Segher Boessenkool --- Author: segher Date: Mon Jul 2 21:25:10 2018 New Revision: 262320 URL: https://gcc.gnu.org/viewcvs?rev=262320&root=gcc&view=rev Log: rs6000: Set up ieee128_float_type_node correctly (PR86285) We shoul

[Bug target/86381] New: Configuration powerpc-unknown-linux-gnu_paired not supported

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: segher at gcc dot gnu.org Target Milestone: --- Status: RESOLVED Resolution: DUPLICATE It's listed in contrib/c

[Bug target/86382] Configuration powerpc-unknown-linux-gnu_paired not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86382 --- Comment #1 from Segher Boessenkool --- *** Bug 86381 has been marked as a duplicate of this bug. ***

[Bug target/86382] Configuration powerpc-unknown-linux-gnu_paired not supported

|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Mine.

[Bug target/86285] We don't mangle __ieee128 correctly using -mlong-double-64 -mabi=ieeelongdouble

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

[Bug target/86382] Configuration powerpc-unknown-linux-gnu_paired not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86382 --- Comment #3 from Segher Boessenkool --- Author: segher Date: Tue Jul 3 11:22:24 2018 New Revision: 262340 URL: https://gcc.gnu.org/viewcvs?rev=262340&root=gcc&view=rev Log: Remove powerpc-linux_paired from config-list.mk The target has been

[Bug target/86382] Configuration powerpc-unknown-linux-gnu_paired not supported

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

[Bug middle-end/86554] Incorrect code generation with signed/unsigned comparison

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

[Bug rtl-optimization/85805] [7/8/9 Regression] Wrong code for 64 bit comparisons on avr-gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805 --- Comment #7 from Segher Boessenkool --- I suspect this is because we have hard regs here, not pseudos. Not a good idea in general, which is why other targets don't do this. Perhaps it is a mode mixup in the known value tracking? Confirmed.

[Bug rtl-optimization/85925] [7/8/9 Regression] Mis-compilation at -02, masking with 257 goes wrong in combine

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925 --- Comment #4 from Segher Boessenkool --- Any progress with this PR?

[Bug target/85610] Unable to optimize away mov followed by compare into a cmpb in case of atomic_load

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

<    5   6   7   8   9   10   11   12   13   14   >