[Bug target/83969] [8 Regression] ICE in final_scan_insn, at final.c:2997 (error: could not split insn) for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83969 --- Comment #5 from Michael Meissner --- On Mon, Jan 22, 2018 at 08:13:11PM +, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83969 > > --- Comment #2 from Segher Boessenkool --- > Where do you get TImode with this testcase? Whoops, I thought this was for PR 83862, which was adjacent in my mailbox. Sorry.
[Bug target/83969] [8 Regression] ICE in final_scan_insn, at final.c:2997 (error: could not split insn) for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83969
--- Comment #4 from Michael Meissner ---
On Mon, Jan 22, 2018 at 08:13:11PM +, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83969
>
> --- Comment #2 from Segher Boessenkool ---
> Where do you get TImode with this testcase?
You get an error, because signbit is only valid for floating point types:
pr83862.c:17:46: error: non-floating-point argument in call to function
'__builtin_signbit'
int sbr (TYPE a) { return __builtin_signbit (a); }
[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210 --- Comment #5 from Michael Meissner --- On Fri, Apr 14, 2017 at 07:26:57PM +, bergner at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210 > > --- Comment #4 from Peter Bergner --- > So it seems rs6000_pragma_target_parse() ends up calling > rs6000_option_override_internal(), which is modifying the options via global > variables. All other arches pass in the option variables to their > *__option_override_internal(), that they want updated/set and those seem to be > scoped to the area of the file they reside in. If that is the case, then we need to modify the code not to touch the global variables.
[Bug target/80108] ICE in aggregate_value_p at function.c:2028
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80108
--- Comment #11 from Michael Meissner ---
On Fri, Mar 31, 2017 at 06:35:20PM +, kelvin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80108
>
> --- Comment #9 from kelvin at gcc dot gnu.org ---
> I've got a patch now that resolves this problem without creating regressions.
> I'm attaching it for "discussion" here before I post for "official review".
>
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c (revision 246573)
> +++ gcc/config/rs6000/rs6000.c (working copy)
> @@ -4273,8 +4273,30 @@ rs6000_option_override_internal (bool global_init_
>/* For the newer switches (vsx, dfp, etc.) set some of the older options,
> unless the user explicitly used the -mno- to disable the code.
> */
>if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_DFORM_SCALAR
> - || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0 ||
> TARGET_P9_MINMAX)
> + || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0)
> rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit);
> + else if (TARGET_P9_MINMAX)
> +{
> + if (have_cpu)
> + {
> + if (cpu_index == PROCESSOR_POWER9)
> + /* legacy behavior: allow -mcpu-power9 with certain capabilities
> + (eg -mno-vsx) explicitly disabled. */
Note, -mpower9-minmax makes no sense without -mvsx, since it is a VSX
instruction.
It also requires upper reg support for the appropriate mode (i.e. double
requires TARGET_UPPER_REGS_DF and float requires TARGET_UPPER_REGS_SF, it is
probably simpler to require both). This comes from a LRA behavior of crashing
if the constraint allows more registers than the register class allows. We
could add additional constraints in the min/max insns if we wanted to support
no upper regs and min/max, but I don't think it is worth it.
(define_insn "*s3_vsx"
[(set (match_operand:SFDF 0 "vsx_register_operand" "=,")
(fp_minmax:SFDF (match_operand:SFDF 1 "vsx_register_operand"
",")
(match_operand:SFDF 2 "vsx_register_operand"
",")))]
"TARGET_VSX && TARGET__FPR"
{
return (TARGET_P9_MINMAX
? "xscdp %x0,%x1,%x2"
: "xsdp %x0,%x1,%x2");
}
[(set_attr "type" "fp")])
[Bug target/80108] ICE in aggregate_value_p at function.c:2028
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80108 --- Comment #5 from Michael Meissner --- On Wed, Mar 29, 2017 at 05:14:38PM +, kelvin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80108 > > kelvin at gcc dot gnu.org changed: > >What|Removed |Added > > CC||kelvin at gcc dot gnu.org > > --- Comment #2 from kelvin at gcc dot gnu.org --- > I'm seeking consensus on the "right thing to do". Should I make sure that > -mpower9-minmax turns on whatever additional target options are necessary in > order to make this work? My opinion is if -mcpu= is not set, then -mpower9-minmax should set -mcpu=power9. However, -mno-power9-minmax should not set anything. If -mcpu= is not -mcpu=power9, then this is an eror.
[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543 --- Comment #19 from Michael Meissner --- On Tue, Mar 21, 2017 at 09:00:37PM +, brenohl at br dot ibm.com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543 > > --- Comment #16 from Breno Leitao --- > If it helps, the problem is reproducible on some other packages as well. Here > is another example: > > https://nopaste.linux-dev.org/?1122124 Note, the source is not complete. Please attach the file as a text file to this bug report.
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #6 from Michael Meissner --- On Thu, Mar 16, 2017 at 03:10:19PM +, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 Generally, the "vector" keyword is a conditional macro that looks at the next token or two to decide whether or not to expand the macro. If the next token is one of the standard types or __bool/__pixel, then __vector/vector is expanded to: __attribute__((altivec(vector__)) The magic is in rs6000-c.c, particularly in altivec_categorize_keyword, init_vector_keywords, rs6000_macro_to_expand, and rs6000_cpu_cpp_builtins.
[Bug target/79752] incorrect code generation for __divkf3 with -O2 -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79752 --- Comment #2 from Michael Meissner --- On Tue, Feb 28, 2017 at 09:13:42PM +, acsawdey at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79752 > > --- Comment #1 from acsawdey at gcc dot gnu.org --- > Meissner spotted the cause. Verified that this fixes it: > > Index: ../trunk/gcc/config/rs6000/rs6000.md > === > --- ../trunk/gcc/config/rs6000/rs6000.md(revision 245787) > +++ ../trunk/gcc/config/rs6000/rs6000.md(working copy) > @@ -3161,7 +3161,7 @@ > && ! reg_mentioned_p (operands[3], operands[1]) > && ! reg_mentioned_p (operands[3], operands[2])" >[(set (match_dup 0) > - (div:GPR (match_dup 1) > + (udiv:GPR (match_dup 1) > (match_dup 2))) > (set (match_dup 3) > (mult:GPR (match_dup 0) > > Now to bootstrap/regtest this and post. One minor formatting nit. When you change div -> udiv, you will need to indent the (match_dup 20 on the next line by one space.
[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79354 --- Comment #7 from Michael Meissner --- On Fri, Feb 03, 2017 at 01:41:44AM +, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79354 > > --- Comment #3 from Jakub Jelinek --- > Created attachment 40661 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40661=edit > gcc7-pr79354.patch > > Untested fix. Yes, this looks right.
[Bug target/79158] gcc.target/powerpc/pr70669.c fails on powerpc BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79158 --- Comment #2 from Michael Meissner --- On Mon, Jan 30, 2017 at 09:17:26PM +, pthaugen at gcc dot gnu.org wrote: > Mike, Does this reasoning sound correct to you? If so I'll submit a patch. That looks fine. Thanks.
[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404 --- Comment #32 from Michael Meissner --- On Thu, Feb 11, 2016 at 05:53:35PM +, meissner at linux dot vnet.ibm.com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404 > > --- Comment #31 from Michael Meissner --- > On Thu, Feb 11, 2016 at 02:32:13AM +, bernds at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404 > > > > --- Comment #30 from Bernd Schmidt --- > > Something like this maybe? I don't know much about the machine and can't say > > whether the earlyclobber is justified, but looking at my dumps this appears > > to > > prevent the problematic peephole from triggering. No testing beyond that. > > > > Index: rs6000.c > > === > > --- rs6000.c(revision 233217) > > +++ rs6000.c(working copy) > > @@ -35801,6 +35801,9 @@ fusion_gpr_load_p (rtx addis_reg, /* reg > >if (!fusion_gpr_addis (addis_value, GET_MODE (addis_value))) > > return false; > > > > + if (reg_overlap_mentioned_p (target, addis_value)) > > +return false; > > + > >/* Allow sign/zero extension. */ > >if (GET_CODE (mem) == ZERO_EXTEND > >|| (GET_CODE (mem) == SIGN_EXTEND && TARGET_P8_FUSION_SIGN)) > > In looking at it, I probably don't need the early clobber. Let me play with > it. It turns out the earlyclobber was indeed the issue, and just eliminating the earlyclobber and providing constraints for the combined insns allowed profiledbootstrap with LTO to do a complete build. Just to be sure, I also did a profiledbootstrap with LTO and specifying -O3. I'll submit the patches to the patches mailing list.
[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404 --- Comment #31 from Michael Meissner --- On Thu, Feb 11, 2016 at 02:32:13AM +, bernds at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404 > > --- Comment #30 from Bernd Schmidt --- > Something like this maybe? I don't know much about the machine and can't say > whether the earlyclobber is justified, but looking at my dumps this appears to > prevent the problematic peephole from triggering. No testing beyond that. > > Index: rs6000.c > === > --- rs6000.c(revision 233217) > +++ rs6000.c(working copy) > @@ -35801,6 +35801,9 @@ fusion_gpr_load_p (rtx addis_reg, /* reg >if (!fusion_gpr_addis (addis_value, GET_MODE (addis_value))) > return false; > > + if (reg_overlap_mentioned_p (target, addis_value)) > +return false; > + >/* Allow sign/zero extension. */ >if (GET_CODE (mem) == ZERO_EXTEND >|| (GET_CODE (mem) == SIGN_EXTEND && TARGET_P8_FUSION_SIGN)) In looking at it, I probably don't need the early clobber. Let me play with it. To be clear, power8 has two types of fusion. The problematical one is GPR load fusion. Normally addresses to large arrays and to TOC entries are two instructions: (set (reg1) (high ...)) (set (reg2) (mem (lo_sum (reg1) (... or (set (reg1) (plus (reg3) (const_int 65536))) (set (reg2) (mem (plus (reg1) (const_int 10 In order to use fusion, the first SET must be adjacent to the second SET, and the register being loaded with the upper bits (reg1) must be identical to the register being loaded from memory (reg2). This requirement means that reg1/reg2 must not be R0 (in the PowerPC memory addressing, a base register of R0 means no register used, so we can't do the optimization if R0 is the target. Now, in the future, we eventually hope to push this earlier before reload, but during development, I was stymied that reload did not like asymetric addressing (i.e. loads with fusion to GPR registers could have the extended addressing form, but stores could not). So I used a peephole2 to get what advantages that I could from the existing insns. Power9 fusion is more general, in that the register to get the high address bits does not have to be the same as the register being loaded. In addition, you can now fuse GPR stores and load/store to the floating point/vector registers. In theory we could use the new fusion scheduling feature to do fusion, but that is a GCC 7.x feature, not a fix for stage4 of GCC 6.x.
[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404 --- Comment #12 from Michael Meissner --- On Fri, Feb 05, 2016 at 11:57:05PM +, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404 > > Bill Schmidt changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org, >||meissner at gcc dot gnu.org, >||rguenth at gcc dot gnu.org, >||segher at gcc dot gnu.org > > --- Comment #11 from Bill Schmidt --- > After discussing with Segher offline, I think the way forward will be to > change > the definition of these fusion peepholes for now. Instead of nesting the > plus, > we can probably just add an argument to the UNSPEC to keep track of the extra > operand. If necessary, we can perhaps add a note to hold the full address; > not > sure that the final few passes would care. > > This would be just a workaround for GCC 6 since this should really be > considered a blocker. In GCC 7 the fusion patterns are supposed to be > introduced earlier and last longer, and the nested plus will cause > difficulties > all over the place, so this needs to be rethought. > > CCing the release managers for consideration of this as a P1 blocker. Another option for GCC 6 is just to disable fusion. I'm not sure we've seen any real benefits from it.
[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69611 --- Comment #3 from Michael Meissner --- On Mon, Feb 01, 2016 at 11:35:35PM +, joseph at codesourcery dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69611 > > --- Comment #1 from joseph at codesourcery dot com dot com> --- > If __NO_FPRS__ is undefined, that means you are compiling for classic hard > float. Which means that the soft-fp code is not needed - if you need to > keep it in libgcc_s.so for binary compatibility, using t-hardfp for > hard-float multilibs, as on powerpc*-*-linux*, would be better. The issue is there are references to sfp-exceptions.o functions in the PowerPC FreeBSD case, and sfp-exceptions.o is not built. I tend to think using: #ifdef __FLOAT128__ is cleaner at this point of time (stage4) than trying to make sure all of the different PowerPC systems build correctly by adding sfp-exceptions.c to the build list.
[Bug target/65614] [5 Regression] PowerPC VSX systems should use XSCPSGNDP to copy scalar fp data to/from Altivec registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65614 --- Comment #5 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Fri, Apr 03, 2015 at 07:19:24PM +, dje at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65614 --- Comment #4 from David Edelsohn dje at gcc dot gnu.org --- Comment on attachment 35227 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35227 Proposed patch to fix the problem The FLOAT_EXTEND cost should be based on the processor tuning, not the ISA. This patch moves the decision to the cost structure based on the processor tuning. Is it ok to install? [gcc] 2015-04-06 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65614 * config/rs6000/rs6000.c (struct processor_costs): Add cost field for SF-DF conversions to make FLOAT_EXTEND more expensive, so that LFD is used to load double constants instead of LFS. Add defaults for all costs structures. Add comments for missing initialization fields. (size32_cost): Likewise. (size64_cost): Likewise. (rs64a_cost): Likewise. (mpccore_cost): Likewise. (ppc403_cost): Likewise. (ppc405_cost): Likewise. (ppc440_cost): Likewise. (ppc476_cost): Likewise. (ppc601_cost): Likewise. (ppc603_cost): Likewise. (ppc604_cost): Likewise. (ppc604e_cost): Likewise. (ppc620_cost): Likewise. (ppc630_cost): Likewise. (ppccell_cost): Likewise. (ppc750_cost): Likewise. (ppc7450_cost): Likewise. (ppc8540_cost): Likewise. (ppce300c2c3_cost): Likewise. (ppce500mc_cost): Likewise. (ppce500mc64_cost): Likewise. (ppce5500_cost): Likewise. (ppce6500_cost): Likewise. (titan_cost): Likewise. (power4_cost): Likewise. (power6_cost): Likewise. (power7_cost): Likewise. (power8_cost): Likewise. (ppca2_cost): Likewise. (rs6000_rtx_costs): Make FLOAT_EXTEND use SFDF_convert field. * config/rs6000/rs6000.md (extendsfdf2_fpr): Generate XSCPSGNDP instead of XXLOR to copy SFmode to clear out dirty bits created when SFmode denormals are generated. (movmode_hardfloat, FMOVE32 case): Likewise. (truncdfsf2_fpr): Add support for ISA 2.07 XSRSP instruction. [gcc/testsuite] 2015-04-06 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65614 * gcc.target/powerpc/compress-float-ppc-pic.c: Run test on power5 to get floating point compression. * gcc.target/powerpc/compress-foat-ppc.c: Likewise.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #14 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Tue, Apr 08, 2014 at 03:21:13PM +, dje at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #13 from David Edelsohn dje at gcc dot gnu.org --- Gentlemen, I really do not understand this discussion. I used the term crude and receive a response that it is not crude, but it is dangerous. WTF? Why is anyone trying to sell the patch when I repeatedly have said that I do not disagree with it in principle? I only am trying to ensure that this is the right use of the GCC API. i386 uses this idiom a lot; rs6000 does not. I see multiple responses trying to convince me of a patch with which I already agree and no one writing a one line comment. When you are doing a subreg type operation, before reload, you must NOT use the register number directly. This is the dangerous part that was mentioned. Hence using gen_highpart, gen_lowpart, or simplify_gen_subreg is the appropriate solution. If you are doing splits after reload, and are dealing with whole registers, the preferred solution is to create a new REG with the appropriate register number. In particular, gen_highpart and gen_lowpart must not be used after reload. However, up until the patch to add more checking, simplify_gen_subreg could be used after reload. The alpha, arm, i386, ia64, iq2000, m32k, m68k, mips, msp430, pa, pdp11, picochip, rl78, rs6000, s390, sh, sparc, spu, and xtensa all generate a call to gen_rtx_REG using REGNO of an operand to change types. Out of force of habit, I've tended to use simplify_gen_subreg when doing splitting, no matter whether it is before or after reload. I thought with 'simplify' in the name, it would do the right thing after reload, but evidently it does not.
[Bug target/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #11 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Thu, Dec 12, 2013 at 08:11:23AM +, stigge at antcom dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #10 from Roland Stigge stigge at antcom dot de --- Please apply this patch only to 4.8.0 for now. The trunk needs some additional care, I'm working on this separately and will open a separate bug when it's ready. Would be nice if you could have a look at powerpc-linux-gnuspe anyway, though. ;-) Is there any way I can test powerpc-linux-gnuspe on a power7 running Linux? Right now, I can only do visual code inspection of the .s file.
[Bug target/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #12 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Thu, Dec 12, 2013 at 12:22:13AM +, meissner at linux dot vnet.ibm.com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #9 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Wed, Dec 11, 2013 at 04:37:20PM +, dje at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #8 from David Edelsohn dje at gcc dot gnu.org --- Mike, can you apply the patch to the 4.8 branch? Thanks, David Note, the patch no longer applies to the trunk due to adding a PTImode case. I'll test both gcc 4.8/trunk with the patch for both. Sorry for breaking this, and went unresponsive. I tested this patch lifted from the bugzilla, and it does fix the problem for GCC 4.8. I'm also including the appropriate patch for GCC 4.9 (different due to the surrounding code being different). While there are other problems with SPE in GCC 4.9, I feel this patch is safe to apply. I have bootstraped the patch on a power7 running linux powerpc64 and there were no regressions between the unpatched gcc 4.8 and the build with the patch attached. I have verified that the bug is fixed when I build a SPE compiler with the patch attached for the GCC 4.8 patch. I have also bootstraped the GCC 4.9 patch on a power7 running linux powerpc64. As I write this message, I haven't done the make check regression test, but I will do that shortly. Are these patches ok to apply? I can apply just the 4.8 patch or both the 4.8 and 4.9 patches. 2013-12-12 Roland Stigge sti...@antcom.de Michael Meissner meiss...@linux.vnet.ibm.com * config/rs6000/rs6000.c (rs6000_legitimate_offset_address_p): Only check TFmode for SPE constants. Don't check TImode or TDmode.
[Bug target/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #13 from Michael Meissner meissner at linux dot vnet.ibm.com --- Created attachment 31429 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31429action=edit pr57386.patch01-gcc49
[Bug target/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #9 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Wed, Dec 11, 2013 at 04:37:20PM +, dje at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #8 from David Edelsohn dje at gcc dot gnu.org --- Mike, can you apply the patch to the 4.8 branch? Thanks, David Note, the patch no longer applies to the trunk due to adding a PTImode case. I'll test both gcc 4.8/trunk with the patch for both. Sorry for breaking this, and went unresponsive.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #10 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Wed, Nov 13, 2013 at 06:03:50AM +, kcc at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #7 from Kostya Serebryany kcc at gcc dot gnu.org --- Is this fixed by http://gcc.gnu.org/viewcvs?rev=204726root=gccview=rev ? No, other patches are needed as communicated in the other threads on this.
[Bug other/12081] Gcc can't be compiled with -mregparm=3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12081 --- Comment #30 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Wed, Aug 07, 2013 at 07:22:32PM +, olegendo at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12081 --- Comment #29 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #28) (In reply to Michael Meissner from comment #27) The patch from Oleg Endo breaks the PowerPC build. .../gcc/config/rs6000/rs6000.c: In function ‘void rs6000_emit_swdiv(rtx_def*, rtx_def*, rtx_def*, bool)’: .../gcc/config/rs6000/rs6000.c:28142: error: invalid cast from type ‘const insn_gen_fn’ to type ‘rtx_def* (*)(rtx_def*, rtx_def*, rtx_def*)’ .../gcc/config/rs6000/rs6000.c: In function ‘void rs6000_emit_swrsqrt(rtx_def*, rtx_def*)’: .../gcc/config/rs6000/rs6000.c:28220: error: invalid cast from type ‘const insn_gen_fn’ to type ‘rtx_def* (*)(rtx_def*, rtx_def*, rtx_def*)’ Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00323.html Fixed on trunk. http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=201580 PR other/12081 config/rs6000/rs6000.c (gen_2arg_fn_t): Remove typedef. (rs6000_emit_swdiv, rs6000_emit_swrsqrt): Don't cast result of GEN_FCN to gen_2arg_fn_t. Great, thanks. I was just starting the build process to verify it.
[Bug testsuite/41701] scan-assembler-not has false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41701 --- Comment #6 from Michael Meissner meissner at linux dot vnet.ibm.com 2011-12-08 19:34:47 UTC --- On Thu, Dec 08, 2011 at 07:20:50PM +, gseanmcg at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41701 --- Comment #4 from Sean McGovern gseanmcg at gmail dot com 2011-12-08 19:20:50 UTC --- Is this fixed now? If so, it can be closed. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. I closed it. Thanks.
[Bug target/51390] Builtin changes on November 29th, broke recip-5.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51390 --- Comment #5 from Michael Meissner meissner at linux dot vnet.ibm.com 2011-12-06 18:21:48 UTC --- On Sun, Dec 04, 2011 at 03:52:47PM +, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51390 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-12-04 15:52:47 UTC --- On powerpc-apple-darwin9 (G5) at revision 181953, I see FAIL: gcc.target/powerpc/recip-5.c (internal compiler error) FAIL: gcc.target/powerpc/recip-5.c (test for excess errors) UNRESOLVED: gcc.target/powerpc/recip-5.c scan-assembler-times xvredp 4 UNRESOLVED: gcc.target/powerpc/recip-5.c scan-assembler-times xvresp 5 UNRESOLVED: gcc.target/powerpc/recip-5.c scan-assembler-times xsredp 2 UNRESOLVED: gcc.target/powerpc/recip-5.c scan-assembler-times fres 2 The ICE is [karma] f90/bug% gfc -mrecip=all -ffast-math -mcpu=power7 /opt/gcc/work/gcc/testsuite/gcc.target/powerpc/recip-5.c /opt/gcc/work/gcc/testsuite/gcc.target/powerpc/recip-5.c: In function 'd_recip': /opt/gcc/work/gcc/testsuite/gcc.target/powerpc/recip-5.c:12:39: error: Builtin function __builtin_recipdiv is not supported with the current options /opt/gcc/work/gcc/testsuite/gcc.target/powerpc/recip-5.c:12:39: internal compiler error: Bus error There was no failure for gcc.target/powerpc/recip-5.c at revision res-181782. Hmmm, you debug where it is segfaulting? I evidently messed up the standard skip darwin on that test (since darwin don't support -mcpu=power7 to turn on VSX), but even so the compiler should not segfault. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You reported the bug.
[Bug rtl-optimization/50101] GCC 4.5 and 4.6 generate suboptimal code on ppc for countdown loops when the CTR register cannot be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50101 --- Comment #8 from Michael Meissner meissner at linux dot vnet.ibm.com 2011-08-19 14:05:51 UTC --- On Thu, Aug 18, 2011 at 08:58:28AM +, rguenth at gcc dot gnu.org wrote: Did you try pessimizing the non-ctr reg alternatives (and the memory alternative even more)? Like adding ! to the non-ctr alternatives and ? to the memory one? Not sure if those markers are looked at by IRA though. Yes, I should have mentioned that I tried various combinations of ?, !, and * and the combinations I tried aborted. I've certainly suspected that IRA now longer looks at !, ?, and * like the previous register allocator did previously. It may be that it is special due to being a JUMP_INSN.
[Bug target/48262] [4.7 Regression] Subversion id 171341 breaks various vectorization files on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48262 --- Comment #17 from Michael Meissner meissner at linux dot vnet.ibm.com 2011-03-31 18:43:44 UTC --- On Wed, Mar 30, 2011 at 09:43:05PM +, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48262 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-30 21:42:39 UTC --- Test results with the patches in comment #5 and #6 posted at http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02627.html and http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02983.html with no new regression. Could the patches be committed? -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. I was hoping Andrew would submit the patches. I just sent them out, for review: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02249.html
