Re: [RFC] New optab for `a&~b` (and future expand improvements)

Hi! On Wed, May 15, 2024 at 02:39:12PM +, Andrew Pinski via Gcc wrote: > * Add an optab for andnot (`a & ~b`) RTL can just as easily recognise (AND (NOT (...))), if Gimple has problems with that that is just a deficiency in Gimple. RTL only cares about what an expression *means*, ans perhaps

Re: 'posix_spawnp' error in build

On Tue, Dec 26, 2023 at 12:33:40AM +0800, Xi Ruoyao wrote: > On Mon, 2023-12-25 at 10:28 -0600, Segher Boessenkool wrote: > > > 1) git clone git://gcc.gnu.org/git/gcc.git > > > 2) cd gcc & ./contrib/download_prerequisites > > > 3) mkdir objdir & cd objdir &g

Re: 'posix_spawnp' error in build

Hi! On Mon, Dec 25, 2023 at 08:11:23PM +0530, Prashant via Gcc-help wrote: > I'm trying to build the gcc repository. Based on the instructions given on > the SummerOfCode - GCC Wiki (gnu.org) > and GCC for New > Contributors — GCC Contribut

Re: Register allocation cost question

Hi Andrew, On Tue, Oct 10, 2023 at 04:11:18PM +0100, Andrew Stubbs wrote: > I'm also seeing wrong-code bugs when I allow more than 32 new registers, > but that might be an unrelated problem. Or the allocation is broken? I'm > still analyzing this. It could be connected. both things should not

Re: Passing the complex args in the GPR's

Hi! On Tue, Jun 06, 2023 at 08:35:22PM +0530, Umesh Kalappa wrote: > Hi Adnrew, > Thank you for the quick response and for PPC64 too ,we do have > mismatches in ABI b/w complex operations like > https://godbolt.org/z/bjsYovx4c . > > Any reason why GCC chose to use GPR 's here ? What did you expe

Re: More C type errors by default for GCC 14

Hi Florian, On Tue, May 09, 2023 at 08:22:44PM +0200, Florian Weimer via Gcc wrote: > * alleged code generation bugs because the upper 32 bits of a pointer > are set to zero or 0x, resulting in crashes. This can happen > if GCC synthesizes an implicit int declaration for a pointer-ret

Re: POWER __builtin_add_overflow/__builtin_mul_overflow with u64

Hi! On Tue, Feb 14, 2023 at 09:23:55AM +0100, Jakub Jelinek wrote: > CCing Segher and David on this. > rs6000 indeed doesn't implement {,u}{add,sub,mul}v4_optab for > any mode and thus leaves it to the generic code. Yes. Can we do better than the generic code, for those? > On Tue, Feb 14, 2023

Re: LRA produces RTL not meeting constraint

On Wed, Jan 11, 2023 at 07:38:44PM -0500, Paul Koning wrote: > > On Jan 11, 2023, at 2:52 PM, Segher Boessenkool > > wrote: > > On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote: > > Before reload it did not have operands[0] and operands[1] the same, &

Re: LRA produces RTL not meeting constraint

Hi Paul, On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote: > In pdp11.md I have: > > (define_insn_and_split "addhi3" > [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,rR,Q,Q") > (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0") >(match_ope

Re: RFC: Make builtin types only valid for some target features

On Mon, Dec 05, 2022 at 07:31:48AM +, Richard Sandiford wrote: > FWIW, the aarch64 fp move patterns emit the error directly. They then > expand an integer-mode move, to provide some error recovery. (The > alternative would be to make the error fatal.) > > (define_expand "mov" > [(set (matc

Re: --target=powerpc64-linux_altivec: Use rs6000_linux64_override_options()?

On Fri, Oct 28, 2022 at 10:07:41PM +0200, Jan-Benedict Glaw wrote: > On Fri, 2022-10-28 14:19:10 -0500, Segher Boessenkool > wrote: > > Why do you use powerpc64-linux_altivec? This things (normally spelled > > with a dash, not and underscore, btw) was made for 32-bit targets.

Re: --target=powerpc64-linux_altivec: Use rs6000_linux64_override_options()?

Hi! On Fri, Oct 28, 2022 at 07:34:24PM +0200, Jan-Benedict Glaw wrote: > While checking my bot build logs, I noticed that GCC configured for > --target=powerpc64-linux_altivec will pull in linux64.h and > linuxaltivec.h . > > linux64.h > * Will "#define TARGET_USES_LINUX64_OPT 1" (to make stati

Re: DejaGnu: flags via 'RUNTESTFLAGS' overriding those specified in test cases

On Wed, Sep 28, 2022 at 03:12:23PM +0100, Jonathan Wakely wrote: > Which version of Dejagnu are you using? There was a fix in 6.1 or 6.2 > to change the order that the RUNTESTFLAGS and dg-options get added to > the command line. > > It's a pain to make the testsuite work consistently for both old

Re: Floating-point comparisons in the middle-end

On Thu, Sep 01, 2022 at 10:19:59AM +0200, Jakub Jelinek via Gcc wrote: > On Thu, Sep 01, 2022 at 10:04:58AM +0200, FX wrote: > > 2. All the functions are available as GCC type-generic built-ins (yeah!), > > except there is no __builtin_ iseqsig > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=779

Re: Resend: Potential upcoming changes in mangling to PowerPC GCC

On Wed, Aug 10, 2022 at 04:55:42PM -0300, Tulio Magno Quites Machado Filho wrote: > Michael Meissner via Gcc writes: > > Because long double mangles the same as either __float128 or __ibm128, you > > cannot write programs like: > > > > double convert (__ibm128x) { return x; } > > doub

Re: Resend: Potential upcoming changes in mangling to PowerPC GCC

On Mon, Aug 08, 2022 at 05:44:36PM -0400, Michael Meissner wrote: > On Thu, Aug 04, 2022 at 03:53:55PM -0500, Segher Boessenkool wrote: > > On Thu, Aug 04, 2022 at 01:48:51PM -0400, Michael Meissner wrote: > > It would be a lot simpler and less roundabout and inside out if we could

Re: Resend: Potential upcoming changes in mangling to PowerPC GCC

Hi! On Thu, Aug 04, 2022 at 01:48:51PM -0400, Michael Meissner wrote: > At the moment, GCC 12 on the server PowerPC systems supports multiple 128-bit > floating point types: > > * _Float128 (in the C language): IEEE 128-bit floating point; > > * __float128 (in the C and C++ languages): I

Re: [PATCH v2] powerpc: add documentation for HWCAPs

On Fri, Jul 15, 2022 at 03:41:20PM -0300, Tulio Magno Quites Machado Filho wrote: > Nicholas Piggin writes: > > > +PPC_FEATURE_ARCH_2_05 > > +The processor supports the v2.05 userlevel architecture. Processors > > +supporting later architectures also set this feature. > > I don't think

Re: [PATCH v2] powerpc: add documentation for HWCAPs

On Fri, Jul 15, 2022 at 11:26:36AM +1000, Nicholas Piggin wrote: > Take the arm64 HWCAP documentation file and adjust it for powerpc. > > Signed-off-by: Nicholas Piggin Reviewed-by: Segher Boessenkool > +2. Facilities > +- > + > +The Power ISA uses the term &

Re: [PATCH Linux] powerpc: add documentation for HWCAPs

On Fri, Jul 15, 2022 at 11:17:24AM +1000, Nicholas Piggin wrote: > Excerpts from Segher Boessenkool's message of May 25, 2022 4:32 am: > > Linux runs on ISA 1.xx and ISA 2.01 machines still. "Category" wasn't > > invented for either yet either, but similar concepts did exist of > > course. > > No

Re: [PATCH Linux] powerpc: add documentation for HWCAPs

On Tue, May 24, 2022 at 11:52:00AM +0200, Florian Weimer wrote: > * Nicholas Piggin: > > > +2. Facilities > > +- > > +The Power ISA uses the term "facility" to describe a class of instructions, > > +registers, interrupts, etc. The presence or absence of a facility indicates > > +whethe

Re: [PATCH Linux] powerpc: add documentation for HWCAPs

Hi! On Tue, May 24, 2022 at 07:38:28PM +1000, Nicholas Piggin wrote: > Thanks for all the comments and corrections. It should be nearing the > point where it is useful now. Yes I do think it would be useful to align > this more with OpenPOWER docs (and possibly eventually move it into the > ABI, g

Re: [RFC Linux patch] powerpc: add documentation for HWCAPs

On Fri, May 20, 2022 at 09:21:43AM -0500, Paul E Murphy wrote: > >+PPC_FEATURE_HAS_ALTIVEC > >+Vector (aka Altivec, VSX) facility is available. > > I think "(aka Altivec, VSX)" might be more accurately stated as "(aka > Altivec)"? "Also known as AltiVec or VMX", yes. > >+PPC_FEATURE_HAS_DFP

Re: [RFC] Adding division/modulo on arbitrary precision integers to libgcc

Hi! On Fri, May 06, 2022 at 02:09:21PM +, Matthias Gehre via Gcc wrote: > We would like to add support for division/modulo on large arbitrary precision  > integers to libgcc/compiler-rt > as required by C23's _BitInt type [0]. > > >From what I know, gcc doesn't yet support C23 _BitInt, but we

Re: [power-iee128] How to specify linker flags

Hi! On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote: > One additional point. The linker does not understand > -mno-gnu-attribute: That is a GCC option, not an ld one. If you use it to compile some file there will be no .gnu.attributes section generated for that translation unit.

Re: [PATCH] Bump required minimum DejaGnu version to 1.5.3

On Thu, Nov 04, 2021 at 01:22:24PM +0100, Martin Liška wrote: > On 11/4/21 12:55, Segher Boessenkool wrote: > >On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches > >wrote: > >>On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer vi

Re: [PATCH] Bump required minimum DejaGnu version to 1.5.3

On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches wrote: > On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via > Gcc-patches wrote: > > > > From: Bernhard Reutner-Fischer > > > > Bump required DejaGnu version to 1.5.3 (or later). > > Ok for trunk? > > OK. If we r

Re: __builtin_addc support??

On Wed, Oct 27, 2021 at 04:12:27PM +, sotrdg sotrdg via Gcc-help wrote: > 79173 – add-with-carry and subtract-with-borrow support (x86_64 and others) > (gnu.org) > > What I find quite interesting is things like this. > > Since llvm clang pr

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

Thank you for writing this out Bill! On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote: > Longer term, we have the question of supporting more Power targets. AIX will > continue to > use only double-double. Yes. So it will be virtually no cost to continue supporting double-double on

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Fri, Oct 15, 2021 at 04:20:49PM +0200, Jakub Jelinek wrote: > If we do implement double-double support, I think KIND=15 would be better > than KIND=17, it is true that double-double has for certain numbers much > higher precision than IEEE quad, but the precision depends on the numbers > and mos

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Thu, Oct 14, 2021 at 02:39:47PM -0500, Bill Schmidt wrote: > On 10/5/21 12:43 PM, Segher Boessenkool wrote: > > The last release (version 1.9) was in 2004. If there is interest in > > making updates to it that coulde be done of course, it is GFDL, there is > > no red ta

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

Hi! On Mon, Oct 11, 2021 at 08:11:50PM +, Joseph Myers wrote: > On Fri, 8 Oct 2021, Segher Boessenkool wrote: > > But many CPUs do not have hardware floating point in any variant, and > > their ABIs / calling conventions do not mention floating point at all. > > Still

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 11:42:11PM -0400, Michael Meissner wrote: > On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote: > > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > > > On 05.10.21 23:54, Segher Boessenkool wrote: > > > >>

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 10:03:59PM +, Joseph Myers wrote: > On Wed, 6 Oct 2021, Segher Boessenkool wrote: > > With "not in any" I mean: not for other architectures either! All archs > > that do not say anything about floating point in their machine > > de

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 07:42:31PM +, Joseph Myers wrote: > On Wed, 6 Oct 2021, Segher Boessenkool wrote: > > Soft float is not described in any formal ABI btw (well, except the > > Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair. > > It's fully

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 05:13:59PM +, Joseph Myers wrote: > On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote: > > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > > We can emulate it everywhere (using libquadmath for example). This can > > >

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 07:07:43PM +0200, Jakub Jelinek wrote: > On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote: > > On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote: > > > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: >

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote: > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > We can emulate it everywhere (using libquadmath for example). This can > > magically make -msoft-float work as well everywhere, btw. > > E

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 11:42:17AM -0400, David Edelsohn wrote: > On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool > wrote: > > > > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > > > On 05.10.21 23:54, Segher Boessenkool wrote: > > > >

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 05:41:07PM +0200, Jakub Jelinek wrote: > On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote: > > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > > > >That means flipping the default on all PowerPC to no longer be double-

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > On 05.10.21 23:54, Segher Boessenkool wrote: > >>There is also the issue of binary data. If some user has written > >>out data in double double and wants to read it in as IEEE quad, > >>the results are

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

Hi! On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote: > On 04.10.21 16:14, Jakub Jelinek via Fortran wrote: > >Based on some IRC discussion, yet another option would be bump libgfortran > >SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean > >always IEEE quad (starti

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

Hi Joseph, On Mon, Oct 04, 2021 at 07:24:31PM +, Joseph Myers wrote: > On Mon, 4 Oct 2021, Segher Boessenkool wrote: > > Some current Power GCC targets support neither. Some support only > > double-double. Making IEEE QP float work on those (that is, those that > &g

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

Hi! On Mon, Oct 04, 2021 at 04:14:10PM +0200, Jakub Jelinek wrote: > Based on some IRC discussion, yet another option would be bump libgfortran > SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean > always IEEE quad (starting with GCC 12) and if wanted add support for > real(kind

Re: [RFC] Adding a new attribute to function param to mark it as constant

On Thu, Aug 05, 2021 at 02:31:02PM +0530, Prathamesh Kulkarni wrote: > On Wed, 4 Aug 2021 at 18:30, Richard Earnshaw > wrote: > > We don't want to have to resort to macros. Not least because at some > > point we want to replace the content of arm_neon.h with a single #pragma > > directive to remo

Re: [RFC] Adding a new attribute to function param to mark it as constant

On Wed, Aug 04, 2021 at 07:08:08PM +0200, Florian Weimer wrote: > * Segher Boessenkool: > > > On Wed, Aug 04, 2021 at 03:27:00PM +0100, Richard Earnshaw wrote: > >> On 04/08/2021 14:40, Segher Boessenkool wrote: > >> >On Wed, Aug 04, 2021 at 02:00:42PM +0100,

Re: [RFC] Adding a new attribute to function param to mark it as constant

On Wed, Aug 04, 2021 at 03:27:00PM +0100, Richard Earnshaw wrote: > On 04/08/2021 14:40, Segher Boessenkool wrote: > >On Wed, Aug 04, 2021 at 02:00:42PM +0100, Richard Earnshaw wrote: > >>We don't want to have to resort to macros. Not least because at some > >>poin

Re: [RFC] Adding a new attribute to function param to mark it as constant

On Wed, Aug 04, 2021 at 02:00:42PM +0100, Richard Earnshaw wrote: > We don't want to have to resort to macros. Not least because at some > point we want to replace the content of arm_neon.h with a single #pragma > directive to remove all the parsing of the header that's needed. What's > more, if

Re: [RFC] Adding a new attribute to function param to mark it as constant

On Wed, Aug 04, 2021 at 05:20:58PM +0530, Prathamesh Kulkarni wrote: > On Wed, 4 Aug 2021 at 15:49, Segher Boessenkool > wrote: > > Both __builtin_constant_p and __is_constexpr will not work in your use > > case (since a function argument is not a constant, let alone an ICE). &

Re: [RFC] Adding a new attribute to function param to mark it as constant

On Wed, Aug 04, 2021 at 03:20:45PM +0530, Prathamesh Kulkarni wrote: > On Wed, 4 Aug 2021 at 03:27, Segher Boessenkool > wrote: > > The Linux kernel has a macro __is_constexpr to test if something is an > > integer constant expression, see . That is a much > > better ide

Re: Failures building glibc with mainline GCC

Off-topic... On Tue, Aug 03, 2021 at 09:00:20PM +, Joseph Myers wrote: > On Tue, 3 Aug 2021, Segher Boessenkool wrote: > > But you do have a cfarm account :-) > > And build-many-glibcs.py is designed to be self-contained [ snip ] Yes, it's great :-) > which will ch

Re: [RFC] Adding a new attribute to function param to mark it as constant

Hi! On Fri, Jul 23, 2021 at 04:23:42PM +0530, Prathamesh Kulkarni via Gcc wrote: > The constraint here is that, vshl_n intrinsics require that the > second arg (__b), > should be an immediate value. Something that matches the "n" constraint, not necessarily a literal, but stricter than just "imme

Re: Failures building glibc with mainline GCC

On Tue, Aug 03, 2021 at 10:20:49AM -0600, Martin Sebor via Gcc wrote: > On 8/3/21 9:54 AM, Joseph Myers wrote: > >As discussed, this is a bug indicating that the code generating that > >warning fails to check targetm.addr_space.zero_address_valid to determine > >whether zero or small constant addre

Re: Named address spaces on x86 GNU/Linux

On Thu, Jul 29, 2021 at 04:08:36PM +, Joseph Myers wrote: > On Thu, 29 Jul 2021, Florian Weimer via Gcc wrote: > > On GNU/Linux, SEGFS is used to implement the thread pointer, to avoid > > dedicating a general-purpose register to it. At address zero with the > > SEGFS prefix, the offset itself

Re: [Questions] Is there any bit in gimple/rtl to indicate this IR support fast-math or not?

On Wed, Jul 14, 2021 at 09:39:42AM +0200, Richard Biener via Gcc-help wrote: > On Wed, Jul 14, 2021 at 9:00 AM Hongtao Liu via Gcc-patches > wrote: > > > > On Wed, Jul 14, 2021 at 2:39 PM Matthias Kretz wrote: > > > > > > On Wednesday, 14 July 2021 07:18:29 CEST Hongtao Liu via Gcc-help wrote: >

Re: Unit Type for Rust

On Mon, Jun 28, 2021 at 02:51:22PM +0100, Philip Herron wrote: > On 28/06/2021 14:49, Philip Herron wrote: > > In Rust the language has the notion of the unit type '()', so for example: > > > >  fn foo ->i32 { ... } > >  fn bar() { ... } > > > > Foo has the return type i32, and bar has no return ty

Re: [RFC] Implementing detection of saturation and rounding arithmetic

On Wed, May 12, 2021 at 09:13:38AM +, Tamar Christina wrote: > > From: Segher Boessenkool > > On Tue, May 11, 2021 at 05:37:34AM +, Tamar Christina via Gcc wrote: > > > 2. Saturating abs: > > >char sat (char a) > > >{ > > >

Re: Speed of compiling gimple-match.c

On Wed, May 12, 2021 at 10:19:17AM +0200, Richard Biener wrote: > On Tue, May 11, 2021 at 5:01 PM Segher Boessenkool > wrote: > > > > On Tue, May 04, 2021 at 10:40:38AM +0200, Richard Biener via Gcc wrote: > > > On Mon, May 3, 2021 at 11:10 PM Andrew Pinski via Gcc

Re: [RFC] Implementing detection of saturation and rounding arithmetic

Hi! On Tue, May 11, 2021 at 05:37:34AM +, Tamar Christina via Gcc wrote: > 2. Saturating abs: >char sat (char a) >{ > int tmp = abs (a); > return tmp > 127 ? 127 : ((tmp < -128) ? -128 : tmp); >} That can be done quite a bit better, branchless at least. Same for all e

Re: Speed of compiling gimple-match.c

On Tue, May 04, 2021 at 10:40:38AM +0200, Richard Biener via Gcc wrote: > On Mon, May 3, 2021 at 11:10 PM Andrew Pinski via Gcc wrote: > > I noticed my (highly, -j24) parallel build of GCC is serialized on > > compiling gimple-match.c. Has anyone looked into splitting this > > generated file in

Re: Should GCC provide __builtin_memcpy_inline like clang does?

On Tue, Jan 19, 2021 at 11:33:56AM +, unlvsur unlvsur via Gcc-help wrote: > I think __builtin_memmove_inline, __builtin_memset_inline can also get > provided. > > That allows better performance for small size copies You normally will get better performance by letting the compiler figure out

Re: More consistency for Git log messages?

On Tue, Dec 29, 2020 at 12:54:53AM +0100, Gerald Pfeifer wrote: > Having spent a bit more time with GCC sources (as opposed to wwwdocs) > recently and looking for prior art to guide me, I noticed there's a > lot of options to specific the ChangeLog file(s) to use. > > And correspondingly a lot o

CC0 removal branch

Hi! I have updated my CC0 removal branch I started in 2019: refs/users/segher/heads/cc0 (yes I know this needs some patch series work; this branch rebases). I have tested it all on powerpc*, and sill test it with cross-compilers to all Linux targets later today. I already know one problem that

Re: The conditions when convert from double to float is permitted?

On Fri, Dec 11, 2020 at 05:38:30PM +0800, Xionghu Luo wrote: > On 2020/12/11 15:47, Richard Biener wrote: > >> Note that the add/sub sequence is different for (3) and (4) since > >> -funsafe-math-optimizations is implicitly true. "fp-contract=fast" in > >> (1) and (2) could avoid Inf as fmads coul

Re: The conditions when convert from double to float is permitted?

On Fri, Dec 11, 2020 at 03:54:44PM +0800, Xionghu Luo wrote: > +cc. > > > On 2020/12/11 14:25, Xionghu Luo via Gcc wrote: > >Thanks, > > > >On 2020/12/10 17:12, Richard Biener wrote: > >>>2) From PR90070: > >>> > >>>double temp1 = (double)r->red; > >>>double temp2 = (double)aggregate.red;

Re: CSE deletes valid REG_EQUAL?

Hi guys, On Thu, Nov 12, 2020 at 09:10:14PM -0700, Jeff Law wrote: > On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote: > > The output shows "REQ_EQUAL r118:DI+0x66546b64" is deleted by > > df_remove_dead_eq_notes, > > but r120:DI is not REG_DEAD here, so is it correct here to check insn use > > an

Re: typeof and operands in named address spaces

On Tue, Nov 10, 2020 at 08:57:42AM +0100, Peter Zijlstra wrote: > On Mon, Nov 09, 2020 at 11:50:15AM -0800, Nick Desaulniers wrote: > > On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool > > wrote: > > > On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote: >

Re: typeof and operands in named address spaces

On Tue, Nov 10, 2020 at 09:11:08PM +0100, Peter Zijlstra wrote: > On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote: > > When I think of qualifiers, I think of const and volatile. I'm not > > sure why the first post I'm cc'ed on talks about "segment" qualifiers. > > Maybe it's in re

Re: typeof and operands in named address spaces

On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote: > > + lots of people and linux-toolchains > > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote: > > Hello! > > > > I was looking at the recent linux patch series [1] where segment > > qualifiers (named address spaces) wer

Re: First set of patches to allow changing the long double default were posted:

Hi! On Wed, Oct 07, 2020 at 08:00:49PM -0400, Michael Meissner wrote: > I looked into this a bit, and I think we want to keep the current behavior (as > modified by the patches). As Joseph says, the _Float types have their own > types, but may/may not use the same modes as other types. Obviously

Re: Wrong optimization from ‘fwprop’ pass

Hi! On Wed, Sep 23, 2020 at 10:50:52AM +0800, Jojo R wrote: > insn seqs: > > s1: > > __builtin_set_float_convert_mode(0); > r1 = __builtin_load(a1, a2); > r2 = __builtin_float_convert(r1); > __builtin_store(a3, r2); > __builtin_set_float_convert_mode(0); > > s2: >

Re: A problem with one instruction multiple latencies and pipelines

On Mon, Sep 14, 2020 at 08:35:44PM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > >> Although this looks/sounds complicated, the advantage is that everything > >> remains up-to-date. If we instead added a second attribute and only > >> defined i

Re: A problem with one instruction multiple latencies and pipelines

Hi! On Mon, Sep 14, 2020 at 10:55:35AM +0100, Richard Sandiford wrote: > "Qian, Jianhua" writes: > > - If we cannot resolve it, the existing CPUs' descriptions need > > to be changed. This is not what I expected. > > - If we want to add new attribute to resolve this probl

Re: A problem with one instruction multiple latencies and pipelines

Hi! On Fri, Sep 11, 2020 at 08:44:54AM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > Consider cores that do not care about the "subtype" at all: when using > > just "type", all cores have to test for "foo,foo_subtype", while with &g

Re: A problem with one instruction multiple latencies and pipelines

On Thu, Sep 10, 2020 at 11:04:26AM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > You can also use some other attributes to classify instructions, you > > don't have to put it all in one "type" attribute. This can of course be > > done later,

Re: subreg vs vec_select

Hi! On Thu, Sep 10, 2020 at 12:21:47PM +0200, Ilya Leoshkevich wrote: > On Wed, 2020-09-09 at 16:09 -0500, Segher Boessenkool wrote: > > On Wed, Sep 09, 2020 at 11:50:56AM +0200, Ilya Leoshkevich via Gcc > > wrote: > > > I have a vector pseudo containing a single

Re: A problem with one instruction multiple latencies and pipelines

Hi! On Mon, Sep 07, 2020 at 09:20:59PM +0100, Richard Sandiford wrote: > This is just personal opinion, but in general (from the point of view > of a new port, or a new subport like SVE), I think the best approach > to handling the "type" attribute is to start with the coarsest > classification th

Re: subreg vs vec_select

Hi Ilya, On Wed, Sep 09, 2020 at 11:50:56AM +0200, Ilya Leoshkevich via Gcc wrote: > I have a vector pseudo containing a single 128-bit value (V1TFmode) and > I need to access its last 64 bits (DFmode). Which of the two options > is better? > > (subreg:DF (reg:V1TF) 8) > > or > > (vec_select:DF

Re: PowerPC long double Mangling

On Wed, Sep 09, 2020 at 07:41:02PM +0200, Jakub Jelinek wrote: > On Wed, Sep 09, 2020 at 12:32:22PM -0500, Segher Boessenkool wrote: > > On Wed, Sep 09, 2020 at 07:06:41PM +0200, Thomas Koenig wrote: > > > Am 09.09.20 um 17:36 schrieb Segher Boessenkool: > > > >

Re: PowerPC long double Mangling

On Wed, Sep 09, 2020 at 07:06:41PM +0200, Thomas Koenig wrote: > Am 09.09.20 um 17:36 schrieb Segher Boessenkool: > >You can use both __ibm128 and __ieee128 in one program, so it isn't an > >ABI change. Only the default of what "long double" means changes. And >

Re: PowerPC long double Mangling

Hi! On Wed, Sep 09, 2020 at 02:42:36PM +0100, Jonathan Wakely wrote: > On Fri, 7 Aug 2020 at 22:14, Michael Meissner wrote: > > But assuming we want compatibility with libraries like glibc and libstdc++, > > I > > think we will have to continue to use "g" for __ibm128. Yes. > > With the long d

Re: Clobber REG_CC only for some constraint alternatives?

Hi! On Sun, Aug 16, 2020 at 06:28:44PM +, Pip Cet wrote: > > > IIUC, the idea is that references to REG_CC, except for clobbers, are > > > only introduced in the post-reload split pass, so it cannot be live > > > before our define_split runs. Does that make sense? > > > > Yes, it does. It has

Re: Clobber REG_CC only for some constraint alternatives?

On Sat, Aug 15, 2020 at 10:18:27AM +, Pip Cet wrote: > > > What I'm currently doing is this: > > > > > > (define_split > > > [(set (match_operand 0 "nonimmediate_operand") > > > (match_operand 1 "nox_general_operand"))] > > > "reload_completed && mov_clobbers_cc (insn, operands)" > > >

Re: Clobber REG_CC only for some constraint alternatives?

Hi! On Fri, Aug 14, 2020 at 05:47:02PM +, Pip Cet wrote: > On Fri, Aug 14, 2020 at 4:24 PM Segher Boessenkool > wrote: > > On Fri, Aug 14, 2020 at 04:46:59PM +0530, Senthil Kumar Selvaraj via Gcc > > wrote: > > > (define_insn "*mov_insn_noclobber_flags"

Re: Clobber REG_CC only for some constraint alternatives?

Hi! On Fri, Aug 14, 2020 at 04:46:59PM +0530, Senthil Kumar Selvaraj via Gcc wrote: > I'm working on porting AVR to MODE_CC, I'm very happy to see people work on that. > (define_insn "*mov_insn_noclobber_flags" > [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d ,q,r") > (ma

Re: Silly question about pass numbers

Hi! On Wed, Aug 12, 2020 at 08:26:34PM +, Gary Oblock wrote: > The files are from the same run: > -rw-rw-r-- 1 gary gary 3855 Aug 12 12:49 exe.ltrans0.ltrans.074i.cp > -rw-rw-r-- 1 gary gary 16747 Aug 12 12:49 > exe.ltrans0.ltrans.087i.structure-reorg > > By the time .cp was created inlinin

Re: Silly question about pass numbers

On Tue, Aug 11, 2020 at 08:27:29PM +, Gary Oblock via Gcc wrote: > For these two dump files: > > exe.ltrans0.ltrans.074i.cp > > and > > exe.ltrans0.ltrans.087i.structure-reorg > > doesn't the ".074i." mean that this dump was created > before the ".087i." dump? It means that the 074 pass is

Re: Problem with 64-bit only compiler build

On Tue, Aug 11, 2020 at 08:01:55PM -0400, Paul Smith wrote: > This is a kind of esoteric problem, but all the more annoying for that. :-) > As usual I've built my own version of GCC, and then I check it into Git > so that all builds can use this one canonical compiler regardless of > operating sy

Re: documentation of powerpc64{,le}-linux-gnu as primary platform

On Thu, Jul 09, 2020 at 08:18:56PM -0500, Bill Schmidt via Gcc wrote: > >>>No, I don't leave this alone. The little endian target is dropped in > >>GCC 9 and > >>>GCC 10. Is this really what you intended to do? > >>No, it's not dropped. Some people are being pedantic about the name, > >>which is

Re: Push to my private branches is disallowed

Hi! On Tue, Jun 16, 2020 at 02:09:37PM +0100, Jonathan Wakely wrote: > I see no harm in rebasing public branches as long as nobody expects > otherwise. A public branch on gcc.gnu.org under refs/heads that is > being pulled by unknown persons and used in unknown forks for unknown > purposes shouldn

Re: Push to my private branches is disallowed

On Tue, Jun 16, 2020 at 02:54:13PM +, Joseph Myers wrote: > On Tue, 16 Jun 2020, Jonathan Wakely via Gcc wrote: > > > I see no harm in rebasing public branches as long as nobody expects > > otherwise. > > And by design you *can* rebase user and vendor branches (but not those in > other names

Re: Push to my private branches is disallowed

Hi! On Tue, Jun 16, 2020 at 11:11:01AM +0200, Martin Jambor wrote: > On Mon, Jun 15 2020, Segher Boessenkool wrote: > > What. > > > > Of course it is not a fast-forward. I rebase the branches I publish, > > what is the point of publishing them otherwise? This is so

Re: Push to my private branches is disallowed

On Mon, Jun 15, 2020 at 09:17:43PM +0200, Richard Biener wrote: > On June 15, 2020 7:19:13 PM GMT+02:00, Joseph Myers > wrote: > >I don't know if deleting and then recreating a user branch (in separate > > > >pushes) avoids the limit (and the excess mails) in the case where a > >user > >branch i

Re: Push to my private branches is disallowed

On Mon, Jun 15, 2020 at 10:47:48AM -0700, H.J. Lu wrote: > These are all the reasons why I don't use GCC repo for my personal > branches. Yeah, but I thought a lot of different GCC people might be interested in my "nuke CC0" patches, so putting it in the official repo seemed like a good idea, for

Re: Push to my private branches is disallowed

Hi Joseph, Thanks, good to hear things will get better. On Mon, Jun 15, 2020 at 05:19:13PM +, Joseph Myers wrote: > > It should never send email for user branches *at all*. > > I think sending email for all branches showing the development taking > place there (as opposed to commits that ar

Re: Push to my private branches is disallowed

On Mon, Jun 15, 2020 at 06:41:02PM +0200, Andreas Schwab wrote: > On Jun 15 2020, Segher Boessenkool wrote: > > > On Mon, Jun 15, 2020 at 06:28:39PM +0200, Richard Biener wrote: > >> On June 15, 2020 6:05:26 PM GMT+02:00, Segher Boessenkool > >> wrote: > >&

Re: Push to my private branches is disallowed

On Mon, Jun 15, 2020 at 06:28:39PM +0200, Richard Biener wrote: > On June 15, 2020 6:05:26 PM GMT+02:00, Segher Boessenkool > wrote: > >Of course it is not a fast-forward. I rebase the branches I publish, > >what is the point of publishing them otherwise? This is so that peo

Push to my private branches is disallowed

Hi! $ git push -n fsf To git+ssh://gcc.gnu.org/git/gcc.git + 1db88c6...71e5e35 cc0 -> refs/users/segher/heads/cc0 (forced update) $ git push fsf Counting objects: 664, done. Delta compression using up to 64 threads. Compressing objects: 100% (239/239), done. Writing objects: 100% (504/504), 87.7

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi Arseny, On Mon, Jun 01, 2020 at 10:38:16AM +0700, Arseny Solokha wrote: > > PRs from the second group were filed by me, so if there's consensus to > > close all > > of them, the ones from this second group I can close myself. I don't > > have the > > right permissions to m

Re: [IMPORTANT] ChangeLog related changes

On Tue, May 26, 2020 at 03:14:02PM +0200, Andreas Schwab wrote: > On Mai 26 2020, Martin Liška wrote: > > > subprocess.check_output('git show --name-only --pretty="" | ' > > 'grep ChangeLog | ' > > git show --name-only --pretty= -- '*ChangeLog*' Or even ju

  1   2   3   4   5   6   7   >