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

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

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

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

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

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

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

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

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

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

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: 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: 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: --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: --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: 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: 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: 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: 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: 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: 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: 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: '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: '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: [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: If you had a month to improve gcc build parallelization, where would you begin?

How does that work? The binaries have to get the all the machines of the clusters somewhere. Does this assume you are using NFS or similar for your build directory? Won't the overhead of using that instead of local disk kill most of the parallelization benefit of a cluster over a single SMP

Re: wrong assertion in caller-save.c

> I think I found a bug in gcc 4.7.3 in gcc/caller-save.c at line 158 : > > gcc_assert (cached_reg_save_code[reg][mode]); > > should be : > > gcc_assert (cached_reg_save_code[reg][mode] != -1); > > because cached_reg_save_code contains INSN_CODES that can be equal to 0 This is PR55036.

Re: Memory outputs in inline asm

FWIW: > __asm__("\t0:\n" > "\tstr wzr, [%2, #4]!\n" > "\tsub %1, %1, #1\n" > "\tcbnz %1, 0b\n" > : "=m"(*p), "+r"(len) : "r"(p)); "+r"(p) as well, you're modifying %2. Cheers, Segher

Re: Double word left shift optimisation

Hi Jon, I'd like to try to optimise double word left shifts of sign/zero extended operands if a widening multiply instruction is available. For the following code: long long f(long a, long b) { return (long long)a << b; } I'd like to optimise this to something like: (long long) a * (

Re: [PATCH] rs6000: Disable generation of lwa in 32-bit mode

some (20040709-2.c, etc.) fail with a linker error now, instead of Hmm, packed structs. If gcc is generating mis-aligned accesses using lwa or ld, that would be another TARGET_64BIT vs TARGET_POWERPC64 bug, wouldn't it? I have analysed it, patch on the way. The problem is LO_SUMs of misalign

atomic accesses

The Linux kernel, and probably some user-space applications and libraries as well, depend on GCC guaranteeing (a variant of) the following: "any access to a naturally aligned scalar object in memory that is not a bit-field will be performed by a single machine instruction

Re: atomic accesses

This seems somewhat like other issues we have dealt with concerning thread safety. Perhaps an entire section addressing code generation issues related to correct multi-threaded semantics. I like that idea. But, we need to decide what those correct semantics _are_. Or we can wait for that to

Re: atomic accesses

The Linux kernel, and probably some user-space applications and libraries as well, depend on GCC guaranteeing (a variant of) the following: "any access to a naturally aligned scalar object in memory that is not a bit-field will be performed by a single machine instruction

Re: atomic accesses

The Linux kernel, and probably some user-space applications and libraries as well, depend on GCC guaranteeing (a variant of) the following: "any access to a naturally aligned scalar object in memory that is not a bit-field will be performed by a single machine instruction

Re: atomic accesses

The Linux kernel, and probably some user-space applications and libraries as well, depend on GCC guaranteeing (a variant of) the following: "any access to a naturally aligned scalar object in memory that is not a bit-field will be performed by a single machine instruction

Re: atomic accesses

As I said before, I think any words of this form SHOULD NOT be added. All it does is add words to the documentation that provide NO guarantee of anything -- but in a way that will confuse those who don't read it carefully enough into thinking that they DID get some sort of guarantee. The idea is

Re: No warning for unreachable code

I just discovered a behaviour in gcc-4, which I don't understand: code unsigned int x; if (x < 0) do_something(); compiled with -Wall doesn't produce a warning, and the call to do_something() is silently dropped, whereas if x is of type unsigned char, I get as

Re: No warning for unreachable code

I'm suggesting that there's no big difference between unsigned char and unsigned int (and unsigned long...) in this case, and, therefore compiler's behaviour should be consistent. But there is a difference. When "x" is an unsigned int, the expression "x < 0" is equivalent to (unsigned i

Re: paranoia on PowerPC

Given the age of paranoia (the version included with RTEMS is from Cygnus circa 1993), does this sound familiar or is this a new issue? What happens if you use -mno-fused-madd option? Same result for me using RTEMS on psim. Eric N. will have to give a Mac report. I tested it (the source fro

Re: RFC: Simplify rules for ctz/clz patterns and RTL

* I would like to do the same for __builtin_ctz, but there is a catch. The synthetic ctz sequence in terms of popcount (as presently implemented by ia64.md, and potentially usable for at least i386 and rs6000 as well if moved to optabs.c) produces the canonical behavior at zero, but the synthetic

Re: RFC: Simplify rules for ctz/clz patterns and RTL

I suppose you're using (assuming 32-bit) ctz(x) := 31 - clz(x & -x) now, which gives -1 for 0; and the version you're looking for is ctz(x) := 32 - clz(~x & (x-1)) which gives 32 for 0. (Straight from the venerable PowerPC Compiler Writer's Guide, btw). What does the popcount

Re: RFC: Simplify rules for ctz/clz patterns and RTL

I suppose you're using (assuming 32-bit) ctz(x) := 31 - clz(x & -x) now, which gives -1 for 0; and the version you're looking for is ctz(x) := 32 - clz(~x & (x-1)) which gives 32 for 0. Thanks! That's, unfortunately, one more instruction, although I guess a lot of chips have "a & ~b" a

Re: RFC: Simplify rules for ctz/clz patterns and RTL

I think the cost would be something like: +case POPCOUNT: + *total = COSTS_N_INSNS (3); + return false; Is that the cost when using popcountb? It is a lot more expensive when that instruction isn't available (like on most current machines). The rest (i.e. CLZ, CTZ) loo

Re: RFC: Simplify rules for ctz/clz patterns and RTL

I think the cost would be something like: +case POPCOUNT: + *total = COSTS_N_INSNS (3); + return false; Segher> Is that the cost when using popcountb? It is a lot more Segher> expensive when that instruction isn't available (like on Segher> most current machines). Yes, bu

Re: Why is building a cross compiler "out-of-the-box" always broken?

So, my open questions to the list are, what is/should be the preferred way to bootstrap a cross compiler/glibc environment? This likely isn't the preferred way, but the following builds a cross toolchain for all but a few Linux targets: $SRC/src/configure \ --target=$TARGET --prefix=$P

Re: Why is building a cross compiler "out-of-the-box" always broken?

4. Use the minimal cross-compiler produced in step 3 to configure glibc and do "make install-headers" to get glibc headers. At this point you should be able to delete the minimal cross-compiler, it's job has been done. 5. Make distclean and then configure, make, and install a normal gcc cross

Re: Why is building a cross compiler "out-of-the-box" always broken?

Thanks, I git cloned buildall and it sure looks simple (now that you have made it work) :-! Good to see it is useful to more people than just me :-) Although, that combination of options was not exactly obvious at first glance. Heh. Almost all of it is just "disable what we don't need". OT

Fwd: Re: Why is building a cross compiler "out-of-the-box" always broken?

(Stephen typoed the gcc address, forwarding) From: Segher Boessenkool <[EMAIL PROTECTED]> Date: 21 augustus 2007 17:10:30 GMT+02:00 To: "Stephen M. Kenton" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Why is building a cross compiler "out-of-the-box&qu

Re: Why is LIMITS_H_TEST defined in cris/t-linux? It caused cross-compiler build errors

Segher - If remember right, cris was one of the targets that did not build for you. This might help. No idea if it would help or not -- it currently dies with an ICE while building __mulvdi3: /home/segher/src/gcc/libgcc/../gcc/libgcc2.c: In function '__mulvdi3': /home/segher/src/gcc/libgcc/../g

[PATCH PR31490] Re: another build failure on ppc64-linux

Bootstrap of current trunk on powerpc64-linux fails in libstdc++ building system_error.lo. The code that fails was added a few days ago, but the failure seems to be the same as the one reported in PR 31490. I verified that the patch from comment #10 of that PR allows bootstrap of c,c++,fortra

Re: Register allocation issues

load r3, q + 0 load r4, q + 4 store r3, p + 0 store r4, p + 4 load r3, q + 4 load r4, q + 8 store r3, p + 4 store r4, p + 8 These last four lines should be load r3, q + 8 load r4, q + 12 store r3, p + 8 store r4, p + 12 Did you just typo it or do you have a big

<    2   3   4   5   6   7