Re: [PATCH] Cleanup: Replace UNSPEC_COPYSIGN with copysign RTL
On Fri, Sep 29, 2023 at 2:09 PM Michael Meissner
wrote:
> When I first implemented COPYSIGN support in the power7 days, we did not
> have a
> copysign RTL insn, so I had to use UNSPEC to represent the copysign
> instruction. This patch removes those UNSPECs, and it uses the native RTL
> copysign insn.
>
> I have tested this on both big endian and little endian PowerPC server
> systems,
> and there were no regressions. Can I check this into the master branch?
> Since
> it is just a clean-up, I don't see the need to back port it, but it is
> simple
> to do the back port if desired.
>
> 2023-09-29 Michael Meissner
>
> gcc/
>
> * config/rs6000/rs6000.md (UNSPEC_COPYSIGN): Delete.
> (copysign3_fcpsg): Use copysign RTL instead of UNSPEC.
> (copysign3_hard): Likewise.
> (copysign3_soft): Likewise.
> * config/rs6000/vector.md (vector_copysign3): Use copysign
> RTL
> instead of UNSPEC.
> * config/rs6000/vsx.md (vsx_copysign3): Use copysign RTL
> instead
> of UNSPEC.
> ---
> gcc/config/rs6000/rs6000.md | 20
> gcc/config/rs6000/vector.md | 4 ++--
> gcc/config/rs6000/vsx.md| 7 +++
> 3 files changed, 13 insertions(+), 18 deletions(-)
>
> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index 7b583d7a69a..1b6b6cb5bbe 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -108,7 +108,6 @@ (define_c_enum "unspec"
> UNSPEC_TOCREL
> UNSPEC_MACHOPIC_OFFSET
> UNSPEC_BPERM
> - UNSPEC_COPYSIGN
> UNSPEC_PARITY
> UNSPEC_CMPB
> UNSPEC_FCTIW
> @@ -5383,9 +5382,8 @@ (define_expand "copysign3"
> ;; compiler from optimizing -0.0
>
The comment above the define_insn refers to UNSPEC instead of if-then-else
because of -0.0.
Please remove or update the comment because the pattern no longer uses
UNSPEC.
The rest of the patch is okay with that change.
Thanks, David
> (define_insn "copysign3_fcpsgn"
>[(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
> - (unspec:SFDF [(match_operand:SFDF 1 "gpc_reg_operand" "d,wa")
> - (match_operand:SFDF 2 "gpc_reg_operand" "d,wa")]
> -UNSPEC_COPYSIGN))]
> + (copysign:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "d,wa")
> + (match_operand:SFDF 2 "gpc_reg_operand" "d,wa")))]
>"TARGET_HARD_FLOAT && (TARGET_CMPB || VECTOR_UNIT_VSX_P (mode))"
>"@
> fcpsgn %0,%2,%1
> @@ -14984,10 +14982,9 @@ (define_expand "copysign3"
>
> (define_insn "copysign3_hard"
>[(set (match_operand:IEEE128 0 "altivec_register_operand" "=v")
> - (unspec:IEEE128
> -[(match_operand:IEEE128 1 "altivec_register_operand" "v")
> - (match_operand:IEEE128 2 "altivec_register_operand" "v")]
> -UNSPEC_COPYSIGN))]
> + (copysign:IEEE128
> +(match_operand:IEEE128 1 "altivec_register_operand" "v")
> +(match_operand:IEEE128 2 "altivec_register_operand" "v")))]
>"TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode)"
> "xscpsgnqp %0,%2,%1"
>[(set_attr "type" "vecmove")
> @@ -14995,10 +14992,9 @@ (define_insn "copysign3_hard"
>
> (define_insn "copysign3_soft"
>[(set (match_operand:IEEE128 0 "altivec_register_operand" "=v")
> - (unspec:IEEE128
> -[(match_operand:IEEE128 1 "altivec_register_operand" "v")
> - (match_operand:IEEE128 2 "altivec_register_operand" "v")]
> -UNSPEC_COPYSIGN))
> + (copysign:IEEE128
> +(match_operand:IEEE128 1 "altivec_register_operand" "v")
> +(match_operand:IEEE128 2 "altivec_register_operand" "v")))
> (clobber (match_scratch:IEEE128 3 "=&v"))]
>"!TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode)"
> "xscpsgndp %x3,%x2,%x1\;xxpermdi %x0,%x3,%x1,1"
> diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
> index 1ae04c8e0a8..f4fc620b653 100644
> --- a/gcc/config/rs6000/vector.md
> +++ b/gcc/config/rs6000/vector.md
> @@ -332,8 +332,8 @@ (define_expand "vector_btrunc2"
>
> (define_expand "vector_copysign3"
>[(set (match_operand:VEC_F 0 "vfloat_operand")
> - (unspec:VEC_F [(match_operand:VEC_F 1 "vfloat_operand")
> - (match_operand:VEC_F 2 "vfloat_operand")]
> UNSPEC_COPYSIGN))]
> + (copysign:VEC_F (match_operand:VEC_F 1 "vfloat_operand")
> + (match_operand:VEC_F 2 "vfloat_operand")))]
>"VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
> {
>if (mode == V4SFmode && VECTOR_UNIT_ALTIVEC_P (mode))
> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
> index 4de41e78d51..f3b40229094 100644
> --- a/gcc/config/rs6000/vsx.md
> +++ b/gcc/config/rs6000/vsx.md
> @@ -2233,10 +2233,9 @@ (define_insn "*vsx_ge__p"
> ;; Copy sign
> (define_insn "vsx_copysign3"
>[(set (match_operand:VSX_F 0 "vsx_register_operand" "=wa")
> - (unspec:VSX_F
> -[(match_operand:VSX_F 1 "vsx_register_operand" "wa")
> - (match_operand:VSX_F 2 "vsx_register_opera
Re: Ping^2 [PATCH V5 1/4] rs6000: build constant via li;rotldi
On Mon, Sep 25, 2023 at 10:52 PM Jiufu Guo wrote:
> Hi,
>
> Gentle ping...
>
> BR,
> Jeff (Jiufu Guo)
>
This is okay.
Thanks, David
>
> Jiufu Guo via Gcc-patches writes:
>
> > Hi,
> >
> > Gentle ping...
> >
> > BR,
> > Jeff (Jiufu Guo)
> >
> > Jiufu Guo writes:
> >
> >> Hi,
> >>
> >> If a constant is possible to be rotated to/from a positive or negative
> >> value which "li" can generated, then "li;rotldi" can be used to build
> >> the constant.
> >>
> >> Compare with the previous version:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623528.html
> >> This patch just did minor changes to the comments according to previous
> >> review.
> >>
> >> Bootstrap and regtest pass on ppc64{,le}.
> >>
> >> Is this ok for trunk?
> >>
> >>
> >> BR,
> >> Jeff (Jiufu)
> >>
> >> gcc/ChangeLog:
> >>
> >> * config/rs6000/rs6000.cc (can_be_built_by_li_and_rotldi): New
> function.
> >> (rs6000_emit_set_long_const): Call can_be_built_by_li_and_rotldi.
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >> * gcc.target/powerpc/const-build.c: New test.
> >> ---
> >> gcc/config/rs6000/rs6000.cc | 47 +--
> >> .../gcc.target/powerpc/const-build.c | 57 +++
> >> 2 files changed, 98 insertions(+), 6 deletions(-)
> >> create mode 100644 gcc/testsuite/gcc.target/powerpc/const-build.c
> >>
> >> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> >> index 42f49e4a56b..acc332acc05 100644
> >> --- a/gcc/config/rs6000/rs6000.cc
> >> +++ b/gcc/config/rs6000/rs6000.cc
> >> @@ -10258,6 +10258,31 @@ rs6000_emit_set_const (rtx dest, rtx source)
> >>return true;
> >> }
> >>
> >> +/* Check if value C can be built by 2 instructions: one is 'li',
> another is
> >> + 'rotldi'.
> >> +
> >> + If so, *SHIFT is set to the shift operand of rotldi(rldicl), and
> *MASK
> >> + is set to the mask operand of rotldi(rldicl), and return true.
> >> + Return false otherwise. */
> >> +
> >> +static bool
> >> +can_be_built_by_li_and_rotldi (HOST_WIDE_INT c, int *shift,
> >> + HOST_WIDE_INT *mask)
> >> +{
> >> + /* If C or ~C contains at least 49 successive zeros, then C can be
> rotated
> >> + to/from a positive or negative value that 'li' is able to load.
> */
> >> + int n;
> >> + if (can_be_rotated_to_lowbits (c, 15, &n)
> >> + || can_be_rotated_to_lowbits (~c, 15, &n))
> >> +{
> >> + *mask = HOST_WIDE_INT_M1;
> >> + *shift = HOST_BITS_PER_WIDE_INT - n;
> >> + return true;
> >> +}
> >> +
> >> + return false;
> >> +}
> >> +
> >> /* Subroutine of rs6000_emit_set_const, handling PowerPC64 DImode.
> >> Output insns to set DEST equal to the constant C as a series of
> >> lis, ori and shl instructions. */
> >> @@ -10266,15 +10291,14 @@ static void
> >> rs6000_emit_set_long_const (rtx dest, HOST_WIDE_INT c)
> >> {
> >>rtx temp;
> >> + int shift;
> >> + HOST_WIDE_INT mask;
> >>HOST_WIDE_INT ud1, ud2, ud3, ud4;
> >>
> >>ud1 = c & 0x;
> >> - c = c >> 16;
> >> - ud2 = c & 0x;
> >> - c = c >> 16;
> >> - ud3 = c & 0x;
> >> - c = c >> 16;
> >> - ud4 = c & 0x;
> >> + ud2 = (c >> 16) & 0x;
> >> + ud3 = (c >> 32) & 0x;
> >> + ud4 = (c >> 48) & 0x;
> >>
> >>if ((ud4 == 0x && ud3 == 0x && ud2 == 0x && (ud1 &
> 0x8000))
> >>|| (ud4 == 0 && ud3 == 0 && ud2 == 0 && ! (ud1 & 0x8000)))
> >> @@ -10305,6 +10329,17 @@ rs6000_emit_set_long_const (rtx dest,
> HOST_WIDE_INT c)
> >>emit_move_insn (dest, gen_rtx_XOR (DImode, temp,
> >> GEN_INT ((ud2 ^ 0x) << 16)));
> >> }
> >> + else if (can_be_built_by_li_and_rotldi (c, &shift, &mask))
> >> +{
> >> + temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> >> + unsigned HOST_WIDE_INT imm = (c | ~mask);
> >> + imm = (imm >> shift) | (imm << (HOST_BITS_PER_WIDE_INT - shift));
> >> +
> >> + emit_move_insn (temp, GEN_INT (imm));
> >> + if (shift != 0)
> >> +temp = gen_rtx_ROTATE (DImode, temp, GEN_INT (shift));
> >> + emit_move_insn (dest, temp);
> >> +}
> >>else if (ud3 == 0 && ud4 == 0)
> >> {
> >>temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> >> diff --git a/gcc/testsuite/gcc.target/powerpc/const-build.c
> b/gcc/testsuite/gcc.target/powerpc/const-build.c
> >> new file mode 100644
> >> index 000..69b37e2bb53
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.target/powerpc/const-build.c
> >> @@ -0,1 +1,57 @@
> >> +/* { dg-do run } */
> >> +/* { dg-options "-O2 -save-temps" } */
> >> +/* { dg-require-effective-target has_arch_ppc64 } */
> >> +
> >> +/* Verify that two instructions are successfully used to build
> constants.
> >> + One insn is li, another is rotate: rldicl. */
> >> +
> >> +#define NOIPA __attribute__ ((noipa))
> >> +
> >> +struct fun
> >> +{
> >> + long long (*f) (void);
> >> + long long val;
> >> +};
> >> +
> >> +long l
Re: [PATCH v3] RISC-V:Optimize the MASK opt generation
Wang, The AWK portions of this patch broke bootstrap on AIX. Also, the AWK portions are common code, not RISC-V specific. I don't see anywhere that the common portions of the patch were reviewed or approved by anyone with authority to approve the changes to the AWK files. This patch should not have been committed without approval by a reviewer with authority for that portion of the compiler and should have been tested on targets other than RISC-V if common parts of the compiler were changed. Thanks, David
Re: [PATCH v3] RISC-V:Optimize the MASK opt generation
On Mon, Oct 2, 2023 at 1:59 PM Jeff Law wrote: > > > On 10/2/23 11:20, David Edelsohn wrote: > > Wang, > > > > The AWK portions of this patch broke bootstrap on AIX. > > > > Also, the AWK portions are common code, not RISC-V specific. I don't > > see anywhere that the common portions of the patch were reviewed or > > approved by anyone with authority to approve the changes to the AWK > files. > > > > This patch should not have been committed without approval by a reviewer > > with authority for that portion of the compiler and should have been > > tested on targets other than RISC-V if common parts of the compiler were > > changed. > I acked the generic bits. So the lack of testing on another target is > on me. > Hi, Jeff Sorry. I didn't see a comment from a global reviewer in the V3 thread. I am using Gawk on AIX. After the change, I see a parse error from gawk. I'm rebuilding with a checkout just before the change to confirm that it was the source of the error, and it seems to be past that failure location. I didn't keep the exact error. Once I get past this build cycle, I'll reproduce it. Thanks, David
Re: [PATCH v3] RISC-V:Optimize the MASK opt generation
The patch works on AIX. I have Gawk installed, but it is a very old release before multi-dimensional array support was added. Thanks, David On Mon, Oct 2, 2023 at 10:38 PM Kito Cheng wrote: > Proposed fix, and verified with "mawk" and "gawk -P" (gawk with posix > mode) on my linux also some other report it work on freebsd, just wait > review :) > > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631785.html > > On Tue, Oct 3, 2023 at 2:07 AM Jeff Law wrote: > > > > > > > > On 10/2/23 12:03, David Edelsohn wrote: > > > On Mon, Oct 2, 2023 at 1:59 PM Jeff Law > > <mailto:jeffreya...@gmail.com>> wrote: > > > > > > > > > > > > On 10/2/23 11:20, David Edelsohn wrote: > > > > Wang, > > > > > > > > The AWK portions of this patch broke bootstrap on AIX. > > > > > > > > Also, the AWK portions are common code, not RISC-V specific. I > > > don't > > > > see anywhere that the common portions of the patch were > reviewed or > > > > approved by anyone with authority to approve the changes to the > > > AWK files. > > > > > > > > This patch should not have been committed without approval by a > > > reviewer > > > > with authority for that portion of the compiler and should have > been > > > > tested on targets other than RISC-V if common parts of the > > > compiler were > > > > changed. > > > I acked the generic bits. So the lack of testing on another > target is > > > on me. > > > > > > > > > Hi, Jeff > > > > > > Sorry. I didn't see a comment from a global reviewer in the V3 thread. > > NP. > > > > > > > > I am using Gawk on AIX. After the change, I see a parse error from > > > gawk. I'm rebuilding with a checkout just before the change to confirm > > > that it was the source of the error, and it seems to be past that > > > failure location. I didn't keep the exact error. Once I get past this > > > build cycle, I'll reproduce it. > > I think there's already a patch circulating which fixes this. It broke > > at least one other platform. Hopefully it'll all be sorted out today. > > > > > > jeff >
Re: [PATCH] rs6000: Make 32 bit stack_protect support prefixed insn [PR111367]
On Wed, Sep 27, 2023 at 1:38 AM Kewen.Lin wrote:
> Hi,
>
> As PR111367 shows, with prefixed insn supported, some of
> checkings consider it's able to leverage prefixed insn
> for stack protect related load/store, but since we don't
> actually change the emitted assembly for 32 bit, it can
> cause the assembler error as exposed.
>
> Mike's commit r10-4547-gce6a6c007e5a98 has already handled
> the 64 bit case (DImode), this patch is to treat the 32
> bit case (SImode) by making use of mode iterator P and
> ptrload attribute iterator, also fixes the constraints
> to match the emitted operand formats.
>
> Bootstrapped and regtested on powerpc64-linux-gnu P7/P8/P9
> and powerpc64le-linux-gnu P9.
>
> This patch has incorporated Segher's comments in PR111367,
> I'm going to push this soon if no objections.
>
This patch is okay.
Thanks, David
>
> BR,
> Kewen
> -
> PR target/111367
>
> gcc/ChangeLog:
>
> * config/rs6000/rs6000.md (stack_protect_setsi): Support prefixed
> instruction emission and incorporate to stack_protect_set.
> (stack_protect_setdi): Rename to ...
> (stack_protect_set): ... this, adjust constraint.
> (stack_protect_testsi): Support prefixed instruction emission and
> incorporate to stack_protect_test.
> (stack_protect_testdi): Rename to ...
> (stack_protect_test): ... this, adjust constraint.
>
> gcc/testsuite/ChangeLog:
>
> * g++.target/powerpc/pr111367.C: New test.
> ---
> gcc/config/rs6000/rs6000.md | 73 -
> gcc/testsuite/g++.target/powerpc/pr111367.C | 22 +++
> 2 files changed, 49 insertions(+), 46 deletions(-)
> create mode 100644 gcc/testsuite/g++.target/powerpc/pr111367.C
>
> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index 1a9a7b1a479..0ac79fc7735 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -12389,33 +12389,26 @@ (define_expand "stack_protect_set"
>DONE;
> })
>
> -(define_insn "stack_protect_setsi"
> - [(set (match_operand:SI 0 "memory_operand" "=m")
> - (unspec:SI [(match_operand:SI 1 "memory_operand" "m")]
> UNSPEC_SP_SET))
> - (set (match_scratch:SI 2 "=&r") (const_int 0))]
> - "TARGET_32BIT"
> - "lwz%U1%X1 %2,%1\;stw%U0%X0 %2,%0\;li %2,0"
> - [(set_attr "type" "three")
> - (set_attr "length" "12")])
> -
> ;; We can't use the prefixed attribute here because there are two memory
> ;; instructions. We can't split the insn due to the fact that this
> operation
> ;; needs to be done in one piece.
> -(define_insn "stack_protect_setdi"
> - [(set (match_operand:DI 0 "memory_operand" "=Y")
> - (unspec:DI [(match_operand:DI 1 "memory_operand" "Y")]
> UNSPEC_SP_SET))
> - (set (match_scratch:DI 2 "=&r") (const_int 0))]
> - "TARGET_64BIT"
> +(define_insn "stack_protect_set"
> + [(set (match_operand:P 0 "memory_operand" "=YZ")
> + (unspec:P [(match_operand:P 1 "memory_operand" "YZ")]
> UNSPEC_SP_SET))
> + (set (match_scratch:P 2 "=&r") (const_int 0))]
> + ""
> {
> - if (prefixed_memory (operands[1], DImode))
> -output_asm_insn ("pld %2,%1", operands);
> + if (prefixed_memory (operands[1], mode))
> +/* Prefixed load only supports D-form but no update and X-form. */
> +output_asm_insn ("p %2,%1", operands);
>else
> -output_asm_insn ("ld%U1%X1 %2,%1", operands);
> +output_asm_insn ("%U1%X1 %2,%1", operands);
>
> - if (prefixed_memory (operands[0], DImode))
> -output_asm_insn ("pstd %2,%0", operands);
> + if (prefixed_memory (operands[0], mode))
> +/* Prefixed store only supports D-form but no update and X-form. */
> +output_asm_insn ("pst %2,%0", operands);
>else
> -output_asm_insn ("std%U0%X0 %2,%0", operands);
> +output_asm_insn ("st%U0%X0 %2,%0", operands);
>
>return "li %2,0";
> }
> @@ -12461,45 +12454,33 @@ (define_expand "stack_protect_test"
>DONE;
> })
>
> -(define_insn "stack_protect_testsi"
> - [(set (match_operand:CCEQ 0 "cc_reg_operand" "=x,?y")
> -(unspec:CCEQ [(match_operand:SI 1 "memory_operand" "m,m")
> - (match_operand:SI 2 "memory_operand" "m,m")]
> -UNSPEC_SP_TEST))
> - (set (match_scratch:SI 4 "=r,r") (const_int 0))
> - (clobber (match_scratch:SI 3 "=&r,&r"))]
> - "TARGET_32BIT"
> - "@
> - lwz%U1%X1 %3,%1\;lwz%U2%X2 %4,%2\;xor. %3,%3,%4\;li %4,0
> - lwz%U1%X1 %3,%1\;lwz%U2%X2 %4,%2\;cmplw %0,%3,%4\;li %3,0\;li %4,0"
> - [(set_attr "length" "16,20")])
> -
> ;; We can't use the prefixed attribute here because there are two memory
> ;; instructions. We can't split the insn due to the fact that this
> operation
> ;; needs to be done in one piece.
> -(define_insn "stack_protect_testdi"
> +(define_insn "stack_protect_test"
>[(set (match_operand:CCEQ 0 "cc_reg_operand" "=x,?y")
> -(unspec:CCEQ [(match_operand:DI 1 "memory_operand" "Y,Y")
> - (match_operand:DI 2 "memory_operand" "Y,Y")]
>
Re: [COMMITTED] Return TRUE only when a global value is updated.
This patch caused a bootstrap failure on AIX. during GIMPLE pass: evrp /nasfarm/edelsohn/src/src/libgcc/libgcc2.c: In function '__gcc_bcmp': /nasfarm/edelsohn/src/src/libgcc/libgcc2.c:2910:1: internal compiler error: in get_irange, at value-range-storage.cc:343 2910 | } | ^ 0x11b7f4b7 irange_storage::get_irange(irange&, tree_node*) const /nasfarm/edelsohn/src/src/gcc/value-range-storage.cc:343 0x11b7e7af vrange_storage::get_vrange(vrange&, tree_node*) const /nasfarm/edelsohn/src/src/gcc/value-range-storage.cc:178 0x139f3d77 range_info_get_range(tree_node const*, vrange&) /nasfarm/edelsohn/src/src/gcc/tree-ssanames.cc:118 0x1134b463 set_range_info(tree_node*, vrange const&) /nasfarm/edelsohn/src/src/gcc/tree-ssanames.cc:425 0x116a7333 gimple_ranger::register_inferred_ranges(gimple*) /nasfarm/edelsohn/src/src/gcc/gimple-range.cc:487 0x125cef27 rvrp_folder::fold_stmt(gimple_stmt_iterator*) /nasfarm/edelsohn/src/src/gcc/tree-vrp.cc:1033 0x123dd063 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) /nasfarm/edelsohn/src/src/gcc/tree-ssa-propagate.cc:876 0x1176cc43 dom_walker::walk(basic_block_def*) /nasfarm/edelsohn/src/src/gcc/domwalk.cc:311 0x123dd733 substitute_and_fold_engine::substitute_and_fold(basic_block_def*) /nasfarm/edelsohn/src/src/gcc/tree-ssa-propagate.cc:999 0x123d0f5f execute_ranger_vrp(function*, bool, bool) /nasfarm/edelsohn/src/src/gcc/tree-vrp.cc:1062 0x123d14ef execute /nasfarm/edelsohn/src/src/gcc/tree-vrp.cc:1142
Re: [COMMITTED] Return TRUE only when a global value is updated.
AIX bootstrap is happier with the patch. Thanks, David On Tue, Oct 3, 2023 at 12:30 PM Andrew MacLeod wrote: > Give this a try.. I'm testing it here, but x86 doesn't seem to show it > anyway for some reason :-P > > I think i needed to handle pointers special since SSA_NAMES handle > pointer ranges different. > > Andrew > > On 10/3/23 11:47, David Edelsohn wrote: > > This patch caused a bootstrap failure on AIX. > > > > during GIMPLE pass: evrp > > > > /nasfarm/edelsohn/src/src/libgcc/libgcc2.c: In function '__gcc_bcmp': > > > > /nasfarm/edelsohn/src/src/libgcc/libgcc2.c:2910:1: internal compiler > > error: in get_irange, at value-range-storage.cc:343 > > > > 2910 | } > > > > | ^ > > > > > > 0x11b7f4b7 irange_storage::get_irange(irange&, tree_node*) const > > > > /nasfarm/edelsohn/src/src/gcc/value-range-storage.cc:343 > > > > 0x11b7e7af vrange_storage::get_vrange(vrange&, tree_node*) const > > > > /nasfarm/edelsohn/src/src/gcc/value-range-storage.cc:178 > > > > 0x139f3d77 range_info_get_range(tree_node const*, vrange&) > > > > /nasfarm/edelsohn/src/src/gcc/tree-ssanames.cc:118 > > > > 0x1134b463 set_range_info(tree_node*, vrange const&) > > > > /nasfarm/edelsohn/src/src/gcc/tree-ssanames.cc:425 > > > > 0x116a7333 gimple_ranger::register_inferred_ranges(gimple*) > > > > /nasfarm/edelsohn/src/src/gcc/gimple-range.cc:487 > > > > 0x125cef27 rvrp_folder::fold_stmt(gimple_stmt_iterator*) > > > > /nasfarm/edelsohn/src/src/gcc/tree-vrp.cc:1033 > > > > 0x123dd063 > > substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) > > > > /nasfarm/edelsohn/src/src/gcc/tree-ssa-propagate.cc:876 > > > > 0x1176cc43 dom_walker::walk(basic_block_def*) > > > > /nasfarm/edelsohn/src/src/gcc/domwalk.cc:311 > > > > 0x123dd733 > > substitute_and_fold_engine::substitute_and_fold(basic_block_def*) > > > > /nasfarm/edelsohn/src/src/gcc/tree-ssa-propagate.cc:999 > > > > 0x123d0f5f execute_ranger_vrp(function*, bool, bool) > > > > /nasfarm/edelsohn/src/src/gcc/tree-vrp.cc:1062 > > > > 0x123d14ef execute > > > > /nasfarm/edelsohn/src/src/gcc/tree-vrp.cc:1142 > >
Re: [PATCH v2] Add a GCC Security policy
Hi, Siddhesh Thanks for working on this and fine-tuning the original proposed text. It looks good to me. Minor grammatical nit below. Thanks, David On Thu, Sep 28, 2023 at 7:59 AM Siddhesh Poyarekar wrote: > On 2023-09-28 12:55, Siddhesh Poyarekar wrote: > > Define a security process and exclusions to security issues for GCC and > > all components it ships. > > > > Signed-off-by: Siddhesh Poyarekar > > --- > > Sorry I forgot to summarize changes since the previous version: > > - Reworded the introduction so that it doesn't sound like we know *all* > scenarios and also encourage reporters to reach out. > > - Fixed up support and diagnostic libraries sections based on Jakub's > feedback. > > > SECURITY.txt | 205 +++ > > 1 file changed, 205 insertions(+) > > create mode 100644 SECURITY.txt > > > > diff --git a/SECURITY.txt b/SECURITY.txt > > new file mode 100644 > > index 000..14cb31570d3 > > --- /dev/null > > +++ b/SECURITY.txt > > @@ -0,0 +1,205 @@ > > +What is a GCC security bug? > > +=== > > + > > +A security bug is one that threatens the security of a system or > > +network, or might compromise the security of data stored on it. > > +In the context of GCC there are multiple ways in which this might > > +happen and some common scenarios are detailed below. > > + > > +If you're reporting a security issue and feel like it does not fit > > +into any of the descriptions below, you're encouraged to reach out > > +through the GCC bugzilla or if needed, privately by following the > Some missing, pedantic commas: through the GCC bugzilla or, if needed, privately, by following the > > +instructions in the last two sections of this document. > > + > > +Compiler drivers, programs, libgccjit and support libraries > > +--- > > + > > +The compiler driver processes source code, invokes other programs > > +such as the assembler and linker and generates the output result, > > +which may be assembly code or machine code. Compiling untrusted > > +sources can result in arbitrary code execution and unconstrained > > +resource consumption in the compiler. As a result, compilation of > > +such code should be done inside a sandboxed environment to ensure > > +that it does not compromise the development environment. > > + > > +The libgccjit library can, despite the name, be used both for > > +ahead-of-time compilation and for just-in-compilation. In both > > +cases it can be used to translate input representations (such as > > +source code) in the application context; in the latter case the > > +generated code is also run in the application context. > > + > > +Limitations that apply to the compiler driver, apply here too in > > +terms of sanitizing inputs and it is recommended that both the > > +compilation *and* execution context of the code are appropriately > > +sandboxed to contain the effects of any bugs in libgccjit, the > > +application code using it, or its generated code to the sandboxed > > +environment. > > + > > +Libraries such as libiberty, libcc1 and libcpp are not distributed > > +for runtime support and have similar challenges to compiler drivers. > > +While they are expected to be robust against arbitrary input, they > > +should only be used with trusted inputs when linked into the > > +compiler. > > + > > +Libraries such as zlib that bundled into GCC to build it will be > > +treated the same as the compiler drivers and programs as far as > > +security coverage is concerned. However if you find an issue in > > +these libraries independent of their use in GCC, you should reach > > +out to their upstream projects to report them. > > + > > +As a result, the only case for a potential security issue in the > > +compiler is when it generates vulnerable application code for > > +trusted input source code that is conforming to the relevant > > +programming standard or extensions documented as supported by GCC > > +and the algorithm expressed in the source code does not have the > > +vulnerability. The output application code could be considered > > +vulnerable if it produces an actual vulnerability in the target > > +application, specifically in the following cases: > > + > > +- The application dereferences an invalid memory location despite > > + the application sources being valid. > > +- The application reads from or writes to a valid but incorrect > > + memory location, resulting in an information integrity issue or an > > + information leak. > > +- The application ends up running in an infinite loop or with > > + severe degradation in performance despite the input sources having > > + no such issue, resulting in a Denial of Service. Note that > > +
Re: [PATCH V5 1/2] rs6000: optimize moving to sf from highpart di
On Thu, Oct 5, 2023 at 12:50 AM Jiufu Guo wrote:
> Hi,
>
> Currently, we have the pattern "movsf_from_si2" which was trying
> to support moving high part DI to SF.
>
> But current pattern only accepts "ashiftrt":
> XX:SF=bitcast:SF(subreg(YY:DI>>32),0), but actually "lshiftrt" should
> also be ok.
> And current pattern only supports BE.
>
> This patch updats the pattern to support BE and "lshiftrt".
>
> Compare with previous version:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628790.html
> This version refines the code slightly and updates the test case
> according to review comments.
>
> Pass bootstrap and regtest on ppc64{,le}.
> Is this ok for trunk?
>
Okay.
Thanks, David
>
> BR,
> Jeff (Jiufu Guo)
>
> PR target/108338
>
> gcc/ChangeLog:
>
> * config/rs6000/predicates.md (lowpart_subreg_operator): New
> define_predicate.
> * config/rs6000/rs6000.md (any_rshift): New code_iterator.
> (movsf_from_si2): Rename to ...
> (movsf_from_si2_): ... this.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/powerpc/pr108338.c: New test.
>
> ---
> gcc/config/rs6000/predicates.md | 5 +++
> gcc/config/rs6000/rs6000.md | 12 ---
> gcc/testsuite/gcc.target/powerpc/pr108338.c | 37 +
> 3 files changed, 49 insertions(+), 5 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/powerpc/pr108338.c
>
> diff --git a/gcc/config/rs6000/predicates.md
> b/gcc/config/rs6000/predicates.md
> index 925f69cd3fc..ef7d3f214c4 100644
> --- a/gcc/config/rs6000/predicates.md
> +++ b/gcc/config/rs6000/predicates.md
> @@ -2098,3 +2098,8 @@ (define_predicate "macho_pic_address"
>else
> return false;
> })
> +
> +(define_predicate "lowpart_subreg_operator"
> + (and (match_code "subreg")
> + (match_test "subreg_lowpart_offset (mode, GET_MODE (SUBREG_REG
> (op)))
> + == SUBREG_BYTE (op)")))
> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index 1a9a7b1a479..56bd8bc1147 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -643,6 +643,9 @@ (define_code_iterator any_extend[sign_extend
> zero_extend])
> (define_code_iterator any_fix [fix unsigned_fix])
> (define_code_iterator any_float[float unsigned_float])
>
> +; Shift right.
> +(define_code_iterator any_shiftrt [ashiftrt lshiftrt])
> +
> (define_code_attr u [(sign_extend "")
> (zero_extend "u")
> (fix "")
> @@ -8303,14 +8306,13 @@ (define_insn_and_split "movsf_from_si"
> ;; {%1:SF=unspec[r122:DI>>0x20#0] 86;clobber scratch;}
> ;; split it before reload with "and mask" to avoid generating shift right
> ;; 32 bit then shift left 32 bit.
> -(define_insn_and_split "movsf_from_si2"
> +(define_insn_and_split "movsf_from_si2_"
>[(set (match_operand:SF 0 "gpc_reg_operand" "=wa")
> (unspec:SF
> -[(subreg:SI
> - (ashiftrt:DI
> +[(match_operator:SI 3 "lowpart_subreg_operator"
> + [(any_shiftrt:DI
> (match_operand:DI 1 "input_operand" "r")
> - (const_int 32))
> - 0)]
> + (const_int 32))])]
> UNSPEC_SF_FROM_SI))
>(clobber (match_scratch:DI 2 "=r"))]
>"TARGET_NO_SF_SUBREG"
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr108338.c
> b/gcc/testsuite/gcc.target/powerpc/pr108338.c
> new file mode 100644
> index 000..bd83c0b3ad8
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr108338.c
> @@ -0,0 +1,37 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target hard_float } */
> +/* { dg-options "-O2 -save-temps" } */
> +
> +/* Under lp64, parameter 'v' is in DI regs, then bitcast sub DI to SF. */
> +/* { dg-final { scan-assembler-times {\mxscvspdpn\M} 1 { target { lp64 &&
> has_arch_pwr8 } } } } */
> +/* { dg-final { scan-assembler-times {\mmtvsrd\M} 1 { target { lp64 &&
> has_arch_pwr8 } } } } */
> +/* { dg-final { scan-assembler-times {\mrldicr\M} 1 { target { lp64 &&
> has_arch_pwr8 } } } } */
> +
> +struct di_sf_sf
> +{
> + float f1; float f2; long long l;
> +};
> +
> +float __attribute__ ((noipa))
> +sf_from_high32bit_di (struct di_sf_sf v)
> +{
> +#ifdef __LITTLE_ENDIAN__
> + return v.f2;
> +#else
> + return v.f1;
> +#endif
> +}
> +
> +int main()
> +{
> + struct di_sf_sf v;
> + v.f1 = v.f2 = 0.0f;
> +#ifdef __LITTLE_ENDIAN__
> + v.f2 = 2.0f;
> +#else
> + v.f1 = 2.0f;
> +#endif
> + if (sf_from_high32bit_di (v) != 2.0f)
> +__builtin_abort ();
> + return 0;
> +}
> --
> 2.25.1
>
>
Re: [PATCH V5 2/2] rs6000: use mtvsrws to move sf from si p9
On Thu, Oct 5, 2023 at 12:14 AM Jiufu Guo wrote:
> Hi,
>
> As mentioned in PR108338, on p9, we could use mtvsrws to implement
> the bitcast from SI to SF (or lowpart DI to SF).
>
> For example:
> *(long long*)buff = di;
> float f = *(float*)(buff);
>
> "sldi 9,3,32 ; mtvsrd 1,9 ; xscvspdpn 1,1" is generated.
> A better one would be "mtvsrws 1,3 ; xscvspdpn 1,1".
>
> Compare with previous patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628791.html
> According to review comments, this version refines commit message
> and words in comments, also updates the test case
>
> Pass bootstrap and regtest on ppc64{,le}.
> Is this ok for trunk?
>
Okay.
Thanks, David
>
> BR,
> Jeff (Jiufu Guo)
>
> PR target/108338
>
> gcc/ChangeLog:
>
> * config/rs6000/rs6000.md (movsf_from_si): Update to generate
> mtvsrws
> for P9.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/powerpc/pr108338.c: Updated to check mtvsrws for p9.
>
> ---
> gcc/config/rs6000/rs6000.md | 25 -
> gcc/testsuite/gcc.target/powerpc/pr108338.c | 21 ++---
> 2 files changed, 37 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index 56bd8bc1147..d6dfb25cea0 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -8283,13 +8283,26 @@ (define_insn_and_split "movsf_from_si"
> {
>rtx op0 = operands[0];
>rtx op1 = operands[1];
> - rtx op2 = operands[2];
> - rtx op1_di = gen_rtx_REG (DImode, REGNO (op1));
>
> - /* Move SF value to upper 32-bits for xscvspdpn. */
> - emit_insn (gen_ashldi3 (op2, op1_di, GEN_INT (32)));
> - emit_insn (gen_p8_mtvsrd_sf (op0, op2));
> - emit_insn (gen_vsx_xscvspdpn_directmove (op0, op0));
> + /* Move lowpart 32-bits from register for SFmode. */
> + if (TARGET_P9_VECTOR)
> +{
> + /* Using mtvsrws;xscvspdpn. */
> + rtx op0_v = gen_rtx_REG (V4SImode, REGNO (op0));
> + emit_insn (gen_vsx_splat_v4si (op0_v, op1));
> + emit_insn (gen_vsx_xscvspdpn_directmove (op0, op0));
> +}
> + else
> +{
> + rtx op2 = operands[2];
> + rtx op1_di = gen_rtx_REG (DImode, REGNO (op1));
> +
> + /* Using sldi;mtvsrd;xscvspdpn. */
> + emit_insn (gen_ashldi3 (op2, op1_di, GEN_INT (32)));
> + emit_insn (gen_p8_mtvsrd_sf (op0, op2));
> + emit_insn (gen_vsx_xscvspdpn_directmove (op0, op0));
> +}
> +
>DONE;
> }
>[(set_attr "length"
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr108338.c
> b/gcc/testsuite/gcc.target/powerpc/pr108338.c
> index bd83c0b3ad8..5f2f62866ee 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr108338.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr108338.c
> @@ -3,9 +3,12 @@
> /* { dg-options "-O2 -save-temps" } */
>
> /* Under lp64, parameter 'v' is in DI regs, then bitcast sub DI to SF. */
> -/* { dg-final { scan-assembler-times {\mxscvspdpn\M} 1 { target { lp64 &&
> has_arch_pwr8 } } } } */
> -/* { dg-final { scan-assembler-times {\mmtvsrd\M} 1 { target { lp64 &&
> has_arch_pwr8 } } } } */
> +/* { dg-final { scan-assembler-times {\mxscvspdpn\M} 2 { target { lp64 &&
> has_arch_pwr8 } } } } */
> +/* { dg-final { scan-assembler-times {\mmtvsrd\M} 2 { target { lp64 && {
> has_arch_pwr8 && { ! has_arch_pwr9 } } } } } } */
> +/* { dg-final { scan-assembler-times {\mmtvsrd\M} 1 { target { lp64 &&
> has_arch_pwr9 } } } } */
> +/* { dg-final { scan-assembler-times {\mmtvsrws\M} 1 { target { lp64 &&
> has_arch_pwr9 } } } } */
> /* { dg-final { scan-assembler-times {\mrldicr\M} 1 { target { lp64 &&
> has_arch_pwr8 } } } } */
> +/* { dg-final { scan-assembler-times {\msldi\M} 1 { target { lp64 && {
> has_arch_pwr8 && { ! has_arch_pwr9 } } } } } } */
>
> struct di_sf_sf
> {
> @@ -22,16 +25,28 @@ sf_from_high32bit_di (struct di_sf_sf v)
> #endif
> }
>
> +float __attribute__ ((noipa))
> +sf_from_low32bit_di (struct di_sf_sf v)
> +{
> +#ifdef __LITTLE_ENDIAN__
> + return v.f1;
> +#else
> + return v.f2;
> +#endif
> +}
> +
> int main()
> {
>struct di_sf_sf v;
>v.f1 = v.f2 = 0.0f;
> #ifdef __LITTLE_ENDIAN__
> + v.f1 = 1.0f;
>v.f2 = 2.0f;
> #else
>v.f1 = 2.0f;
> + v.f2 = 1.0f;
> #endif
> - if (sf_from_high32bit_di (v) != 2.0f)
> + if (sf_from_high32bit_di (v) != 2.0f || sf_from_low32bit_di (v) != 1.0f)
> __builtin_abort ();
>return 0;
> }
> --
> 2.25.1
>
>
Re: [PATCH-2, rs6000] Enable vector mode for memory equality compare [PR111449]
On Sun, Oct 8, 2023 at 10:30 PM HAO CHEN GUI wrote:
> Hi,
> This patch enables vector mode for memory equality compare by adding
> a new expand cbranchv16qi4 and implementing it. Also the corresponding
> CC reg and compare code is set in rs6000_generate_compare. With the
> patch, 16-byte equality compare can be implemented by one vector compare
> instructions other than 2 8-byte compares with branches.
>
> The test case is in the second patch which is rs6000 specific.
>
> Bootstrapped and tested on powerpc64-linux BE and LE with no
> regressions.
>
Thanks for working on this.
>
> Thanks
> Gui Haochen
>
> ChangeLog
> rs6000: Enable vector compare for memory equality compare
>
> gcc/
> PR target/111449
> * config/rs6000/altivec.md (cbranchv16qi4): New expand pattern.
> * config/rs6000/rs6000.cc (rs6000_generate_compare): Generate insn
> sequence for V16QImode equality compare.
> * config/rs6000/rs6000.h (MOVE_MAX_PIECES): Define.
> (COMPARE_MAX_PIECES): Define.
>
> gcc/testsuite/
> PR target/111449
> * gcc.target/powerpc/pr111449.c: New.
>
> patch.diff
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index e8a596fb7e9..c69bf266402 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -2605,6 +2605,39 @@ (define_insn "altivec_vupklpx"
> }
>[(set_attr "type" "vecperm")])
>
> +(define_expand "cbranchv16qi4"
> + [(use (match_operator 0 "equality_operator"
> + [(match_operand:V16QI 1 "gpc_reg_operand")
> +(match_operand:V16QI 2 "gpc_reg_operand")]))
> + (use (match_operand 3))]
> + "VECTOR_UNIT_ALTIVEC_P (V16QImode)"
> +{
> + if (!TARGET_P9_VECTOR
> + && MEM_P (operands[1])
> + && !altivec_indexed_or_indirect_operand (operands[1], V16QImode)
> + && MEM_P (operands[2])
> + && !altivec_indexed_or_indirect_operand (operands[2], V16QImode))
> +{
> + /* Use direct move as the byte order doesn't matter for equality
> +compare. */
> + rtx reg_op1 = gen_reg_rtx (V16QImode);
> + rtx reg_op2 = gen_reg_rtx (V16QImode);
> + rs6000_emit_le_vsx_permute (reg_op1, operands[1], V16QImode);
> + rs6000_emit_le_vsx_permute (reg_op2, operands[2], V16QImode);
> + operands[1] = reg_op1;
> + operands[2] = reg_op2;
> +}
> + else
> +{
> + operands[1] = force_reg (V16QImode, operands[1]);
> + operands[2] = force_reg (V16QImode, operands[2]);
> +}
> + rtx_code code = GET_CODE (operands[0]);
> + operands[0] = gen_rtx_fmt_ee (code, V16QImode, operands[1],
> operands[2]);
> + rs6000_emit_cbranch (V16QImode, operands);
> + DONE;
> +})
> +
> ;; Compare vectors producing a vector result and a predicate, setting CR6
> to
> ;; indicate a combined status
> (define_insn "altivec_vcmpequ_p"
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index efe9adce1f8..0087d786840 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -15264,6 +15264,15 @@ rs6000_generate_compare (rtx cmp, machine_mode
> mode)
> else
> emit_insn (gen_stack_protect_testsi (compare_result, op0,
> op1b));
> }
> + else if (mode == V16QImode)
> + {
> + gcc_assert (code == EQ || code == NE);
> +
> + rtx result_vector = gen_reg_rtx (V16QImode);
> + compare_result = gen_rtx_REG (CCmode, CR6_REGNO);
> + emit_insn (gen_altivec_vcmpequb_p (result_vector, op0, op1));
> + code = (code == NE) ? GE : LT;
> + }
>else
> emit_insn (gen_rtx_SET (compare_result,
> gen_rtx_COMPARE (comp_mode, op0, op1)));
> diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
> index 3503614efbd..dc33bca0802 100644
> --- a/gcc/config/rs6000/rs6000.h
> +++ b/gcc/config/rs6000/rs6000.h
> @@ -1730,6 +1730,8 @@ typedef struct rs6000_args
> in one reasonably fast instruction. */
> #define MOVE_MAX (! TARGET_POWERPC64 ? 4 : 8)
> #define MAX_MOVE_MAX 8
> +#define MOVE_MAX_PIECES (!TARGET_POWERPC64 ? 4 : 16)
> +#define COMPARE_MAX_PIECES (!TARGET_POWERPC64 ? 4 : 16)
>
How are the definitions of MOVE_MAX_PIECES and COMPARE_MAX_PIECES
determined? The email does not provide any explanation for the
implementation. The rest of the patch is related to vector support, but
vector support is not dependent on TARGET_POWERPC64.
Thanks, David
>
> /* Nonzero if access to memory by bytes is no faster than for words.
> Also nonzero if doing byte operations (specifically shifts) in
> registers
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr111449.c
> b/gcc/testsuite/gcc.target/powerpc/pr111449.c
> new file mode 100644
> index 000..a8c30b92a41
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr111449.c
> @@ -0,0 +1,19 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_p8vector_ok } */
> +/* { dg-options "-maltivec -O2" } */
> +
Re: [PATCH-2, rs6000] Enable vector mode for memory equality compare [PR111449]
On Tue, Oct 10, 2023 at 4:23 AM HAO CHEN GUI wrote: > Hi David, > > Thanks for your review comments. > > 在 2023/10/9 23:42, David Edelsohn 写道: > > #define MOVE_MAX (! TARGET_POWERPC64 ? 4 : 8) > > #define MAX_MOVE_MAX 8 > > +#define MOVE_MAX_PIECES (!TARGET_POWERPC64 ? 4 : 16) > > +#define COMPARE_MAX_PIECES (!TARGET_POWERPC64 ? 4 : 16) > > > > > > How are the definitions of MOVE_MAX_PIECES and COMPARE_MAX_PIECES > determined? The email does not provide any explanation for the > implementation. The rest of the patch is related to vector support, but > vector support is not dependent on TARGET_POWERPC64. > > By default, MOVE_MAX_PIECES and COMPARE_MAX_PIECES is set the same value > as MOVE_MAX. The move and compare instructions are required in > compare_by_pieces, those macros are set to 16 byte when supporting > vector mode (V16QImode). The problem is rs6000 hasn't supported TImode > for "-m32". We discussed it in issue 1307. TImode will be used for > move when MOVE_MAX_PIECES is set to 16. But TImode isn't supported > with "-m32" which might cause ICE. > > So MOVE_MAX_PIECES and COMPARE_MAX_PIECES is set to 4 for 32 bit > target in this patch. They could be changed to 16 after rs6000 > supports TImode with "-m32". > Hi, Hao Thanks for the explanation. Are you stating that although PPC32 supports V16QImode in VSX, the move_by_pieces support also requires TImode, which is not available on PPC32? Thanks, David
Re: [PATCH] early outs for functions in rs6000.cc
On Tue, Oct 10, 2023 at 9:29 PM Jiufu Guo wrote:
> Hi,
>
> There are some piece of code like below in rs6000.cc:
>
> ...
> if (xx)
>return x;
> else if (yy)
>return y;
> ... //else if chain
> else
>return d;
>
> Using early outs would be more preferable for this kind of code.
>
Why?
This seems like premature optimization.
Thanks, David
>
> The whole function rs6000_emit_set_long_const and num_insns_constant_gpr
> are refined. And similar code are also restuctured in rs6000.cc.
>
> This patch pass bootstrap and regtest on ppc64{,le}.
> Is this ok for trunk?
>
> BR,
> Jeff (Jiufu Guo)
>
> gcc/ChangeLog:
>
> * config/rs6000/rs6000.cc (vspltis_shifted): Adopt early outs.
> (rs6000_cost_data::determine_suggested_unroll_factor): Likewise.
> (num_insns_constant_gpr): Likewise.
> (easy_altivec_constant): Likewise.
> (output_vec_const_move): Likewise.
> (rs6000_expand_vector_set): Likewise.
> (rs6000_legitimize_address): Likewise.
> (rs6000_emit_set_long_const): Likewise.
> (rs6000_preferred_reload_class): Likewise.
> (rs6000_can_change_mode_class): Likewise.
> (rs6000_output_move_128bit): Likewise.
> (rs6000_emit_vector_cond_expr): Likewise.
> (adjacent_mem_locations): Likewise.
> (is_fusable_store): Likewise.
> (insn_terminates_group_p): Likewise.
> (rs6000_elf_reloc_rw_mask): Likewise.
> (rs6000_rtx_costs): Likewise.
> (rs6000_scalar_mode_supported_p): Likewise.
> (rs6000_update_ipa_fn_target_info): Likewise.
> (reg_to_non_prefixed): Likewise.
> (rs6000_split_logical_inner): Likewise.
> (rs6000_opaque_type_invalid_use_p): Likewise.
>
> ---
> gcc/config/rs6000/rs6000.cc | 495 ++--
> 1 file changed, 249 insertions(+), 246 deletions(-)
>
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index d10d22a5816..43681d9eb08 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -5522,24 +5522,22 @@
> rs6000_cost_data::determine_suggested_unroll_factor (loop_vec_info
> loop_vinfo)
> to vectorize it with the unrolled VF any more if the actual
> iteration
> count is in between. */
> return 1;
> - else
> -{
> - unsigned int epil_niter_unr = est_niter % unrolled_vf;
> - unsigned int epil_niter = est_niter % vf;
> - /* Even if we have partial vector support, it can be still
> inefficent
> -to calculate the length when the iteration count is unknown, so
> -only expect it's good to unroll when the epilogue iteration count
> -is not bigger than VF (only one time length calculation). */
> - if (LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
> - && epil_niter_unr <= vf)
> - return uf;
> - /* Without partial vector support, conservatively unroll this when
> -the epilogue iteration count is less than the original one
> -(epilogue execution time wouldn't be longer than before). */
> - else if (!LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
> - && epil_niter_unr <= epil_niter)
> - return uf;
> -}
> +
> + unsigned int epil_niter_unr = est_niter % unrolled_vf;
> + unsigned int epil_niter = est_niter % vf;
> + /* Even if we have partial vector support, it can be still inefficent
> + to calculate the length when the iteration count is unknown, so
> + only expect it's good to unroll when the epilogue iteration count
> + is not bigger than VF (only one time length calculation). */
> + if (LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo) && epil_niter_unr
> <= vf)
> +return uf;
> +
> + /* Without partial vector support, conservatively unroll this when
> + the epilogue iteration count is less than the original one
> + (epilogue execution time wouldn't be longer than before). */
> + if (!LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
> + && epil_niter_unr <= epil_niter)
> +return uf;
>
>return 1;
> }
> @@ -6044,35 +6042,31 @@ num_insns_constant_gpr (HOST_WIDE_INT value)
> return 1;
>
>/* constant loadable with addis */
> - else if ((value & 0x) == 0
> - && (value >> 31 == -1 || value >> 31 == 0))
> + if ((value & 0x) == 0 && (value >> 31 == -1 || value >> 31 == 0))
> return 1;
>
>/* PADDI can support up to 34 bit signed integers. */
> - else if (TARGET_PREFIXED && SIGNED_INTEGER_34BIT_P (value))
> + if (TARGET_PREFIXED && SIGNED_INTEGER_34BIT_P (value))
> return 1;
>
> - else if (TARGET_POWERPC64)
> -{
> - HOST_WIDE_INT low = sext_hwi (value, 32);
> - HOST_WIDE_INT high = value >> 31;
> + if (!TARGET_POWERPC64)
> +return 2;
>
> - if (high == 0 || high == -1)
> - return 2;
> + /* TARGET_POWERPC64 */
> + HOST_WIDE_INT low = sext_hwi (value, 32);
> + HOST_WIDE_INT high = value >> 31;
> +
> + if (h
Re: [PATCH] PR target/111778 - Fix undefined shifts in PowerPC compiler
On Thu, Oct 12, 2023 at 4:24 AM Michael Meissner
wrote:
> I was building a cross compiler to PowerPC on my x86_86 workstation with
> the
> latest version of GCC on October 11th. I could not build the compiler on
> the
> x86_64 system as it died in building libgcc. I looked into it, and I
> discovered the compiler was recursing until it ran out of stack space. If
> I
> build a native compiler with the same sources on a PowerPC system, it
> builds
> fine.
>
> I traced this down to a change made around October 10th:
>
> | commit 8f1a70a4fbcc6441c70da60d4ef6db1e5635e18a (HEAD)
> | Author: Jiufu Guo
> | Date: Tue Jan 10 20:52:33 2023 +0800
> |
> | rs6000: build constant via li/lis;rldicl/rldicr
> |
> | If a constant is possible left/right cleaned on a rotated value from
> | a negative value of "li/lis". Then, using "li/lis ; rldicl/rldicr"
> | to build the constant.
>
> The code was doing a -1 << 64 which is undefined behavior because different
> machines produce different results. On the x86_64 system, (-1 << 64)
> produces
> -1 while on a PowerPC 64-bit system, (-1 << 64) produces 0. The x86_64
> then
> recurses until the stack runs out of space.
>
> If I apply this patch, the compiler builds fine on both x86_64 as a PowerPC
> crosss compiler and on a native PowerPC system.
>
> Can I check this into the master branch to fix the problem?
>
Thanks for finding and debugging this problem. This is okay.
Thanks, David
>
> 2023-10-12 Michael Meissner
>
> gcc/
>
> PR target/111778
> * config/rs6000/rs6000.cc (can_be_built_by_li_lis_and_rldicl):
> Protect
> code from shifts that are undefined.
> (can_be_built_by_li_lis_and_rldicr): Likewise.
> (can_be_built_by_li_and_rldic): Protect code from shifts that
> undefined. Also replace uses of 1ULL with HOST_WIDE_INT_1U.
>
> ---
> gcc/config/rs6000/rs6000.cc | 29 ++---
> 1 file changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index 2828f01413c..cc24dd5301e 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -10370,6 +10370,11 @@ can_be_built_by_li_lis_and_rldicl (HOST_WIDE_INT
> c, int *shift,
>/* Leading zeros may be cleaned by rldicl with a mask. Change leading
> zeros
> to ones and then recheck it. */
>int lz = clz_hwi (c);
> +
> + /* If lz == 0, the left shift is undefined. */
> + if (!lz)
> +return false;
> +
>HOST_WIDE_INT unmask_c
> = c | (HOST_WIDE_INT_M1U << (HOST_BITS_PER_WIDE_INT - lz));
>int n;
> @@ -10398,6 +10403,11 @@ can_be_built_by_li_lis_and_rldicr (HOST_WIDE_INT
> c, int *shift,
>/* Tailing zeros may be cleaned by rldicr with a mask. Change tailing
> zeros
> to ones and then recheck it. */
>int tz = ctz_hwi (c);
> +
> + /* If tz == HOST_BITS_PER_WIDE_INT, the left shift is undefined. */
> + if (tz >= HOST_BITS_PER_WIDE_INT)
> +return false;
> +
>HOST_WIDE_INT unmask_c = c | ((HOST_WIDE_INT_1U << tz) - 1);
>int n;
>if (can_be_rotated_to_lowbits (~unmask_c, 15, &n)
> @@ -10428,8 +10438,15 @@ can_be_built_by_li_and_rldic (HOST_WIDE_INT c,
> int *shift, HOST_WIDE_INT *mask)
> right bits are shifted as 0's, and left 1's(and x's) are cleaned. */
>int tz = ctz_hwi (c);
>int lz = clz_hwi (c);
> +
> + /* If lz == HOST_BITS_PER_WIDE_INT, the left shift is undefined. */
> + if (lz >= HOST_BITS_PER_WIDE_INT)
> +return false;
> +
>int middle_ones = clz_hwi (~(c << lz));
> - if (tz + lz + middle_ones >= ones)
> + if (tz + lz + middle_ones >= ones
> + && (tz - lz) < HOST_BITS_PER_WIDE_INT
> + && tz < HOST_BITS_PER_WIDE_INT)
> {
>*mask = ((1LL << (HOST_BITS_PER_WIDE_INT - tz - lz)) - 1LL) << tz;
>*shift = tz;
> @@ -10440,7 +10457,8 @@ can_be_built_by_li_and_rldic (HOST_WIDE_INT c, int
> *shift, HOST_WIDE_INT *mask)
>int leading_ones = clz_hwi (~c);
>int tailing_ones = ctz_hwi (~c);
>int middle_zeros = ctz_hwi (c >> tailing_ones);
> - if (leading_ones + tailing_ones + middle_zeros >= ones)
> + if (leading_ones + tailing_ones + middle_zeros >= ones
> + && middle_zeros < HOST_BITS_PER_WIDE_INT)
> {
>*mask = ~(((1ULL << middle_zeros) - 1ULL) << tailing_ones);
>*shift = tailing_ones + middle_zeros;
> @@ -10450,10 +10468,15 @@ can_be_built_by_li_and_rldic (HOST_WIDE_INT c,
> int *shift, HOST_WIDE_INT *mask)
>/* xx1..1xx: --> xx0..01..1xx: some 1's(following x's) are cleaned. */
>/* Get the position for the first bit of successive 1.
> The 24th bit would be in successive 0 or 1. */
> - HOST_WIDE_INT low_mask = (1LL << 24) - 1LL;
> + HOST_WIDE_INT low_mask = (HOST_WIDE_INT_1U << 24) - HOST_WIDE_INT_1U;
>int pos_first_1 = ((c & (low_mask + 1)) == 0)
> ? clz_hwi (c & low_mask)
> : HOST_BITS_PER_WIDE_INT - ctz_hwi (~(c | low_mask));
> +
> + /* Make s
Re: [PATCH v2] swap: Fix incorrect lane extraction by vec_extract() [PR106770]
Hi, Surya
Thanks for working on this issue and creating a patch.
It helps if you explicitly send patches to Segher and me, and copy gcc-patches.
+/* Return true if insn is a non-permuting load/store. */
+static bool
+non_permuting_mem_insn (swap_web_entry *insn_entry, unsigned int i)
+{
+ return (insn_entry[i].special_handling == SH_NOSWAP_LD ||
+ insn_entry[i].special_handling == SH_NOSWAP_ST);
+}
The logical operator || should be at the beginning of the line, not
the end. That also ensures correct formatting and indentation. The
|| should be under the "i" of insn on the line above.
It also generally simplifies review to have the ChangeLog in the same
order as changes in the file. The order of the files relative to the
patch may not be the same, but the ChangeLog entries should be in
sequential order relative to the file.
This patch is okay with the logical operator formatting change.
Thanks, David
Re: [PATCH v2] swap: Fix incorrect lane extraction by vec_extract() [PR106770]
[Resending from correct email.]
Hi, Surya
Thanks for working on this issue and creating a patch.
It helps if you explicitly send patches to Segher and me, and copy
gcc-patches.
+/* Return true if insn is a non-permuting load/store. */
+static bool
+non_permuting_mem_insn (swap_web_entry *insn_entry, unsigned int i)
+{
+ return (insn_entry[i].special_handling == SH_NOSWAP_LD ||
+ insn_entry[i].special_handling == SH_NOSWAP_ST);
+}
The logical operator || should be at the beginning of the line, not
the end. That also ensures correct formatting and indentation. The
|| should be under the "i" of insn on the line above.
It also generally simplifies review to have the ChangeLog in the same
order as changes in the file. The order of the files relative to the
patch may not be the same, but the ChangeLog entries should be in
sequential order relative to the file.
This patch is okay with the logical operator formatting change.
Thanks, David
Re: [PATCH, rs6000] Fix AIX test case failures
On Mon, Jun 25, 2018 at 1:04 PM Segher Boessenkool
wrote:
>
> On Mon, Jun 25, 2018 at 09:53:17AM -0700, Carl Love wrote:
> > On Mon, 2018-06-25 at 04:44 -0500, Segher Boessenkool wrote:
> > > On Fri, Jun 22, 2018 at 02:55:44PM -0700, Carl Love wrote:
> > > > --- a/gcc/testsuite/gcc.target/powerpc/divkc3-2.c
> > > > +++ b/gcc/testsuite/gcc.target/powerpc/divkc3-2.c
> > > > @@ -13,4 +13,5 @@ divide (cld_t *p, cld_t *q, cld_t *r)
> > > >*p = *q / *r;
> > > > }
> > > >
> > > > -/* { dg-final { scan-assembler "bl __divkc3" } } */
> > > > +/* { dg-final { scan-assembler "bl __divkc3" { target { powerpc*-
> > > > *-linux* } } } } */
> > > > +/* { dg-final { scan-assembler "bl .__divdc3" { target { powerpc*-
> > > > *-aix* } } } } */
> > >
> > > Should it be calling __divdc3 on AIX, is that correct?
> >
> > I was a bit surprised that it wasn't calling divkc3. I am guessing
> > these are library routines we are calling? I couldn't find the source
> > code for them and don't really know what the difference is between
> > divkc3 and divdc3.
>
> divkc3 is for KCmode, that is the complex mode for KFmode (128-bit IEEE).
> divdc3 is for DCmode, that is the complex mode for DFmode (64-bit IEEE,
> that is, "double").
>
> I think this is the same as PR82625, for which I have a patch in testing.
>
> > So, not sure why AIX and Linux are not calling the name for the
> > function or if what is being called is functionally equivalent?
>
> AIX uses 64-bit long double by default, and GCC has a bug with that and
> -mabi=ieeelongdouble and __ieee128.
>
> It thinks __ieee128 is the same as long double if it has -mabi=ieeelongdouble,
> but that is not always true. So it ends up using the long double type for
> __ieee128, but that is just double precision float in this case.
On AIX it would be calling divtc3, but AIX defaults to 64 bit long
double. Either all of these tests need
/* { dg-require-effective-target longdouble128 } */
or
/* { dg-additional-options "-mlong-double-128" { target powerpc-ibm-aix* } } */
along with testing for "tc", e.g., bl .__divtc3
Thanks, David
Re: [PATCH, rs6000] Fix AIX test case failures
On Fri, Jul 13, 2018 at 7:15 PM Carl Love wrote:
>
> On Fri, 2018-07-13 at 16:00 -0500, Segher Boessenkool wrote:
> > On Fri, Jul 13, 2018 at 10:51:24AM -0400, David Edelsohn wrote:
> > > On AIX it would be calling divtc3, but AIX defaults to 64 bit long
> > > double. Either all of these tests need
> > >
> > > /* { dg-require-effective-target longdouble128 } */
> > >
> > > or
> > >
> > > /* { dg-additional-options "-mlong-double-128" { target powerpc-
> > > ibm-aix* } } */
> > >
> > > along with testing for "tc", e.g., bl .__divtc3
> >
> > Which would you prefer David? (I'd do the former).
> >
> >
> > Segher
> >
>
> Segher, David:
>
> I reworked the patch per the first option that David gave. The tests
> divkc3-2.c, divkc3-3.c, mulkc3-2.c and mulkc3-3.c pass on Power 9 Linux
> as they did before. The tests are unsupported on Power8 Linux as they
> were before. Now, the tests are reported as unsupported on AIX rather
> then failing on AIX.
>
> Please let me know if you both approve the updated patch below. Thanks
> for the input and help on this.
>
>Carl Love
>
> ---
>
> gcc/testsuite/ChangeLog:
>
> 2018-07-13 Carl Love
>
> * gcc.target/powerpc/divkc3-2.c: Add dg-require-effective-target
> longdouble128.
> * gcc.target/powerpc/divkc3-3.c: Ditto.
> * gcc.target/powerpc/mulkc3-2.c: Ditto.
> * gcc.target/powerpc/mulkc3-3.c: Ditto.
> * gcc.target/powerpc/fold-vec-mergehl-double.c: Update counts.
> * gcc.target/powerpc/pr85456.c: Make check Linux and AIX specific.
> ---
> gcc/testsuite/gcc.target/powerpc/divkc3-2.c| 1 +
> gcc/testsuite/gcc.target/powerpc/divkc3-3.c| 1 +
> gcc/testsuite/gcc.target/powerpc/fold-vec-mergehl-double.c | 4 +---
> gcc/testsuite/gcc.target/powerpc/mulkc3-2.c| 1 +
> gcc/testsuite/gcc.target/powerpc/mulkc3-3.c| 1 +
> gcc/testsuite/gcc.target/powerpc/pr85456.c | 3 ++-
> 6 files changed, 7 insertions(+), 4 deletions(-)
Hi, Carl
This is essentially what I have been testing with today.
This is okay.
Thanks, David
[PATCH, testsuite] Restrict some PPC tests
Two of the powerpc testcases have additional requirements. Fixed thus.
Thanks, David
* gcc.target/powerpc/pr57150.c: Require longdouble128.
* gcc.target/powerpc/pr79916.c: Require dfp.
Index: pr79916.c
===
--- pr79916.c (revision 262824)
+++ pr79916.c (working copy)
@@ -1,4 +1,5 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target dfp } */
/* { dg-options "-fno-expensive-optimizations --param
ira-max-conflict-table-size=0 -mno-popcntd -O3" } */
#define PASTE2(A,B) A ## B
Index: pr57150.c
===
--- pr57150.c (revision 262824)
+++ pr57150.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-require-effective-target longdouble128 } */
/* { dg-require-effective-target powerpc_vsx_ok } */
/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*"
} { "-mcpu=power7" } } */
/* { dg-options "-O3 -mcpu=power7 -fcaller-saves" } */
[PATCH, testsuite] PPC testsuite pr85456.c
And another test that needs to be restricted because it assumes 128
bit long double.
Thanks, David
* gcc.target/powerpc/pr85456.c: Require longdouble128.
Index: pr85456.c
===
--- pr85456.c (revision 262824)
+++ pr85456.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-require-effective-target longdouble128 } */
/* { dg-options "-O2 -mpower8-vector -mabi=ieeelongdouble -Wno-psabi" } */
/* Check that the __builtin_powil generates a call to the correct function
[PATCH,fixincludes] AIX unistd header
AIX unistd.h defines a static function without a parameter, which
justifiably upsets C++ code when the header is included and
referenced. This patch to fixincludes adjusts the header to declare
the parameter as void.
Bootstrapped on powerpc-ibm-aix7.2.0.0 and powerpc64le-linux
Thanks, David
* inclhack.def (aix_unistd): New.
* fixincl.x: Regenerate.
* tests/base/unistd.h [AIX_UNISTD_CHECK]: New test.
Index: inclhack.def
===
--- inclhack.def(revision 262934)
+++ inclhack.def(working copy)
@@ -924,6 +924,20 @@
};
/*
+ * AIX unistd.h defines a static function with an empty parameter list.
+ */
+fix = {
+hackname = aix_unistd;
+mach = "*-*-aix*";
+files = unistd.h;
+
+select= "[ \t]+static[ \t]+int[ \t]+getdtablesize\\(\\)";
+c_fix = format;
+c_fix_arg = "\tstatic int\t\tgetdtablesize(void)";
+test_text = " static int getdtablesize()";
+};
+
+/*
* Fix __assert declaration in assert.h on Alpha OSF/1.
*/
fix = {
Re: Build fail on gthr-simple.h targets (Re: AsyncI/O patch committed)
> Ulrich Weigand wrote: > Nicholas Koenig wrote: > >> Hello everyone, >> >> I have committed the async I/O patch as r262978. >> >> The test cases are in libgomp.fortran for now, maybe that can be changed >> later. > > It looks like this broke building libgfortran on spu, and presumably > any platform that uses gthr-simple instead of gthr-posix. Yes, this broke bootstrap for AIX as well. - David
Re: Build fail on gthr-simple.h targets (Re: AsyncI/O patch committed)
Thomas, Correct, the proposed patch does not fix the build failure on AIX. Please see the information on the GCC Compile Farm wiki page for instructions to bootstrap on gcc119. https://gcc.gnu.org/wiki/CompileFarm#Projects_Ideas - at the bottom of Project ideas. Thanks, David On Fri, Jul 27, 2018 at 3:30 AM Thomas Koenig wrote: > > Am 26.07.2018 um 22:54 schrieb Thomas Koenig: > > Hi Ulrich, > > > >> The problem is that io/asynch.h unconditionally uses a couple of > >> features that are not provided by gthr-simplex, in particular > >>__gthread_cond_t > >> and > >>__gthread_equal / __gthread_self > >> > >> According to the documentation in gthr.h, the former is only available > >> if __GTHREAD_HAS_COND is defined, and the latter are only available if > >> __GTHREADS_CXX0X is defined. Neither is true for gthr-simple.h. > > > > Thanks for the analysis, and the pointer to the macros. > > > > Because the functionality depends on these features, it is best to > > remove them if it is not present. So, here is a patch which does > > just that. > > > > This was reg-tested on Linux, which showed that the functionality is > > still there. I tried bootstrapping on AIX on gcc119, but this failed > > due to an unrelated issue (problem with compiling the inline > > libraries). > > > > OK, this does not work. > > We have found a method of checking on Linux, and this does not work. > We have also found a way of working in the next couple of days, so > expect an update in one or two days. > > If that is too much time, feel free to revert the async patch > in the meantime. > > Regards > > Thomas
Re: [PATCH v3] Control flow redundancy hardening
This patch broke bootstrap on AIX because ASM_GENERATE_INTERNAL_LABEL can embed target-specific functions. Fixed by including tm_p.h. Thanks, David * gimple-harden-control-flow.cc: Include tm_p.h. *diff --git a/gcc/gimple-harden-control-flow.cc b/gcc/gimple-harden-control-flow.cc* *index 5c28fd07f33..1b345dab766 100644* *--- a/gcc/gimple-harden-control-flow.cc* *+++ b/gcc/gimple-harden-control-flow.cc* @@ -23,6 +23,7 @@ along with GCC; see the file COPYING3. If not see #include "system.h" #include "coretypes.h" #include "backend.h" +#include "tm_p.h" #include "tree.h" #include "fold-const.h" #include "gimple.h"
Re: [PATCH v3] Control flow redundancy hardening
SPARC target header requires memmodel.h. David * gimple-harden-control-flow.cc: Include memmodel.h. *diff --git a/gcc/gimple-harden-control-flow.cc b/gcc/gimple-harden-control-flow.cc* *index 1b345dab766..441df5ac21c 100644* *--- a/gcc/gimple-harden-control-flow.cc* *+++ b/gcc/gimple-harden-control-flow.cc* @@ -23,6 +23,7 @@ along with GCC; see the file COPYING3. If not see #include "system.h" #include "coretypes.h" #include "backend.h" +#include "memmodel.h" #include "tm_p.h" #include "tree.h" #include "fold-const.h" On Fri, Oct 20, 2023 at 2:18 PM David Edelsohn wrote: > This patch broke bootstrap on AIX because ASM_GENERATE_INTERNAL_LABEL can > embed target-specific functions. Fixed by including tm_p.h. > > Thanks, David > > * gimple-harden-control-flow.cc: Include tm_p.h. > > > *diff --git a/gcc/gimple-harden-control-flow.cc > b/gcc/gimple-harden-control-flow.cc* > > *index 5c28fd07f33..1b345dab766 100644* > > *--- a/gcc/gimple-harden-control-flow.cc* > > *+++ b/gcc/gimple-harden-control-flow.cc* > > @@ -23,6 +23,7 @@ along with GCC; see the file COPYING3. If not see > > #include "system.h" > > #include "coretypes.h" > > #include "backend.h" > > +#include "tm_p.h" > > #include "tree.h" > > #include "fold-const.h" > > #include "gimple.h" >
Re: [PATCH] PR85678: Change default to -fno-common
>> Has this been bootstrapped and regression tested? > > Yes, it bootstraps OK of course. I ran regression over the weekend, there > are a few minor regressions in lto due to relying on tentative definitions > and a few latent bugs. I'd expect there will be a few similar failures on > other targets but nothing major since few testcases rely on -fcommon. This almost certainly will break AIX. - David
[PATCH] ggc-common.c bootstrap breakage
The change to add malloc.h to ggc-common.c broke bootstrap. system.h must be included before system header files. The following patch fixes this, committed as obvious with concurrence by Richi. Thanks, David * ggc-common.c: Include system.h before malloc.h. Index: ggc-common.c === --- ggc-common.c(revision 27) +++ ggc-common.c(working copy) @@ -21,10 +21,10 @@ any particular GC implementation. */ #include "config.h" +#include "system.h" #ifdef HAVE_MALLINFO #include #endif -#include "system.h" #include "coretypes.h" #include "timevar.h" #include "diagnostic-core.h"
Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.
Jason, There is no ChangeLog entry for the testsuite changes. I'm also still trying to determine if Wconversion-pr40752.c requires -fsigned-char option. Thanks, David
Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.
On Fri, Jan 24, 2020 at 12:00 PM Jason Merrill wrote: > > On 1/24/20 8:45 AM, David Edelsohn wrote: > > There is no ChangeLog entry for the testsuite changes. > > I don't believe in ChangeLog entries for testcases, but I'll add one for > the target-supports.exp change, thanks. Is this a general policy change that we want to make? Current we still have gcc/testsuite/ChangeLog and developers are updating that file. Thanks, David
Re: SPARC build broken
Sorry. I had to add tm_p.h because Jakub's earlier patch to add output.h to cp-gimplify.c broke AIX. We certainly can add memmodel.h to cp-gimplify.c. Thanks, David On Thu, Dec 5, 2019 at 8:32 AM Joseph Myers wrote: > > The change > > 2019-12-04 David Edelsohn > > * cp-gimplify.c: Include tm_p.h. > > appears to have broken the build for SPARC. I see > > In file included from ./tm_p.h:4:0, > from > /scratch/jmyers/glibc-bot/src/gcc/gcc/cp/cp-gimplify.c:38: > /scratch/jmyers/glibc-bot/src/gcc/gcc/config/sparc/sparc-protos.h:45:47: > error: use of enum 'memmodel' without previous declaration > extern void sparc_emit_membar_for_model (enum memmodel, int, int); > > with my glibc bot. It's possible this declaration ought to be inside > #ifdef RTX_CODE - that appears to be what other architectures' > -protos.h files do with all their declarations using enum memmodel. > > https://sourceware.org/ml/libc-testresults/2019-q4/msg00300.html > > -- > Joseph S. Myers > jos...@codesourcery.com
Re: SPARC build broken
Done. r279003. - David On Thu, Dec 5, 2019 at 9:33 AM Jakub Jelinek wrote: > > On Thu, Dec 05, 2019 at 09:25:40AM -0500, David Edelsohn wrote: > > Sorry. I had to add tm_p.h because Jakub's earlier patch to add > > output.h to cp-gimplify.c broke AIX. > > > > We certainly can add memmodel.h to cp-gimplify.c. > > I'd say so. E.g. c-family/c-cppbuiltin.c which also includes output.h > includes "memmodel.h" and "tm_h.h" in that order for the same reason > (since r241121). > > Jakub >
Re: Bountysource campaign for gcc-rust?
> John Paul Adrian Glaubitz wrote: > The programming language Rust has become very popular over the past few years > with many projects rewriting parts of their codebase in that language. While > these rewrites often make the code perform faster and potentially safer, using > Rust makes these projects less portable as Rust is limited to the > architectures > supported by LLVM which are less than the ones supported by GCC. > > For this reason, people have been asking for a Rust frontend for GCC similar > to > the one for Go. Now, there are actually two independent implementation of a > Rust > frontend for GCC [1, 2] being developed and I was wondering whether it would > be > desirable to help this development with a Bountysource campaign? > > I'm asking because I'm not sure whether GCC upstream would be okay having a > Rust > frontend in GCC at all and, if yes, it would be okay to have a Bountysource > campaign > for that project? > > I personally like the idea of a Rust frontend for GCC very much as I expect > more > software projects in the future to adopt Rust and I would like to be able to > build > and use these projects on architectures that LLVM doesn't support yet (and > might > not even in the future). > > Due to the popularity of Rust and the desire of the community for an > independent > implementation, I expect the Bountysource campaign to be rather successful. The earlier, public discussions about a Rust front-end were open and welcoming. The GCC Community and GCC Steering Committee would be happy to consider a Rust front-end that can be contributed and accepted into GCC and is maintainable. As David Malcolm previously commented, something similar to the adaptor for GCC Go or an adaptor for rustc seems the most productive approach. GCC gains nothing by creating unnecessary barriers to support for popular programming languages. Thanks, David
Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100]
If the fixes remove the failures on AIX, then the patch to disable the tests also can be reverted. Thanks, David On Wed, Jan 17, 2024 at 8:06 PM Alexandre Oliva wrote: > David, > > On Jan 7, 2024, "Kewen.Lin" wrote: > > > As PR113100 shows, the unbiasing introduced by r14-6737 can > > cause the scrubbing to overrun and screw some critical data > > on stack like saved toc base consequently cause segfault on > > Power. > > I suppose this problem that Kewen fixed (thanks) was what caused you to > install commit r14-6838. According to posted test results, strub worked > on AIX until Dec 20, when the fixes for sparc that broke strub on ppc > went in. > > I can't seem to find the email in which you posted the patch, and I'd > have appreciated if you'd copied me. I wouldn't have missed it for so > long if you had. Since I couldn't find that patch, I'm responding in > this thread instead. > > The r14-6838 patch is actually very very broken. Disabling strub on a > target is not a matter of changing only the testsuite. Your additions > to the tests even broke the strub-unsupported testcases, that tested > exactly the feature that enables ports to disable strub in a way that > informs users in case they attempt to use it. > > I'd thus like to revert that patch. > > Kewen's patch needs a little additional cleanup, that I'm preparing now, > to restore fully-functioning strub on sparc32. > > Please let me know in case you observe any other problems related with > strub. I'd be happy to fix them, but I can only do so once I'm aware of > them. > > In case the reversal or the upcoming cleanup has any negative impact, > please make sure you let me know. > > Thanks, > > Happy GNU Year! > > -- > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ >Free Software Activist GNU Toolchain Engineer > More tolerance and less prejudice are key for inclusion and diversity > Excluding neuro-others for not behaving ""normal"" is *not* inclusive >
Re: [committed] libstdc++: Implement C++23 header [PR107760]
Hi, Jonathan
Unfortunately this patch broke bootstrap on AIX.
In file included from /tmp/GCC/gcc/include-fixed/wchar.h:64,
from
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/cwchar:44,
from
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/bits/postypes.h:40,
from
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/bits/char_traits.h:42,
from
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/string:42,
from
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++23/print.cc:26:
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++23/print.cc: In function
'void* std::__open_terminal(FILE*)':
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++23/print.cc:78:24: error:
expected id-expression before '(' token
78 | if (int fd = ::fileno(f); fd >= 0 && ::isatty(fd))
|^~
make[6]: *** [Makefile:747: print.lo] Error 1
AIX stdio.h defines fileno as a macro although there is a symbol in libc.
I think that print.cc at least needs to
#undef fileno
before the usage.
Thanks, David
Re: [committed] libstdc++: Implement C++23 header [PR107760]
On Sat, Dec 16, 2023 at 4:44 PM Jakub Jelinek wrote: > On Sat, Dec 16, 2023 at 04:24:13PM -0500, David Edelsohn wrote: > > AIX stdio.h defines fileno as a macro although there is a symbol in libc. > > > > I think that print.cc at least needs to > > > > > > #undef fileno > > > > > > before the usage. > > Or (::fileno)(f) ? > Yes, that also avoids the error. Thanks, David > > Jakub > >
Re: [committed] libstdc++: Implement C++23 header [PR107760]
On Sat, Dec 16, 2023 at 7:04 PM Jonathan Wakely wrote: > On Sun, 17 Dec 2023 at 00:02, Jonathan Wakely wrote: > > > > On Sat, 16 Dec 2023 at 23:06, David Edelsohn wrote: > > > > > > On Sat, Dec 16, 2023 at 4:44 PM Jakub Jelinek > wrote: > > >> > > >> On Sat, Dec 16, 2023 at 04:24:13PM -0500, David Edelsohn wrote: > > >> > AIX stdio.h defines fileno as a macro although there is a symbol in > libc. > > >> > > > >> > I think that print.cc at least needs to > > >> > > > >> > > > >> > #undef fileno > > >> > > > >> > > > >> > before the usage. > > >> > > >> Or (::fileno)(f) ? > > > > > > > > > Yes, that also avoids the error. > > > > Yup, I've just tested it. I'll push that change in the morning. > > Actually I just pushed it now. The functions in that file are only > actually used on Windows, so if they build on linux and AIX, that's > good enough. > Thanks. I had tested and was just about to push it myself. Thanks, David
Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime
Alex, This patch broke bootstrap on AIX. The stage1 compiler is not able to build a program and stage2 configure fails. Thanks, David
Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime
The error is: ld: 0711-317 ERROR: Undefined symbol: __cxa_thread_atexit_impl from the new, weak reference. Also, earlier in atexit_thread.cc, there is another definition protected by _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL not utilized by the new reference. Thanks, David On Tue, Dec 5, 2023 at 11:10 AM David Edelsohn wrote: > Alex, > > This patch broke bootstrap on AIX. The stage1 compiler is not able to > build a program and stage2 configure fails. > > Thanks, David > >
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
Arsen, Unfortunately this broke bootstrap on AIX. I had not seen this series of patches. David
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
On Tue, Nov 14, 2023 at 6:09 PM Arsen Arsenović wrote: > Hi David, > > David Edelsohn writes: > > > Arsen, > > > > Unfortunately this broke bootstrap on AIX. > > > > I had not seen this series of patches. > > I've added Bruno to CC as the libintl maintainer, to keep him in the > loop. Could you provide some extra information w.r.t. the failure mode? > > I'll try to investigate ASAP. > > In the meanwhile, does disabling NLS etc work? > > Thanks in advance, have a lovely night. > > GCC had been working on AIX with NLS, using "--with-included-gettext". --disable-nls gets past the breakage, but GCC does not build for me on AIX with NLS enabled. A change in dependencies for GCC should have been announced and more widely socialized in the GCC development mailing list, not just GCC patches mailing list. I have tried both the AIX Open Source libiconv and libgettext package, and the ones that I previously built. Both fail because GCC configure decides to disable NLS, despite being requested, while libcpp is satisfied, so tools in the gcc subdirectory don't link against libiconv and the build fails. With the included gettext, I was able to rely on a self-consistent solution. The current gettext-0.22.3 fails to build for me on AIX. libcpp configure believes that NLS functions on AIX, but gcc configure fails in its tests of gettext functionality, which leads to an inconsistent configuration and build breakage. Thanks, David
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
On Wed, Nov 15, 2023 at 9:22 AM Arsen Arsenović wrote: > > David Edelsohn writes: > > > GCC had been working on AIX with NLS, using "--with-included-gettext". > > --disable-nls gets past the breakage, but GCC does not build for me on > AIX > > with NLS enabled. > > That should still work with gettext 0.22+ extracted in-tree (it should > be fetched by download_prerequisites). > > > A change in dependencies for GCC should have been announced and more > widely > > socialized in the GCC development mailing list, not just GCC patches > > mailing list. > > > > I have tried both the AIX Open Source libiconv and libgettext package, > and > > the ones that I previously built. Both fail because GCC configure > decides > > to disable NLS, despite being requested, while libcpp is satisfied, so > > tools in the gcc subdirectory don't link against libiconv and the build > > fails. With the included gettext, I was able to rely on a > self-consistent > > solution. > > That is interesting. They should be using the same checks. I've > checked trunk and regenerated files on it, and saw no significant diff > (some whitespace changes only). Could you post the config.log of both? > > I've never used AIX. Can I reproduce this on one of the cfarm machines > to poke around? I've tried cfarm119, but that one lacked git, and I > haven't poked around much further due to time constraints. > The AIX system in the Compile Farm has a complete complement of Open Source software installed. Please ensure that /opt/freeware/bin is in your path. Also, the GCC Wiki Compile Farm page has build tips that include AIX https://gcc.gnu.org/wiki/CompileFarm#Services_and_software_installed_on_farm_machines that recommended --with-included-gettext configuration option. Thanks, David > > TIA, sorry about the inconvenience. Have a lovely day. > > > The current gettext-0.22.3 fails to build for me on AIX. > > > > libcpp configure believes that NLS functions on AIX, but gcc configure > > fails in its tests of gettext functionality, which leads to an > inconsistent > > configuration and build breakage. > > > > Thanks, David > > > -- > Arsen Arsenović >
Re: building GNU gettext on AIX
When I try to configure gettext-0.22.3, I receive the following error:
checking for socklen_t equivalent... configure: error: Cannot find a type
to use in place of socklen_t
configure: error:
/nasfarm/edelsohn/src/gettext-0.22.3/libtextstyle/configure failed for
libtextstyle
configure:43943: /nasfarm/edelsohn/install/GCC12/bin/gcc -c -g -O2
-D_THREAD_SAFE
conftest.c >&5
conftest.c:112:18: error: two or more data types in declaration specifiers
112 | #define intmax_t long long
| ^~~~
conftest.c:112:23: error: two or more data types in declaration specifiers
112 | #define intmax_t long long
| ^~~~
In file included from conftest.c:212:
conftest.c:214:24: error: conflicting types for 'ngetpeername'; have
'int(int, void *, long unsigned int *)'
214 |int getpeername (int, void *, unsigned long int
*);
|^~~
/nasfarm/edelsohn/install/GCC12/lib/gcc/powerpc-ibm-aix7.2.5.0/12.1.1/include-fixed/sys/socket.h:647:9:
note: previous declaration of 'ngetpeername' with type 'int(int, struct
sockaddr * restrict, socklen_t * restrict)' {aka 'int(int, struct
sockaddr * restrict, long unsigned int * restrict)'}
647 | int getpeername(int, struct sockaddr *__restrict__, socklen_t
*__restrict__);
| ^~~
configure and config.h seems to get itself confused about types.
David
On Wed, Nov 15, 2023 at 7:29 AM Bruno Haible wrote:
> [CCing bug-gettext]
>
> David Edelsohn wrote in
> <https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636558.html>:
> > The current gettext-0.22.3 fails to build for me on AIX.
>
> Here are some hints to get a successful build of GNU gettext on AIX:
>
> 1. Set the recommended environment variables before running configure:
>https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration
>
>Namely:
>* for a 32-bit build with gcc:
> CC=gcc
> CXX=g++
> CPPFLAGS="-I$PREFIX/include"
> LDFLAGS="-L$PREFIX/lib"
> unset AR NM
>* for a 32-bit build with xlc:
> CC="xlc -qthreaded -qtls"
> CXX="xlC -qthreaded -qtls"
> CPPFLAGS="-I$PREFIX/include"
> LDFLAGS="-L$PREFIX/lib"
> unset AR NM
>* for a 64-bit build with gcc:
> CC="gcc -maix64"
> CXX="g++ -maix64"
> CPPFLAGS="-I$PREFIX/include"
> LDFLAGS="-L$PREFIX/lib"
> AR="ar -X 64"; NM="nm -X 64 -B"
>* for a 64-bit build with xlc:
> CC="xlc -q64 -qthreaded -qtls"
> CXX="xlC -q64 -qthreaded -qtls"
> CPPFLAGS="-I$PREFIX/include"
> LDFLAGS="-L$PREFIX/lib"
> AR="ar -X 64"; NM="nm -X 64 -B"
>
>where $PREFIX is the value that you pass to the --prefix configure
> option.
>
>Rationale: you can run into all sorts of problems if you choose compiler
>options at random and haven't experience with compiler options on that
>platform.
>
> 2. Don't use ibm-clang.
>
>Rationale: It's broken.
>
> 3. Don't use -Wall with gcc 10.3.
>
>Rationale: If you specify -Wall, gettext's configure adds -fanalyzer,
> which
>has excessive memory requirements in gcc 10.x. In particular, on AIX, it
>makes cc1 crash while compiling regex.c after it has consumed 1 GiB of
> RAM.
>
> 4. Avoid using a --prefix that contains earlier installations of the same
>package.
>
>Rationale: Because the AIX linker hardcodes directory names in shared
>libraries, GNU libtool has a peculiar configuration on AIX. It ends up
>mixing the in-build-tree libraries with the libraries in the install
>locations, leading to all sorts of errors.
>
>If you really need to use a --prefix that contains an earlier
>installation of the same package:
> - Either use --disable-shared and remove libgettextlib.a and
>libgettextsrc.a from $PREFIX/lib before starting the build.
> - Or use a mix of "make -k", "make -k install" and ad-hoc workarounds
>that cannot be described in a general way.
>
> Bruno
>
>
>
>
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
On Wed, Nov 15, 2023 at 9:22 AM Arsen Arsenović wrote: > > David Edelsohn writes: > > > GCC had been working on AIX with NLS, using "--with-included-gettext". > > --disable-nls gets past the breakage, but GCC does not build for me on > AIX > > with NLS enabled. > > That should still work with gettext 0.22+ extracted in-tree (it should > be fetched by download_prerequisites). > > > A change in dependencies for GCC should have been announced and more > widely > > socialized in the GCC development mailing list, not just GCC patches > > mailing list. > > > > I have tried both the AIX Open Source libiconv and libgettext package, > and > > the ones that I previously built. Both fail because GCC configure > decides > > to disable NLS, despite being requested, while libcpp is satisfied, so > > tools in the gcc subdirectory don't link against libiconv and the build > > fails. With the included gettext, I was able to rely on a > self-consistent > > solution. > > That is interesting. They should be using the same checks. I've > checked trunk and regenerated files on it, and saw no significant diff > (some whitespace changes only). Could you post the config.log of both? > GCC configured with --with-libintl-prefix and --with-libiconv-prefix libcpp/config.log: configure:7610: checking for GNU gettext in libc configure:7639: /nasfarm/edelsohn/install/GCC12/bin/gcc -std=gnu99 -o conftest -g -static-libstdc++ -static-libgcc -Wl,-bbigtoc conftest.c >&5 conftest.c:71:10: fatal error: libintl.h: No such file or directory 71 | #include | ^~~ configure:8318: checking for GNU gettext in libintl configure:8355: /nasfarm/edelsohn/install/GCC12/bin/gcc -std=gnu99 -o conftest -g -I/nasfarm/edelsohn/install/include -static-libstdc++ -static-libgcc -Wl,-bbigtoc conftest.c /nasfarm/edelsohn/install/lib/ libintl.a >&5 ld: 0711-317 ERROR: Undefined symbol: .libiconv_open ld: 0711-317 ERROR: Undefined symbol: .libiconv_set_relocation_prefix ld: 0711-317 ERROR: Undefined symbol: .libiconv_close ld: 0711-317 ERROR: Undefined symbol: .libiconv ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status configure:8355: $? = 1 configure:8392: /nasfarm/edelsohn/install/GCC12/bin/gcc -std=gnu99 -o conftest -g -I/nasfarm/edelsohn/install/include -static-libstdc++ -static-libgcc -Wl,-bbigtoc conftest.c /nasfarm/edelsohn/install/lib/ libintl.a /nasfarm/edelsohn/install/lib/libiconv.a >&5 configure:8392: $? = 0 configure:8405: result: yes configure:8440: checking whether to use NLS configure:8442: result: yes configure:8445: checking where the gettext function comes from configure:8456: result: external libintl configure:8464: checking how to link with libintl configure:8466: result: /nasfarm/edelsohn/install/lib/libintl.a /nasfarm/edelsohn/install/lib/libiconv.a configure:8525: checking whether NLS is requested configure:8531: result: yes gcc/config.log: configure:14002: checking for GNU gettext in libc configure:14031: /nasfarm/edelsohn/install/GCC12/bin/g++ -std=c++11 -o conftest -g-static-libstdc++ -static-libgcc -Wl,-bbigtoc conftest.cpp >&5 conftest.cpp:196:10: fatal error: libintl.h: No such file or directory 196 | #include | ^~~ configure:14710: checking for GNU gettext in libintl configure:14747: /nasfarm/edelsohn/install/GCC12/bin/g++ -std=c++11 -o conftest -g-I/nasfarm/edelsohn/install/include -static-libstdc++ -static-libgcc -Wl,-bbigtoc conftest.cpp /nasfarm/edelsohn/install/lib/ libintl.a >&5 ld: 0711-317 ERROR: Undefined symbol: .libiconv_open ld: 0711-317 ERROR: Undefined symbol: .libiconv_set_relocation_prefix ld: 0711-317 ERROR: Undefined symbol: .libiconv_close ld: 0711-317 ERROR: Undefined symbol: .libiconv ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status configure:14747: $? = 1 configure:14797: result: no configure:14832: checking whether to use NLS configure:14834: result: no configure:14917: checking whether NLS is requested configure:14920: result: no > I've never used AIX. Can I reproduce this on one of the cfarm machines > to poke around? I've tried cfarm119, but that one lacked git, and I > haven't poked around much further due to time constraints. > > TIA, sorry about the inconvenience. Have a lovely day. > > > The current gettext-0.22.3 fails to build for me on AIX. > > > > libcpp configure believes that NLS functions on AIX, but gcc configure > > fails in its tests of gettext functionality, which leads to an > inconsistent > > configuration and build breakage. > > > > Thanks, David > > > -- > Arsen Arsenović >
Re: building GNU gettext on AIX
On Wed, Nov 15, 2023 at 4:22 PM Bruno Haible wrote:
> David Edelsohn wrote:
> > When I try to configure gettext-0.22.3, I receive the following error:
> >
> > checking for socklen_t equivalent... configure: error: Cannot find a type
> > to use in place of socklen_t
> >
> > configure: error:
> > /nasfarm/edelsohn/src/gettext-0.22.3/libtextstyle/configure failed for
> > libtextstyle
> >
> >
> > configure:43943: /nasfarm/edelsohn/install/GCC12/bin/gcc -c -g -O2
> > -D_THREAD_SAFE
> > conftest.c >&5
> >
> > conftest.c:112:18: error: two or more data types in declaration
> specifiers
> >
> > 112 | #define intmax_t long long
> >
> > | ^~~~
> >
> > conftest.c:112:23: error: two or more data types in declaration
> specifiers
> >
> > 112 | #define intmax_t long long
> >
> > | ^~~~
> >
> > In file included from conftest.c:212:
> >
> > conftest.c:214:24: error: conflicting types for 'ngetpeername'; have
> > 'int(int, void *, long unsigned int *)'
> >
> > 214 |int getpeername (int, void *, unsigned long
> int
> > *);
> >
> > |^~~
> >
> >
> /nasfarm/edelsohn/install/GCC12/lib/gcc/powerpc-ibm-aix7.2.5.0/12.1.1/include-fixed/sys/socket.h:647:9:
> > note: previous declaration of 'ngetpeername' with type 'int(int, struct
> > sockaddr * restrict, socklen_t * restrict)' {aka 'int(int, struct
> > sockaddr * restrict, long unsigned int * restrict)'}
> >
> > 647 | int getpeername(int, struct sockaddr *__restrict__, socklen_t
> > *__restrict__);
> >
> > | ^~~
> >
> >
> > configure and config.h seems to get itself confused about types.
>
> There seem to be two problems, both related to the include files of
> your compiler:
>
> - The configure test "checking for intmax_t..." must have found the
> answer "no". But on a modern system, should be defining
> intmax_t already.
>
> - This configure test that tries to find the getpeername declaration,
> but cannot find it (maybe because of the first problem?):
>
>
>
> for arg2 in "struct sockaddr" void; do
>for t in int size_t "unsigned int" "long int" "unsigned long
> int"; do
> cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> /* end confdefs.h. */
> #include
>#include
>
>int getpeername (int, $arg2 *, $t *);
> int
> main (void)
> {
> $t len;
> getpeername (0, 0, &len);
> ;
> return 0;
> }
> _ACEOF
> if ac_fn_c_try_compile "$LINENO"
> then :
> gl_cv_socklen_t_equiv="$t"
> fi
>
>
>
> I would concentrate on the first problem. If you don't get it fixed, then
> I'd
> suggest to try 'gcc' from the AIX Toolbox [1] or 'xlc' (as an IBM product)
> instead of 'gcc' (that looks like you built it yourself).
>
> Bruno
>
> [1]
> https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/SPECS/gcc12-12.3.0-1.spec
Bruno,
I am using my own install of GCC for a reason. The build of GCC works for
everything else, including bootstrap of GCC, GDB, GMP, etc. The only
problem is gettext.
Thanks, David
Re: building GNU gettext on AIX
Bruno, I have been able to tweak the environment and build gettext and libintl. With the updated libintl and environment, GCC reliably does not use NLS. The issue is that libintl utilizes pthreads. AIX does not provide no-op pthread stubs in libc. pthreads is an explicit multilib on AIX. It is great that gettext and libintl can be built thread-safe, but GCC (cc1, gcov, etc.) are not pthreads applications and are not built with pthreads. Because libintl defaults to pthreads enabled, NLS cannot function in GCC on AIX by default. The GCC included gettext was built in the default for GCC libraries, which was not pthreads enabled. I can rebuild libintl with --disable-pthreads and I will see if that works, but the default, distributed libintl library will not allow GCC to be built with NLS enabled. And, no, GCC on AIX should not be forced to build with pthreads. This is a regression in NLS support in GCC. Thanks, David On Wed, Nov 15, 2023 at 5:39 PM Bruno Haible wrote: > David Edelsohn wrote: > > I am using my own install of GCC for a reason. > > I have built GNU gettext 0.22.3 in various configurations on the AIX 7.1 > and 7.3 machines in the compilefarm, and haven't encountered issues with > 'max_align_t' nor with 'getpeername'. So, from my point of view, GNU > gettext > works fine on AIX with gcc and xlc (but not ibm-clang, which I haven't > tested). > > You will surely understand that I cannot test a release against a compiler > that exists only on your hard disk. > > The hint I gave you, based on the partial logs that you provided, is to > look at the configure test for intmax_t first. > > Bruno > > > >
Re: building GNU gettext on AIX
I configured gettext with --disable-pthreads and libintl.a still contains references to pthread_mutex_lock and pthread_mutex_unlock, which causes NLS configure to fail on AIX. How can this be corrected? Thanks, David libintl.a[libgnu_la-mbrtowc.o]: - U __lc_charmap - U errno - U .locale_encoding_classification - U .gl_get_mbtowc_lock - U .pthread_mutex_lock - U .mbtowc - U .pthread_mutex_unlock - U .abort 0 T ._libintl_mbrtowc 1952 D _libintl_mbrtowc libintl.a[libgnu_la-setlocale_null.o]: - U .gl_get_setlocale_null_lock - U .pthread_mutex_lock - U .setlocale - U .strlen - U .memcpy - U .pthread_mutex_unlock - U .abort - U .strcpy 336 T ._libintl_setlocale_null_r 400 T ._libintl_setlocale_null 812 D _libintl_setlocale_null_r 824 D _libintl_setlocale_null On Thu, Nov 16, 2023 at 11:00 AM David Edelsohn wrote: > Bruno, > > I have been able to tweak the environment and build gettext and libintl. > With the updated libintl and environment, GCC reliably does not use NLS. > > The issue is that libintl utilizes pthreads. AIX does not provide no-op > pthread stubs in libc. pthreads is an explicit multilib on AIX. > > It is great that gettext and libintl can be built thread-safe, but GCC > (cc1, gcov, etc.) are not pthreads applications and are not built with > pthreads. Because libintl defaults to pthreads enabled, NLS cannot > function in GCC on AIX by default. The GCC included gettext was built in > the default for GCC libraries, which was not pthreads enabled. > > I can rebuild libintl with --disable-pthreads and I will see if that > works, but the default, distributed libintl library will not allow GCC to > be built with NLS enabled. And, no, GCC on AIX should not be forced to > build with pthreads. > > This is a regression in NLS support in GCC. > > Thanks, David > > > On Wed, Nov 15, 2023 at 5:39 PM Bruno Haible wrote: > >> David Edelsohn wrote: >> > I am using my own install of GCC for a reason. >> >> I have built GNU gettext 0.22.3 in various configurations on the AIX 7.1 >> and 7.3 machines in the compilefarm, and haven't encountered issues with >> 'max_align_t' nor with 'getpeername'. So, from my point of view, GNU >> gettext >> works fine on AIX with gcc and xlc (but not ibm-clang, which I haven't >> tested). >> >> You will surely understand that I cannot test a release against a compiler >> that exists only on your hard disk. >> >> The hint I gave you, based on the partial logs that you provided, is to >> look at the configure test for intmax_t first. >> >> Bruno >> >> >> >>
Re: building GNU gettext on AIX
On Thu, Nov 16, 2023 at 11:58 AM Richard Biener wrote: > > > Am 16.11.2023 um 17:00 schrieb David Edelsohn : > > > Bruno, > > I have been able to tweak the environment and build gettext and libintl. > With the updated libintl and environment, GCC reliably does not use NLS. > > The issue is that libintl utilizes pthreads. AIX does not provide no-op > pthread stubs in libc. pthreads is an explicit multilib on AIX. > > It is great that gettext and libintl can be built thread-safe, but GCC > (cc1, gcov, etc.) are not pthreads applications and are not built with > pthreads. Because libintl defaults to pthreads enabled, NLS cannot > function in GCC on AIX by default. The GCC included gettext was built in > the default for GCC libraries, which was not pthreads enabled. > > I can rebuild libintl with --disable-pthreads and I will see if that > works, but the default, distributed libintl library will not allow GCC to > be built with NLS enabled. And, no, GCC on AIX should not be forced to > build with pthreads. > > This is a regression in NLS support in GCC. > > > If that’s for the in-tree libintl we can arrange configure to pass down > —disable-pthreads like we adjust configure args for gmp and friends as well. > The latest issue is that a few files in gettext ignore --disable-pthreads and creates a dependency on pthread_mutex. David > > Richard > > Thanks, David > > > On Wed, Nov 15, 2023 at 5:39 PM Bruno Haible wrote: > >> David Edelsohn wrote: >> > I am using my own install of GCC for a reason. >> >> I have built GNU gettext 0.22.3 in various configurations on the AIX 7.1 >> and 7.3 machines in the compilefarm, and haven't encountered issues with >> 'max_align_t' nor with 'getpeername'. So, from my point of view, GNU >> gettext >> works fine on AIX with gcc and xlc (but not ibm-clang, which I haven't >> tested). >> >> You will surely understand that I cannot test a release against a compiler >> that exists only on your hard disk. >> >> The hint I gave you, based on the partial logs that you provided, is to >> look at the configure test for intmax_t first. >> >> Bruno >> >> >> >>
Re: building GNU gettext on AIX
Bruno,
The issue appears to be that intl/gnulib-lib/{mbrtowc.c,setlocale_null.c}
include pthread.h based on HAVE_PTHREAD_API, which is defined as 1 in
intl/config.h build directory despite requesting --disable-pthreads.
Thanks, David
On Thu, Nov 16, 2023 at 11:35 AM David Edelsohn wrote:
> I configured gettext with --disable-pthreads and libintl.a still contains
> references to pthread_mutex_lock and pthread_mutex_unlock, which causes NLS
> configure to fail on AIX.
>
> How can this be corrected?
>
> Thanks, David
>
> libintl.a[libgnu_la-mbrtowc.o]:
>
> - U __lc_charmap
>
> - U errno
>
> - U .locale_encoding_classification
>
> - U .gl_get_mbtowc_lock
>
> - U .pthread_mutex_lock
>
> - U .mbtowc
>
> - U .pthread_mutex_unlock
>
> - U .abort
>
> 0 T ._libintl_mbrtowc
>
> 1952 D _libintl_mbrtowc
>
> libintl.a[libgnu_la-setlocale_null.o]:
>
> - U .gl_get_setlocale_null_lock
>
> - U .pthread_mutex_lock
>
> - U .setlocale
>
> - U .strlen
>
> - U .memcpy
>
> - U .pthread_mutex_unlock
>
> - U .abort
>
> - U .strcpy
>
>336 T ._libintl_setlocale_null_r
>
> 400 T ._libintl_setlocale_null
>
>812 D _libintl_setlocale_null_r
>
>824 D _libintl_setlocale_null
>
> On Thu, Nov 16, 2023 at 11:00 AM David Edelsohn wrote:
>
>> Bruno,
>>
>> I have been able to tweak the environment and build gettext and libintl.
>> With the updated libintl and environment, GCC reliably does not use NLS.
>>
>> The issue is that libintl utilizes pthreads. AIX does not provide no-op
>> pthread stubs in libc. pthreads is an explicit multilib on AIX.
>>
>> It is great that gettext and libintl can be built thread-safe, but GCC
>> (cc1, gcov, etc.) are not pthreads applications and are not built with
>> pthreads. Because libintl defaults to pthreads enabled, NLS cannot
>> function in GCC on AIX by default. The GCC included gettext was built in
>> the default for GCC libraries, which was not pthreads enabled.
>>
>> I can rebuild libintl with --disable-pthreads and I will see if that
>> works, but the default, distributed libintl library will not allow GCC to
>> be built with NLS enabled. And, no, GCC on AIX should not be forced to
>> build with pthreads.
>>
>> This is a regression in NLS support in GCC.
>>
>> Thanks, David
>>
>>
>> On Wed, Nov 15, 2023 at 5:39 PM Bruno Haible wrote:
>>
>>> David Edelsohn wrote:
>>> > I am using my own install of GCC for a reason.
>>>
>>> I have built GNU gettext 0.22.3 in various configurations on the AIX 7.1
>>> and 7.3 machines in the compilefarm, and haven't encountered issues with
>>> 'max_align_t' nor with 'getpeername'. So, from my point of view, GNU
>>> gettext
>>> works fine on AIX with gcc and xlc (but not ibm-clang, which I haven't
>>> tested).
>>>
>>> You will surely understand that I cannot test a release against a
>>> compiler
>>> that exists only on your hard disk.
>>>
>>> The hint I gave you, based on the partial logs that you provided, is to
>>> look at the configure test for intmax_t first.
>>>
>>> Bruno
>>>
>>>
>>>
>>>
Re: building GNU gettext on AIX
I manually commented out HAVE_PTHREAD_API from config.h and produced a
libintl.a without references to pthreads. Configuring GCC with that custom
libintl.a enables NLS. I now am building GCC with NLS and we will see how
well it functions.
gettext depends on pthreads by default and the versions distributed.
Thanks, David
On Thu, Nov 16, 2023 at 1:01 PM David Edelsohn wrote:
> Bruno,
>
> The issue appears to be that intl/gnulib-lib/{mbrtowc.c,setlocale_null.c}
> include pthread.h based on HAVE_PTHREAD_API, which is defined as 1 in
> intl/config.h build directory despite requesting --disable-pthreads.
>
> Thanks, David
>
> On Thu, Nov 16, 2023 at 11:35 AM David Edelsohn wrote:
>
>> I configured gettext with --disable-pthreads and libintl.a still contains
>> references to pthread_mutex_lock and pthread_mutex_unlock, which causes NLS
>> configure to fail on AIX.
>>
>> How can this be corrected?
>>
>> Thanks, David
>>
>> libintl.a[libgnu_la-mbrtowc.o]:
>>
>> - U __lc_charmap
>>
>> - U errno
>>
>> - U .locale_encoding_classification
>>
>> - U .gl_get_mbtowc_lock
>>
>> - U .pthread_mutex_lock
>>
>> - U .mbtowc
>>
>> - U .pthread_mutex_unlock
>>
>> - U .abort
>>
>> 0 T ._libintl_mbrtowc
>>
>> 1952 D _libintl_mbrtowc
>>
>> libintl.a[libgnu_la-setlocale_null.o]:
>>
>> - U .gl_get_setlocale_null_lock
>>
>> - U .pthread_mutex_lock
>>
>> - U .setlocale
>>
>> - U .strlen
>>
>> - U .memcpy
>>
>> - U .pthread_mutex_unlock
>>
>> - U .abort
>>
>> - U .strcpy
>>
>>336 T ._libintl_setlocale_null_r
>>
>>400 T ._libintl_setlocale_null
>>
>>812 D _libintl_setlocale_null_r
>>
>>824 D _libintl_setlocale_null
>>
>> On Thu, Nov 16, 2023 at 11:00 AM David Edelsohn
>> wrote:
>>
>>> Bruno,
>>>
>>> I have been able to tweak the environment and build gettext and
>>> libintl. With the updated libintl and environment, GCC reliably does not
>>> use NLS.
>>>
>>> The issue is that libintl utilizes pthreads. AIX does not provide no-op
>>> pthread stubs in libc. pthreads is an explicit multilib on AIX.
>>>
>>> It is great that gettext and libintl can be built thread-safe, but GCC
>>> (cc1, gcov, etc.) are not pthreads applications and are not built with
>>> pthreads. Because libintl defaults to pthreads enabled, NLS cannot
>>> function in GCC on AIX by default. The GCC included gettext was built in
>>> the default for GCC libraries, which was not pthreads enabled.
>>>
>>> I can rebuild libintl with --disable-pthreads and I will see if that
>>> works, but the default, distributed libintl library will not allow GCC to
>>> be built with NLS enabled. And, no, GCC on AIX should not be forced to
>>> build with pthreads.
>>>
>>> This is a regression in NLS support in GCC.
>>>
>>> Thanks, David
>>>
>>>
>>> On Wed, Nov 15, 2023 at 5:39 PM Bruno Haible wrote:
>>>
>>>> David Edelsohn wrote:
>>>> > I am using my own install of GCC for a reason.
>>>>
>>>> I have built GNU gettext 0.22.3 in various configurations on the AIX 7.1
>>>> and 7.3 machines in the compilefarm, and haven't encountered issues with
>>>> 'max_align_t' nor with 'getpeername'. So, from my point of view, GNU
>>>> gettext
>>>> works fine on AIX with gcc and xlc (but not ibm-clang, which I haven't
>>>> tested).
>>>>
>>>> You will surely understand that I cannot test a release against a
>>>> compiler
>>>> that exists only on your hard disk.
>>>>
>>>> The hint I gave you, based on the partial logs that you provided, is to
>>>> look at the configure test for intmax_t first.
>>>>
>>>> Bruno
>>>>
>>>>
>>>>
>>>>
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
Don't build with the dependent libraries in tree. Don't build the dependent libraries as shared libraries. The libraries are already built and in /opt/cfarm, as mentioned in the Compile Farm wiki. AIX is not Solaris and not Linux. It doesn't use ELF. AIX shared libraries *ARE* shared object files in archives. Shared object versioning is handled by multiple objects in the same archive. Thanks, David On Thu, Nov 16, 2023 at 4:15 PM Arsen Arsenović wrote: > > Arsen Arsenović writes: > > > [[PGP Signed Part:Good signature from 52C294301EA2C493 Arsen Arsenović > (Gentoo Developer UID) (trust ultimate) created at > 2023-11-16T19:47:16+0100 using EDDSA]] > > > > David Edelsohn writes: > > > >> On Wed, Nov 15, 2023 at 9:22 AM Arsen Arsenović > wrote: > >> > >>> > >>> David Edelsohn writes: > >>> > >>> > GCC had been working on AIX with NLS, using > "--with-included-gettext". > >>> > --disable-nls gets past the breakage, but GCC does not build for me > on > >>> AIX > >>> > with NLS enabled. > >>> > >>> That should still work with gettext 0.22+ extracted in-tree (it should > >>> be fetched by download_prerequisites). > >>> > >>> > A change in dependencies for GCC should have been announced and more > >>> widely > >>> > socialized in the GCC development mailing list, not just GCC patches > >>> > mailing list. > >>> > > >>> > I have tried both the AIX Open Source libiconv and libgettext > package, > >>> and > >>> > the ones that I previously built. Both fail because GCC configure > >>> decides > >>> > to disable NLS, despite being requested, while libcpp is satisfied, > so > >>> > tools in the gcc subdirectory don't link against libiconv and the > build > >>> > fails. With the included gettext, I was able to rely on a > >>> self-consistent > >>> > solution. > >>> > >>> That is interesting. They should be using the same checks. I've > >>> checked trunk and regenerated files on it, and saw no significant diff > >>> (some whitespace changes only). Could you post the config.log of both? > >>> > >>> I've never used AIX. Can I reproduce this on one of the cfarm machines > >>> to poke around? I've tried cfarm119, but that one lacked git, and I > >>> haven't poked around much further due to time constraints. > >>> > >> > >> The AIX system in the Compile Farm has a complete complement of Open > Source > >> software installed. > >> > >> Please ensure that /opt/freeware/bin is in your path. Also, the GCC > Wiki > >> Compile Farm page has build tips that include AIX > >> > >> > https://gcc.gnu.org/wiki/CompileFarm#Services_and_software_installed_on_farm_machines > > > > Thanks, that got me further. > > > >> that recommended --with-included-gettext configuration option. > > > > This flag should still exist and operate the same if gettext is present > > in tree. I've cloned gcc and downloaded prerequisites (via > > contrib/download_prerequisites) and I am trying to configure it now. > > The build failed. After gettext/gmp/... (in-tree hostlibs) get built > and added to library paths, further GCC processes fail to run: > > configure:3305: gcc -g -static-libstdc++ -static-libgcc -Wl,-bbigtoc > conftest.c >&5 > Could not load program > /opt/freeware/libexec/gcc/powerpc-ibm-aix7.3.0.0/10/cc1: > Dependent module > /home/arsen/build/./gmp/.libs/libgmp.a(libgmp.so.10) could not be loaded. > Member libgmp.so.10 is not found in archive > > This seems odd. I am not sure what compels the RTDL (?) to look up .sos > in archives, or how it knows about these archives.. I suspect it's > getting tripped by something in HOST_EXPORTS. > > >> Thanks, David > >> > >> > >>> > >>> TIA, sorry about the inconvenience. Have a lovely day. > >>> > >>> > The current gettext-0.22.3 fails to build for me on AIX. > >>> > > >>> > libcpp configure believes that NLS functions on AIX, but gcc > configure > >>> > fails in its tests of gettext functionality, which leads to an > >>> inconsistent > >>> > configuration and build breakage. > >>> > > >>> > Thanks, David > >>> > >>> > >>> -- > >>> Arsen Arsenović > >>> > > > -- > Arsen Arsenović >
Re: building GNU gettext on AIX
On Thu, Nov 16, 2023 at 1:52 PM Bruno Haible wrote: > David Edelsohn wrote: > > I manually commented out HAVE_PTHREAD_API from config.h and produced a > > libintl.a without references to pthreads. > > Good finding! > > Commenting out HAVE_PTHREAD_API from config.h is also what makes the > option --enable-threads=isoc work as expected on AIX 7.3. > I reconfigured and built gettext with --enable-threads=isoc . libintl.a still contains references to pthread_mutex and friends: $ nm -BCpg libintl.a | grep pthread - U __n_pthreads - U .pthread_mutex_lock - U .pthread_mutex_unlock - U .pthread_mutex_lock - U .pthread_mutex_unlock - U __n_pthreads from files mbrtowc, setlocale_null, and vasnwprintf. I tested on an AIX 7.2.5 system and confirmed that libc does provide the mtx_ symbols: $ nm -BCpg libc.a | grep mtx_ 0 T .mtx_timedlock 160 T .mtx_unlock 256 T .mtx_trylock 416 T .mtx_lock 512 T .mtx_init 736 T .mtx_destroy 80 D mtx_timedlock 92 D mtx_unlock 104 D mtx_trylock 116 D mtx_lock 128 D mtx_init 140 D mtx_destroy Were you suggesting that --enable-threads=isoc would work now or that it would require further changes for a future release? At the moment, configuring gettext with --disable-threads and manually modifying config.h is the only method that produces libintl.a without references to pthreads allowing GCC to build on AIX with NLS enabled. Thanks, David
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
On Thu, Nov 16, 2023 at 5:22 PM Arsen Arsenović wrote: > > David Edelsohn writes: > > > Don't build with the dependent libraries in tree. Don't build the > > dependent libraries as shared libraries. The libraries are already built > > and in /opt/cfarm, as mentioned in the Compile Farm wiki. > > > > AIX is not Solaris and not Linux. It doesn't use ELF. AIX shared > > libraries *ARE* shared object files in archives. Shared object > versioning > > is handled by multiple objects in the same archive. > > Hmm, I see. I removed all the deps but gettext from the tree. > > This leaves gettext-runtime fulfilling the previous role of intl/. > > However, I'm confused about how this worked before, in that case, since, > IIRC, intl also produced libraries and was also put into host exports. > > Leaving gettext in tree produces: > > Could not load program gawk: > Dependent module > /home/arsen/build/./gettext/intl/.libs/libintl.a(libintl.so.8) could not be > loaded. > Member libintl.so.8 is not found in archive > > I'll try to see why intl/ didn't cause the same issue soon. > > Thanks, have a lovely evening. > The previous version of "intl" was built as a static library. Configure in the older package had the option --enable-host-shared, which I did not use. Based on the failure message, the in-tree gettext seems to be built as a shared library. If you explicitly pass --disable-shared to the in-tree configure, you may get farther. I'm currently using --disable-shared --disable-threads. As we have discussed, the current gettext will retain some references to pthreads despite the configure option. Thanks, David > > > Thanks, David > > > > > > > > On Thu, Nov 16, 2023 at 4:15 PM Arsen Arsenović wrote: > > > >> > >> Arsen Arsenović writes: > >> > >> > [[PGP Signed Part:Good signature from 52C294301EA2C493 Arsen Arsenović > >> (Gentoo Developer UID) (trust ultimate) created at > >> 2023-11-16T19:47:16+0100 using EDDSA]] > >> > > >> > David Edelsohn writes: > >> > > >> >> On Wed, Nov 15, 2023 at 9:22 AM Arsen Arsenović > >> wrote: > >> >> > >> >>> > >> >>> David Edelsohn writes: > >> >>> > >> >>> > GCC had been working on AIX with NLS, using > >> "--with-included-gettext". > >> >>> > --disable-nls gets past the breakage, but GCC does not build for > me > >> on > >> >>> AIX > >> >>> > with NLS enabled. > >> >>> > >> >>> That should still work with gettext 0.22+ extracted in-tree (it > should > >> >>> be fetched by download_prerequisites). > >> >>> > >> >>> > A change in dependencies for GCC should have been announced and > more > >> >>> widely > >> >>> > socialized in the GCC development mailing list, not just GCC > patches > >> >>> > mailing list. > >> >>> > > >> >>> > I have tried both the AIX Open Source libiconv and libgettext > >> package, > >> >>> and > >> >>> > the ones that I previously built. Both fail because GCC configure > >> >>> decides > >> >>> > to disable NLS, despite being requested, while libcpp is > satisfied, > >> so > >> >>> > tools in the gcc subdirectory don't link against libiconv and the > >> build > >> >>> > fails. With the included gettext, I was able to rely on a > >> >>> self-consistent > >> >>> > solution. > >> >>> > >> >>> That is interesting. They should be using the same checks. I've > >> >>> checked trunk and regenerated files on it, and saw no significant > diff > >> >>> (some whitespace changes only). Could you post the config.log of > both? > >> >>> > >> >>> I've never used AIX. Can I reproduce this on one of the cfarm > machines > >> >>> to poke around? I've tried cfarm119, but that one lacked git, and I > >> >>> haven't poked around much further due to time constraints. > >> >>> > >> >> > >> >> The AIX system in the Compile Farm has a complete complement of Open > >> Source > >> >> software installed. > >> >>
Re: building GNU gettext on AIX
On Thu, Nov 16, 2023 at 5:47 PM Bruno Haible wrote: > Hi David, > > > the default, distributed libintl library will not allow GCC to be built > > with NLS enabled. > > The problem is this configure test from gettext.m4 > > checking for GNU gettext in libintl... no > > It should say > > checking for GNU gettext in libintl... yes > > I reproduce it with simple hello-world package, outside GCC. > > It tests whether a program that uses gettext() can be linked with > -lintl -liconv > But now, on AIX, it needs to test whether such a program can be linked with > -lintl -liconv -lpthread > > > Were you suggesting that --enable-threads=isoc would work now or that it > > would require further changes for a future release? > > It requires a change, effectively to do as if HAVE_PTHREAD_API is undefined > if --enable-threads=isoc was provided. > > I can prepare a new gettext release that has both issues fixed: > - gettext.m4 that fixes the configure test and sets the variable LIBINTL > to "-Lsome/libdir -lintl -liconv -lpthread", > - mbrtowc.o and setlocale*.o that use mtx_* locks instead of pthread_* > mutexes when requested. > > But you then need to make up your mind w.r.t. what I wrote in the earlier > mail. > > * GCC can pass --enable-threads=isoc, to avoid the libpthread dependency > on AIX ≥ 7.2. > I have reached out to the AIX Open Source Tools team for their perspective. Normally GCC and other FOSS packages have not based their support for OS versions on official vendor support lifecycles, within reason. In fact, many users have appreciated longer duration support. > > * Or GCC can (continue to?) use the variable LIBINTL. This will work on > AIX 7.1 as well but the programs will then be linked against > libpthread. > One additional library. > $ ldd gcc > /opt/freeware/bin/gcc needs: > /usr/lib/libc.a(shr.o) > /opt/freeware/lib/libiconv.a(libiconv.so.2) > /usr/lib/libc.a(_shr.o) > /unix > /usr/lib/libcrypt.a(shr.o) > /opt/freeware/lib/libgcc_s.a(shr.o) > libpthread.a will be added to this list. > My builds of GCC only rely on AIX libc. All other libraries are statically linked. > > ibm-clang links against libpthread.a as well: > $ ldd /opt/IBM/openxlC/17.1.1/bin/.ibm-clang.orig > /opt/IBM/openxlC/17.1.1/bin/.ibm-clang.orig needs: > /usr/lib/libpthreads.a(shr_xpg5_64.o) > /usr/opt/zlibNX/lib/libz.a(libz.so.1) > /usr/lib/libcurses.a(shr42_64.o) > /usr/lib/libiconv.a(shr4_64.o) > /usr/lib/libc++.a(shr_64.o) > /usr/lib/libc++abi.a(libc++abi.so.1) > /usr/lib/libc.a(shr_64.o) > /usr/lib/libpthreads.a(_shr_xpg5_64.o) > /usr/lib/libc++.a(libc++.so.1) > /usr/lib/libunwind.a(libunwind.so.1) > /usr/lib/libc.a(_shr_64.o) > /unix > /usr/lib/libcrypt.a(shr_64.o) > I have asked the IBM Clang team why ibm-clang depends on libpthreads. One option is to add -lpthreads to the link line, even if the tools are not built thread-safe. Only the intl support would invoke the extraneous overhead. The downside is that other pthreads dependencies could sneak in. Thanks, David > > Bruno > > > >
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović wrote:
>
> David Edelsohn writes:
>
> > On Thu, Nov 16, 2023 at 5:22 PM Arsen Arsenović wrote:
> >
> >>
> >> David Edelsohn writes:
> >>
> >> > Don't build with the dependent libraries in tree. Don't build the
> >> > dependent libraries as shared libraries. The libraries are already
> built
> >> > and in /opt/cfarm, as mentioned in the Compile Farm wiki.
> >> >
> >> > AIX is not Solaris and not Linux. It doesn't use ELF. AIX shared
> >> > libraries *ARE* shared object files in archives. Shared object
> >> versioning
> >> > is handled by multiple objects in the same archive.
> >>
> >> Hmm, I see. I removed all the deps but gettext from the tree.
> >>
> >> This leaves gettext-runtime fulfilling the previous role of intl/.
> >>
> >> However, I'm confused about how this worked before, in that case, since,
> >> IIRC, intl also produced libraries and was also put into host exports.
> >>
> >> Leaving gettext in tree produces:
> >>
> >> Could not load program gawk:
> >> Dependent module
> >> /home/arsen/build/./gettext/intl/.libs/libintl.a(libintl.so.8) could
> not be
> >> loaded.
> >> Member libintl.so.8 is not found in archive
> >>
> >> I'll try to see why intl/ didn't cause the same issue soon.
> >>
> >> Thanks, have a lovely evening.
> >>
> >
> > The previous version of "intl" was built as a static library. Configure
> in
> > the older package had the option --enable-host-shared,
> > which I did not use. Based on the failure message, the in-tree gettext
> > seems to be built as a shared library. If you explicitly
> > pass --disable-shared to the in-tree configure, you may get farther. I'm
> > currently using --disable-shared --disable-threads.
> > As we have discussed, the current gettext will retain some references to
> > pthreads despite the configure option.
>
> Sure, but my patch does insert --disable-shared:
>
> --8<---cut here---start->8---
> host_modules= { module= gettext; bootstrap=true; no_install=true;
> module_srcdir= "gettext/gettext-runtime";
> // We always build gettext with pic, because some packages
> (e.g. gdbserver)
> // need it in some configuratons, which is determined via
> nontrivial tests.
> // Always enabling pic seems to make sense for something
> tied to
> // user-facing output.
> extra_configure_flags='--disable-shared --disable-java
> --disable-csharp --with-pic';
> lib_path=intl/.libs; };
> --8<---cut here---end--->8---
>
> ... and it is applied:
>
> --8<---cut here---start->8---
> -bash-5.1$ ./config.status --config
> --srcdir=../../gcc/gettext/gettext-runtime --cache-file=./config.cache
> --disable-werror --with-gmp=/opt/cfarm
> --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch
> --with-included-gettext --program-transform-name=s,y,y,
> --disable-option-checking --build=powerpc-ibm-aix7.3.1.0
> --host=powerpc-ibm-aix7.3.1.0 --target=powerpc-ibm-aix7.3.1.0
> --disable-intermodule --enable-checking=yes,types,extra
> --disable-coverage --enable-languages=c,c++
> --disable-build-format-warnings --disable-shared --disable-java
> --disable-csharp --with-pic build_alias=powerpc-ibm-aix7.3.1.0
> host_alias=powerpc-ibm-aix7.3.1.0 target_alias=powerpc-ibm-aix7.3.1.0
> CC=gcc CFLAGS=-g 'LDFLAGS=-static-libstdc++ -static-libgcc
> -Wl,-bbigtoc' 'CXX=g++ -std=c++11' CXXFLAGS=-g
> --8<---cut here---end--->8---
>
> I'm unsure how to tell what the produced binaries are w.r.t static or
> shared, but I only see .o files inside intl/.libs/libintl.a, while I see
> a .so.1 in (e.g.) /lib/libz.a, hinting at it not being shared (?)
>
An AIX shared library created by libtool will look like
libfoo.a[libfoo.so.N], where N is the package major version number.
Normally with one file.
An AIX static library will look like libfoo.a[a.o, b.o, c.o]
with multiple object files.
An AIX archive can contain a combination of shared objects and
normal object files.
AIX normally uses the convention shr.o or shr_64.o for the name
of the shared object file. Hint, hint, an AIX archive can contain
both 32 bit and 64 bit object files or shared o
Re: building GNU gettext on AIX
On Thu, Nov 16, 2023 at 7:07 PM Bruno Haible wrote: > David Edelsohn wrote: > > > ibm-clang links against libpthread.a as well: > > > $ ldd /opt/IBM/openxlC/17.1.1/bin/.ibm-clang.orig > > > /opt/IBM/openxlC/17.1.1/bin/.ibm-clang.orig needs: > > > /usr/lib/libpthreads.a(shr_xpg5_64.o) > > > /usr/opt/zlibNX/lib/libz.a(libz.so.1) > > > /usr/lib/libcurses.a(shr42_64.o) > > > /usr/lib/libiconv.a(shr4_64.o) > > > /usr/lib/libc++.a(shr_64.o) > > > /usr/lib/libc++abi.a(libc++abi.so.1) > > > /usr/lib/libc.a(shr_64.o) > > > /usr/lib/libpthreads.a(_shr_xpg5_64.o) > > > /usr/lib/libc++.a(libc++.so.1) > > > /usr/lib/libunwind.a(libunwind.so.1) > > > /usr/lib/libc.a(_shr_64.o) > > > /unix > > > /usr/lib/libcrypt.a(shr_64.o) > > > > > > > I have asked the IBM Clang team why ibm-clang depends on libpthreads. > > The reason is that > - For a library, it is a normal expectation nowadays that it is > multithread-safe. > - Making a library multithread-safe (without major hacks) means to do > locking or to call pthread_once / call_once in some places. > - The ISO C 11 threading functions in libc have some drawbacks compared > to the pthread functions. [1] So most developer prefer to rely on the > POSIX threads API. > - Since AIX does not have the POSIX mutex functions in libc and does not > support weak symbols like in ELF, this means a dependency to > pthread_mutex_lock or pthread_once. > - Accordingly, in the list of libraries above, 3 libraries need pthread* > symbols: > > $ nm -X 64 /usr/lib/libc++abi.a | grep ' U ' | grep pthread_mutex > pthread_mutex_lock U - > pthread_mutex_unlock U - > $ nm -X 64 /usr/lib/libc++.a | grep ' U ' | grep pthread_mutex > pthread_mutex_destroy U - > pthread_mutex_init U - > pthread_mutex_lock U - > pthread_mutex_trylock U - > pthread_mutex_unlock U - > pthread_mutexattr_destroy U - > pthread_mutexattr_init U - > pthread_mutexattr_settype U - > $ nm -X 64 /usr/opt/zlibNX/lib/libz.a | grep ' U ' | grep pthread_mutex > pthread_mutex_destroy U - > pthread_mutex_init U - > pthread_mutex_lock U - > pthread_mutex_unlock U - > There are ibm_clang and ibm_clang_r (previous xlc and xlc_r) to compile with and without thread safe. If IBM Clang team chose to only provide a thread safe version of libc++, okay, but that doesn't seem like a fundamental requirement. zlibNX is another can of worms. David
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
On Fri, Nov 17, 2023 at 3:46 AM Arsen Arsenović wrote:
>
> David Edelsohn writes:
>
> > On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović wrote:
> >
> > [snip]
> >> Sure, but my patch does insert --disable-shared:
> >>
> >> --8<---cut here---start->8---
> >> host_modules= { module= gettext; bootstrap=true; no_install=true;
> >> module_srcdir= "gettext/gettext-runtime";
> >> // We always build gettext with pic, because some
> packages
> >> (e.g. gdbserver)
> >> // need it in some configuratons, which is determined
> via
> >> nontrivial tests.
> >> // Always enabling pic seems to make sense for something
> >> tied to
> >> // user-facing output.
> >> extra_configure_flags='--disable-shared --disable-java
> >> --disable-csharp --with-pic';
> >> lib_path=intl/.libs; };
> >> --8<---cut here---end--->8---
> >>
> >> ... and it is applied:
> >>
> >> --8<---cut here---start->8---
> >> -bash-5.1$ ./config.status --config
> >> --srcdir=../../gcc/gettext/gettext-runtime --cache-file=./config.cache
> >> --disable-werror --with-gmp=/opt/cfarm
> >> --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch
> >> --with-included-gettext --program-transform-name=s,y,y,
> >> --disable-option-checking --build=powerpc-ibm-aix7.3.1.0
> >> --host=powerpc-ibm-aix7.3.1.0 --target=powerpc-ibm-aix7.3.1.0
> >> --disable-intermodule --enable-checking=yes,types,extra
> >> --disable-coverage --enable-languages=c,c++
> >> --disable-build-format-warnings --disable-shared --disable-java
> >> --disable-csharp --with-pic build_alias=powerpc-ibm-aix7.3.1.0
> >> host_alias=powerpc-ibm-aix7.3.1.0 target_alias=powerpc-ibm-aix7.3.1.0
> >> CC=gcc CFLAGS=-g 'LDFLAGS=-static-libstdc++ -static-libgcc
> >> -Wl,-bbigtoc' 'CXX=g++ -std=c++11' CXXFLAGS=-g
> >> --8<---cut here---end--->8---
> >>
> >> I'm unsure how to tell what the produced binaries are w.r.t static or
> >> shared, but I only see .o files inside intl/.libs/libintl.a, while I see
> >> a .so.1 in (e.g.) /lib/libz.a, hinting at it not being shared (?)
> >>
> >
> > An AIX shared library created by libtool will look like
> > libfoo.a[libfoo.so.N], where N is the package major version number.
> > Normally with one file.
>
> > An AIX static library will look like libfoo.a[a.o, b.o, c.o]
> > with multiple object files.
> >
> > An AIX archive can contain a combination of shared objects and
> > normal object files.
> >
> > AIX normally uses the convention shr.o or shr_64.o for the name
> > of the shared object file. Hint, hint, an AIX archive can contain
> > both 32 bit and 64 bit object files or shared objects.
> >
> > I don't know why the gettext build system would create
> > /home/arsen/build/./gettext/intl/.libs/libintl.a(libintl.so.8)
> > if --disable-shared was requested. That clearly is using the
> > naming of a libtool AIX shared object and failing due to
> > the missing shared object. Although in this case, the problem
> > seems to be the shared library load path. AIX uses LIBPATH,
> > not LD_LIBRARY_PATH.
>
> It doesn't create libintl.a with a libintl.so.8 inside of it. The
> libintl.a contains a bunch of objects, as I'd expect of a static
> library:
>
> --8<---cut here---start->8---
> -bash-5.1$ ar -t gettext/intl/.libs/libintl.a | grep libintl
> -bash-5.1$ ar -t gettext/intl/.libs/libintl.a
> bindtextdom.o
> dcgettext.o
> ...
> --8<---cut here---end--->8---
>
>
> > Also, for me, the out of tree path was
> >
> > gettext/gettext-runtime/intl/.libs
> >
> > Is your search path missing a level?
>
> No, the above is generated by the GCC build system and builds
> gettext-runtime directly (per Brunos recommendation a while ago) as it
> is replacing intl/ of similar functionality.
>
> I'm currently building GCC with libintl with the threads hack you
> mentioned applied (as I got undefined references to the pthread
> functions you discovered). I suspect that, bar this issue (which, IIUC,
> Bruno will fix in a new release?) the patch above will fix the issues
> you've encountered on AIX (note that if you want to use gettext in-tree,
> you'd still have to fetch gettext into the tree).
>
> Maybe we should provide a download-prerequisite-y script that skips
> everything but GNU gettext, to retain same behavior?
>
> Have a lovely day.
>
I'm concerned that the gettext fixes are working around AIX support for
libpthread.a as opposed to making --disable-threads function.
--enabled-threads=isoc use of mtx_* is a workaround, but it's still not
allowing users to truly disable threads.
Thanks, David
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
On Fri, Nov 17, 2023 at 10:17 AM Arsen Arsenović wrote:
>
> David Edelsohn writes:
>
> > On Fri, Nov 17, 2023 at 3:46 AM Arsen Arsenović wrote:
> >
> >>
> >> David Edelsohn writes:
> >>
> >> > On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović
> wrote:
> >> >
> >> > [snip]
> >> >> Sure, but my patch does insert --disable-shared:
> >> >>
> >> >> --8<---cut here---start->8---
> >> >> host_modules= { module= gettext; bootstrap=true; no_install=true;
> >> >> module_srcdir= "gettext/gettext-runtime";
> >> >> // We always build gettext with pic, because some
> >> packages
> >> >> (e.g. gdbserver)
> >> >> // need it in some configuratons, which is determined
> >> via
> >> >> nontrivial tests.
> >> >> // Always enabling pic seems to make sense for
> something
> >> >> tied to
> >> >> // user-facing output.
> >> >> extra_configure_flags='--disable-shared
> --disable-java
> >> >> --disable-csharp --with-pic';
> >> >> lib_path=intl/.libs; };
> >> >> --8<---cut here---end--->8---
> >> >>
> >> >> ... and it is applied:
> >> >>
> >> >> --8<---cut here---start->8---
> >> >> -bash-5.1$ ./config.status --config
> >> >> --srcdir=../../gcc/gettext/gettext-runtime
> --cache-file=./config.cache
> >> >> --disable-werror --with-gmp=/opt/cfarm
> >> >> --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch
> >> >> --with-included-gettext --program-transform-name=s,y,y,
> >> >> --disable-option-checking --build=powerpc-ibm-aix7.3.1.0
> >> >> --host=powerpc-ibm-aix7.3.1.0 --target=powerpc-ibm-aix7.3.1.0
> >> >> --disable-intermodule --enable-checking=yes,types,extra
> >> >> --disable-coverage --enable-languages=c,c++
> >> >> --disable-build-format-warnings --disable-shared --disable-java
> >> >> --disable-csharp --with-pic build_alias=powerpc-ibm-aix7.3.1.0
> >> >> host_alias=powerpc-ibm-aix7.3.1.0
> target_alias=powerpc-ibm-aix7.3.1.0
> >> >> CC=gcc CFLAGS=-g 'LDFLAGS=-static-libstdc++ -static-libgcc
> >> >> -Wl,-bbigtoc' 'CXX=g++ -std=c++11' CXXFLAGS=-g
> >> >> --8<---cut here---end--->8---
> >> >>
> >> >> I'm unsure how to tell what the produced binaries are w.r.t static or
> >> >> shared, but I only see .o files inside intl/.libs/libintl.a, while I
> see
> >> >> a .so.1 in (e.g.) /lib/libz.a, hinting at it not being shared (?)
> >> >>
> >> >
> >> > An AIX shared library created by libtool will look like
> >> > libfoo.a[libfoo.so.N], where N is the package major version number.
> >> > Normally with one file.
> >>
> >> > An AIX static library will look like libfoo.a[a.o, b.o, c.o]
> >> > with multiple object files.
> >> >
> >> > An AIX archive can contain a combination of shared objects and
> >> > normal object files.
> >> >
> >> > AIX normally uses the convention shr.o or shr_64.o for the name
> >> > of the shared object file. Hint, hint, an AIX archive can contain
> >> > both 32 bit and 64 bit object files or shared objects.
> >> >
> >> > I don't know why the gettext build system would create
> >> > /home/arsen/build/./gettext/intl/.libs/libintl.a(libintl.so.8)
> >> > if --disable-shared was requested. That clearly is using the
> >> > naming of a libtool AIX shared object and failing due to
> >> > the missing shared object. Although in this case, the problem
> >> > seems to be the shared library load path. AIX uses LIBPATH,
> >> > not LD_LIBRARY_PATH.
> >>
> >> It doesn't create libintl.a with a libintl.so.8 inside of it. The
> >> libintl.a contains a bunch of objects, as I'd expect of a static
> >> library:
> >>
> >> --8<---cut here---start->8---
> >> -bash-5.1$ ar -t gettext/intl/.libs/libintl
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
On Sun, Nov 19, 2023 at 5:15 PM Bruno Haible wrote: > David Edelsohn wrote: > > --disable-threads currently does not completely disable threads. Bruno > is > > suggesting --enable-threads=isoc that relies on mtx mutex functions in > libc. > > Unfortunately, as said in the other mail today, relying only on mtx_* > functions > did not drop the dependency towards libpthreads. > > So, I've made a new release gettext-0.22.4, that includes only these > changes: > > - AM_GNU_GETTEXT now recognizes a statically built libintl on macOS and > AIX. > > - Passing --disable-threads now builds a libintl that, on AIX, does not > need -lpthread. > > - Other build fixes on AIX. > > > Yes, GCC should configure the in tree gettext with --disable-threads, but > > that configure option is not completely effective and does not produce a > > build without threads references. > > Now it is effective. But you (Arsen) should state in the documentation > (gcc/doc/install.texi) that for --disable-threads to have this effect, > one needs gettext version 0.22.4 or newer. > So the question is do we want to change GCC on AIX to always link against pthreads so that GCC can build with default, external builds of gettext libintl. I don't see a path for i18n support to work for GCC on AIX without that unfortunate change. Thanks, David
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
_GLOBAL__F_xxx is the EH frame data. It's using the filename with full path for the unique name, which is why it includes .._.._.. . Apparently it is adding a random number as well for uniqueness. I guess that this is the downside of building in tree, and apparently it is rebuilding gettext itself with the different stages of the compiler, so the appended random number changes. Thanks, David On Mon, Nov 20, 2023 at 4:23 PM Arsen Arsenović wrote: > > David Edelsohn writes: > > > On Sun, Nov 19, 2023 at 5:15 PM Bruno Haible wrote: > > > >> David Edelsohn wrote: > >> > --disable-threads currently does not completely disable threads. > Bruno > >> is > >> > suggesting --enable-threads=isoc that relies on mtx mutex functions in > >> libc. > >> > >> Unfortunately, as said in the other mail today, relying only on mtx_* > >> functions > >> did not drop the dependency towards libpthreads. > >> > >> So, I've made a new release gettext-0.22.4, that includes only these > >> changes: > >> > >> - AM_GNU_GETTEXT now recognizes a statically built libintl on macOS > and > >> AIX. > >> > >> - Passing --disable-threads now builds a libintl that, on AIX, does > not > >> need -lpthread. > >> > >> - Other build fixes on AIX. > >> > >> > Yes, GCC should configure the in tree gettext with --disable-threads, > but > >> > that configure option is not completely effective and does not > produce a > >> > build without threads references. > >> > >> Now it is effective. But you (Arsen) should state in the documentation > >> (gcc/doc/install.texi) that for --disable-threads to have this effect, > >> one needs gettext version 0.22.4 or newer. > >> > > > > So the question is do we want to change GCC on AIX to always link against > > pthreads so that GCC can build with default, external builds of gettext > > libintl. I don't see a path for i18n support to work for GCC on AIX > > without that unfortunate change. > > Well, if detectable by the build system for, I imagine we could avoid > pthread if gettext is built without them. With the 'private' gettext > build, we should never need threads anyway. > > P.S: Building on AIX is nearly successful. gettext-0.22.4 builds, twice > or even thrice, but ends up producing a bootstrap comparison fail: > > make[3]: Leaving directory '/home/arsen/build' > Comparing stages 2 and 3 > Bootstrap comparison failure! > gettext/libasprintf/autosprintf.o differs > make[2]: *** [Makefile:23435: compare] Error 1 > > Upon inspecting these files, I see the following diff: > > ~ 1 $ git diff <(objdump --all-headers autosprintf.o2) <(objdump > --all-headers autosprintf.o3) > diff --git a/dev/fd/63 b/dev/fd/62 > --- a/dev/fd/63 > +++ b/dev/fd/62 > ... > @@ -92,7 +92,7 @@ AUX indx 30 prmhsh 0 snhsh 0 typ 2 algn 0 clss 0 stb 0 > snstb 0 > AUX val23 prmhsh 0 snhsh 0 typ 1 algn 4 clss 1 stb 0 snstb 0 > [ 58](sec 1)(fl 0x00)(ty0)(scl 107) (nx 1) 0x0460 > _autosprintf.ro_ > AUX val 312 prmhsh 0 snhsh 0 typ 1 algn 4 clss 1 stb 0 snstb 0 > -[ 60](sec 1)(fl 0x00)(ty0)(scl 2) (nx 1) 0x0460 > _GLOBAL__F_.._.._.._gcc_gettext_gettext_runtime_libasprintf_autosprintf.cc_DFF67DD7_0xa20d51b1d7a1772f > +[ 60](sec 1)(fl 0x00)(ty0)(scl 2) (nx 1) 0x0460 > _GLOBAL__F_.._.._.._gcc_gettext_gettext_runtime_libasprintf_autosprintf.cc_DFF67DD7_0x9c04058e89d7a7a4 > AUX indx 58 prmhsh 0 snhsh 0 typ 2 algn 0 clss 1 stb 0 snstb 0 > [ 62](sec 2)(fl 0x00)(ty0)(scl 107) (nx 1) 0x05a0 > _autosprintf.rw_ > AUX val 0 prmhsh 0 snhsh 0 typ 1 algn 4 clss 5 stb 0 snstb 0 > > I am unsure what this symbol is. It does not appear in the stripped > binary. > -- > Arsen Arsenović >
Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext
On Tue, Nov 21, 2023 at 8:51 AM Arsen Arsenović wrote: > > Arsen Arsenović writes: > > > Bruno Haible writes: > > > >> Arsen Arsenović wrote: > >>> Comparing stages 2 and 3 > >>> Bootstrap comparison failure! > >>> gettext/libasprintf/autosprintf.o differs > >>> make[2]: *** [Makefile:23435: compare] Error 1 > >> > >> You should be able to work around this by passing the additional option > >> --disable-libasprintf to gettext-runtime/configure. Nothing in GCC needs > >> libasprintf; therefore there is no need to build it. > > > > Ah, sure, that works for me too (note that the fix is to pass > > -frandom-seed=, according to Jakub, should this show up again). > > Indeed, that got a bootstrap to pass. I've also taken the opportunity > to check the problems Eric Gallager reported. The install tree seems > clean now, and the info et al targets appear to work again. David, > Eric, could you check whether the attached patch works for you in the > scenarios you ran into problems with? Make sure to fetch gettext-0.22.4 > into your trees. > > > If these work, I'll update download_prerequisites and see about posting > the patch for review. > > Thanks, have a lovely day. > I don't build in tree, but the patch seems to address the previous issues. Thanks, David
Re: [RFC 1/2] libbacktrace: add FDPIC support
Hi, Ian
I believe that this patch broke bootstrap on AIX:
/nasfarm/edelsohn/src/src/libbacktrace/xcoff.c: In function 'xcoff_add':
/nasfarm/edelsohn/src/src/libbacktrace/xcoff.c:1309:40: error: incompatible
type for argument 2 of 'backtrace_dwarf_add'
1309 | if (!backtrace_dwarf_add (state, base_address,
&dwarf_sections,
|^~~~
||
|uintptr_t {aka long unsigned
int}
In file included from /nasfarm/edelsohn/src/src/libbacktrace/xcoff.c:45:
/nasfarm/edelsohn/src/src/libbacktrace/internal.h:363:66: note: expected
'struct libbacktrace_base_address' but argument is of type 'uintptr_t' {aka
'long unsigned int'}
363 | struct libbacktrace_base_address
base_address,
|
~^~~~
make[4]: *** [Makefile:1538: xcoff.lo] Error 1
CFG edge visualization to path-printing bootstrap failure
Hi, David Unfortunately r15-636-g770657d02c986c causes a bootstrap failure on AIX when building f951 in stage2. cc1 and cc1plus link successfully. There doesn't seem to be a similar failure for powerpc64-linux BE or LE. The failure is ld: 0711-317 ERROR: Undefined symbol: _ZTV29range_label_for_type_mismatch ld: 0711-317 ERROR: Undefined symbol: ._ZNK29range_label_for_type_mismatch8get_textEj which corresponds to vtable for range_label_for_type_mismatch range_label_for_type_mismatch::get_text(unsigned int) const I suspect that something is not being explicitly instantiated, which is running afoul of the AIX linker. Somehow your patch is causing the f951 compiler to reference these additional, undefined symbols. I suspect that they also are undefined for Linux targets, but the linker ignores the error and nothing is amiss if the symbols never are called. Thanks, David
Re: CFG edge visualization to path-printing bootstrap failure
On Mon, May 20, 2024 at 1:56 PM David Edelsohn wrote: > Hi, David > > Unfortunately r15-636-g770657d02c986c causes a bootstrap failure on AIX > when building f951 in stage2. cc1 and cc1plus link successfully. There > doesn't seem to be a similar failure for powerpc64-linux BE or LE. > > The failure is > > ld: 0711-317 ERROR: Undefined symbol: _ZTV29range_label_for_type_mismatch > ld: 0711-317 ERROR: Undefined symbol: > ._ZNK29range_label_for_type_mismatch8get_textEj > > which corresponds to > > vtable for range_label_for_type_mismatch > range_label_for_type_mismatch::get_text(unsigned int) const > > I suspect that something is not being explicitly instantiated, which is > running afoul of the AIX linker. > > Somehow your patch is causing the f951 compiler to reference these > additional, undefined symbols. I suspect that they also are undefined for > Linux targets, but the linker ignores the error and nothing is amiss if the > symbols never are called. > > Thanks, David > Thanks for diagnosing and fixing the problem. David
Re: Request for testing on non-Linux targets; remove special casing of /usr/lib and /lib from the driver
The patch does not cause failures on AIX. Is it removing explicit references to /lib and /usr/lib? It seems more appropriate for GCC 15. Thanks for alerting me to the patch to test on AIX. AIX is in CFarm. Thanks David On Tue, Apr 16, 2024 at 7:49 PM Andrew Pinski (QUIC) < quic_apin...@quicinc.com> wrote: > Hi all, > The driver currently will remove "/lib" and "/usr/lib" from the library > path that gets passed to the linker because it considers them as paths that > the linker will already known to search. But this is not true for newer > linkers, mold and lld for an example don't have a default search path. > This patch removes the special casing to fix FreeBSD building where lld is > used by default and also fix riscv-linux-gnu when used in combination with > mold. > I have tested it on x86_64-linux-gnu and it works there but since the code > in the driver has been around since 1992, I request some folks to test it > on AIX, Mac OS (Darwin) and solaris where the ld is not GNU bfd ld as I > don't have access to those targets currently. > > Thanks, > Andrew Pinski >
[PATCH, libgfortran] aix: Fix building fat library for AIX
aix: Fix building fat library for AIX With the change in subdirectories, the code for libgfortran fat libraries needs to be adjusted to explicitly reference the subdirectory. AIX creates fat library archives and the compiler itself can be built as either 32 bit or 64 bit application and default code generation. For the two, alternate versions of the compiler to interoperate, GCC needs to construct the fat libraries manually. The Makefile fragment had been trying to leverage as much of the existing targets and macros as possible. With the subdirectory change, the location of single.o is more obscured and cannot be determined without libtool. This patch references the location of the real object file more explicitly. Utilizing subst seems like overkill and unnecessary obscuration for a single object file. Either way, it's digging below the libtool abstraction layer. This also fixes Fortran bootstrap on AIX. Bootstrapped on powerpc-ibm-aix7.3.0.0 libgfortran/ChangeLog: * config/t-aix (all-local, libcaf_single): Explicitly reference caf/.libs/single.o diff --git a/libgfortran/config/t-aix b/libgfortran/config/t-aix index 0e50501d10e..099fc5d8b3a 100644 --- a/libgfortran/config/t-aix +++ b/libgfortran/config/t-aix @@ -7,6 +7,6 @@ ARX=$(shell echo $(AR) | sed -e 's/-X[^ ]*//g') all-local: $(ARX) -X$(BITS) rc .libs/$(PACKAGE).a ../ppc$(BITS)/$(PACKAGE)/.libs/$(PACKAGE).so.$(MAJOR) $(ARX) -X$(BITS) rc ../pthread/$(PACKAGE)/.libs/$(PACKAGE).a ../pthread/ppc$(BITS)/$(PACKAGE)/.libs/$(PACKAGE).so.$(MAJOR) - $(ARX) -X$(BITS) rc .libs/libcaf_single.a ../ppc$(BITS)/$(PACKAGE)/.libs/$(libcaf_single_la_OBJECTS:.lo=.o) - $(ARX) -X$(BITS) rc ../pthread/$(PACKAGE)/.libs/libcaf_single.a ../pthread/ppc$(BITS)/$(PACKAGE)/.libs/$(libcaf_single_la_OBJECTS:.lo=.o) + $(ARX) -X$(BITS) rc .libs/libcaf_single.a ../ppc$(BITS)/$(PACKAGE)/caf/.libs/single.o + $(ARX) -X$(BITS) rc ../pthread/$(PACKAGE)/.libs/libcaf_single.a ../pthread/ppc$(BITS)/$(PACKAGE)/caf/.libs/single.o endif
Re: [PATCH] testsuite, rs6000: Remove some checks with aix[456]
On Wed, May 8, 2024 at 2:36 AM Kewen.Lin wrote:
> Hi,
>
> Since r12-75-g0745b6fa66c69c aix6 support had been dropped,
> so we don't need to check for aix[456].* when testing, this
> patch is to remove such checks.
>
> Regtested on powerpc64-linux-gnu P8/P9 and
> powerpc64le-linux-gnu P9 and P10.
>
Okay
>
> I'm going to push this soon if no objections.
>
> BR,
> Kewen
> -
>
> gcc/testsuite/ChangeLog:
>
> * lib/target-supports.exp
> (check_effective_target_powerpc_altivec_ok): Remove checks for
> aix[456].*
> (check_effective_target_powerpc_p9modulo_ok): Likewise.
> (check_effective_target_powerpc_float128_sw_ok): Likewise.
> (check_effective_target_powerpc_float128_hw_ok): Likewise.
> (check_effective_target_powerpc_vsx_ok): Likewise.
> ---
> gcc/testsuite/lib/target-supports.exp | 29 ---
> 1 file changed, 29 deletions(-)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index 3a55b2a4159..16dc2766850 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -6963,11 +6963,6 @@ proc check_effective_target_powerpc_altivec_ok { } {
> # Paired Single, then not ok
> if { [istarget powerpc-*-linux*paired*] } { return 0 }
>
> -# AltiVec is not supported on AIX before 5.3.
> -if { [istarget powerpc*-*-aix4*]
> -|| [istarget powerpc*-*-aix5.1*]
> -|| [istarget powerpc*-*-aix5.2*] } { return 0 }
> -
> # Return true iff compiling with -maltivec does not error.
> return [check_no_compiler_messages powerpc_altivec_ok object {
> int dummy;
> @@ -6980,12 +6975,6 @@ proc check_effective_target_powerpc_p9modulo_ok { }
> {
> if { ([istarget powerpc*-*-*]
> && ![istarget powerpc-*-linux*paired*])
> || [istarget rs6000-*-*] } {
> - # AltiVec is not supported on AIX before 5.3.
> - if { [istarget powerpc*-*-aix4*]
> -|| [istarget powerpc*-*-aix5.1*]
> -|| [istarget powerpc*-*-aix5.2*] } {
> - return 0
> - }
> return [check_no_compiler_messages powerpc_p9modulo_ok object {
> int main (void) {
> int i = 5, j = 3, r = -1;
> @@ -7116,12 +7105,6 @@ proc check_effective_target_powerpc_float128_sw_ok
> { } {
> if { ([istarget powerpc*-*-*]
> && ![istarget powerpc-*-linux*paired*])
> || [istarget rs6000-*-*] } {
> - # AltiVec is not supported on AIX before 5.3.
> - if { [istarget powerpc*-*-aix4*]
> -|| [istarget powerpc*-*-aix5.1*]
> -|| [istarget powerpc*-*-aix5.2*] } {
> - return 0
> - }
> # Darwin doesn't have VSX, so no soft support for float128.
> if { [istarget *-*-darwin*] } {
> return 0
> @@ -7146,12 +7129,6 @@ proc check_effective_target_powerpc_float128_hw_ok
> { } {
> if { ([istarget powerpc*-*-*]
> && ![istarget powerpc-*-linux*paired*])
> || [istarget rs6000-*-*] } {
> - # AltiVec is not supported on AIX before 5.3.
> - if { [istarget powerpc*-*-aix4*]
> -|| [istarget powerpc*-*-aix5.1*]
> -|| [istarget powerpc*-*-aix5.2*] } {
> - return 0
> - }
> # Darwin doesn't run on any machine with float128 h/w so far.
> if { [istarget *-*-darwin*] } {
> return 0
> @@ -7215,12 +7192,6 @@ proc check_effective_target_powerpc_vsx_ok { } {
> if { ([istarget powerpc*-*-*]
> && ![istarget powerpc-*-linux*paired*])
> || [istarget rs6000-*-*] } {
> - # VSX is not supported on AIX before 7.1.
> - if { [istarget powerpc*-*-aix4*]
> -|| [istarget powerpc*-*-aix5*]
> -|| [istarget powerpc*-*-aix6*] } {
> - return 0
> - }
> # Darwin doesn't have VSX, even if it's used with an assembler
> # which recognises the insns.
> if { [istarget *-*-darwin*] } {
> --
> 2.39.1
>
Re: [PATCH 00/23] prange: pointer ranges
> Tested and benchmarked on x86-64 Linux. Why aren't these patches being tested on all major architectures, especially those available in the Compile Farm? At least for correctness, if not performance. Thanks, David
Re: [patch] Adjust DECL_NAME of virtual clones
On Tue, Aug 20, 2013 at 4:44 AM, Eric Botcazou wrote: >> Dollar sign is not a valid character in symbols on some platforms, such as >> AIX. > > Sure, but DECL_NAME isn't used for any symbol here, unlike > DECL_ASSEMBLER_NAME. Okay, just wanted to make sure. Thanks, David
Re: [PATCH] Rerun df_analyze after delete_unmarked_insns during DCE
This patch has caused a bootstrap failure for powerpc-aix and probably powerpc64-linux. GCC segfaults and core dumps during stage2 configure. The motivation for this patch seems faulty and I strongly request that it be reverted. PR bootstrap/58206 Thanks, David
Re: powerpc64le multilibs and multiarch dir
On Wed, Aug 21, 2013 at 11:57 PM, Alan Modra wrote: > Index: gcc/config/rs6000/t-linux64 > === > --- gcc/config/rs6000/t-linux64 (revision 201834) > +++ gcc/config/rs6000/t-linux64 (working copy) > @@ -25,8 +25,8 @@ > # it doesn't tell anything about the 32bit libraries on those systems. Set > # MULTILIB_OSDIRNAMES according to what is found on the target. > > -MULTILIB_OPTIONS= m64/m32 > -MULTILIB_DIRNAMES = 64 32 > -MULTILIB_EXTRA_OPTS = fPIC > -MULTILIB_OSDIRNAMES= ../lib64$(call if_multiarch,:powerpc64-linux-gnu) > -MULTILIB_OSDIRNAMES+= $(if $(wildcard $(shell echo > $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call > if_multiarch,:powerpc-linux-gnu) > +MULTILIB_OPTIONS:= m64/m32 > +MULTILIB_DIRNAMES := 64 32 > +MULTILIB_EXTRA_OPTS := > +MULTILIB_OSDIRNAMES := m64=../lib64$(call if_multiarch,:powerpc64-linux-gnu) > +MULTILIB_OSDIRNAMES += m32=$(if $(wildcard $(shell echo > $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call > if_multiarch,:powerpc-linux-gnu) What is the purpose of the change to MULTILIB_OSDIRNAMES? Why the addition of m64= and m32=? A secondary tmake file is not always set to post-process those macros, AFAICT. Thanks, David
Re: powerpc64le multilibs and multiarch dir
On Thu, Aug 22, 2013 at 7:15 PM, Alan Modra wrote: > Without another tmake file it really is exactly the same as before. > > old, after applying "make" string gunk > MULTILIB_OPTIONS = m64/m32 > MULTILIB_OSDIRNAMES = ../lib64 ../lib > > new > MULTILIB_OPTIONS = m64/m32 > MULTILIB_OSDIRNAMES = m64=../lib64 m32=../lib > > Either way, -m64 objects use ../lib64 and -m32 ../lib. > > > new with le multilib > MULTILIB_OPTIONS = m64/m32 mlittle > MULTILIB_OSDIRNAMES = m64=../lib64 m32=../lib m64.mlittle=../lib64le > m32.mlittle=../lible Okay, I see how it's duplicating the meaning of the positional arguments. The patch is okay. Thanks, David
Re: Ubsan merged into trunk
This patch / merge broke bootstrap on AIX: In file included from ./tm.h:18:0, from /home/dje/src/src/gcc/function.h:26, from /home/dje/src/src/gcc/basic-block.h:25, from /home/dje/src/src/gcc/cgraph.h:28, from /home/dje/src/src/gcc/ubsan.c:25: /home/dje/src/src/gcc/ubsan.c: In function 'tree_node* ubsan_type_descriptor(tree)': /home/dje/src/src/gcc/config/rs6000/xcoff.h:262:63: error: 'rs6000_xcoff_strip_dollar' was not declared in this scope sprintf (LABEL, "*%s..%u", rs6000_xcoff_strip_dollar (PREFIX), (unsigned) (NUM)) ^ /home/dje/src/src/gcc/ubsan.c:282:3: note: in expansion of macro 'ASM_GENERATE_INTERNAL_LABEL' ASM_GENERATE_INTERNAL_LABEL (tmp_name, "Lubsan_type", type_var_id_num++); ^ /home/dje/src/src/gcc/ubsan.c: In function 'tree_node* ubsan_create_data(const char*, location_t, ...)': /home/dje/src/src/gcc/config/rs6000/xcoff.h:262:63: error: 'rs6000_xcoff_strip_dollar' was not declared in this scope sprintf (LABEL, "*%s..%u", rs6000_xcoff_strip_dollar (PREFIX), (unsigned) (NUM)) If you use macros like ASM_GENERATE_INTERNAL_LABEL, which may cal target-specific functions, you need to include tm_p.h to pull in -protos.h. Thanks, David
[PATCH,fixincldes] AIX assert.h static_assert
In a recent change to AIX 7, the assert.h header defines
static_assert. I presume this was intended not to avoid conflicts
with the new C++ keyword. Sigh. However, the definition is not
protected from C++, which causes problem if the header is included in
C++ code, which it is in libstdc++. This fixincludes patch protects
the definition so that it only applies to ISO C code.
Bootstrapped on powerpc-ibm-aix7.1.0.0
Thanks, David
* inclhack.def (aix_assert): New fix.
* fixincl.x: Regenerate.
* tests/base/assert.h [AIX_ASSERT_CHECK]: New check.
Index: inclhack.def
===
--- inclhack.def(revision 202134)
+++ inclhack.def(working copy)
@@ -569,6 +569,20 @@
};
/*
+ * assert.h on AIX 7 redefines static_assert as _Static_assert without
+ * protecting C++.
+ */
+fix = {
+hackname = aix_assert;
+mach = "*-*-aix*";
+files = assert.h;
+select= "#define[ \t]static_assert[ \t]_Static_assert";
+c_fix = format;
+c_fix_arg = "#ifndef __cplusplus\n%0\n#endif";
+test_text = "#define static_assert _Static_assert";
+};
+
+/*
* complex.h on AIX 5 and AIX 6 define _Complex_I and I in terms of __I,
* which only is provided by AIX xlc C99.
*/
[PATCH,committed] AIX alias fix
varasm.c do_assemble_alias() calls globalize_decl() before creating an
alias for a global symbol. For FUNCTION_DECLs
ASM_OUTPUT_DEF_FROM_DECLS on AIX globalizes the code label in addition
to the function descriptor globalized by varasm.c. For
non-TREE_PUBLIC decls, the alias is declared as .lglobl for the code
label, but nothing emits the equivalent for the function descriptor.
The appended patch emits the additional lglobl.
Bootstrapped on powerpc-ibm-aix7.1.0.0
Thanks, David
* config/rs6000/rs6000.h (ASM_OUTPUT_DEF_FROM_DECLS): Emit lglobl for
function descriptor.
Index: rs6000.h
===
--- rs6000.h(revision 202225)
+++ rs6000.h(working copy)
@@ -2142,6 +2142,9 @@
fputs ("\t.lglobl\t.", FILE); \
RS6000_OUTPUT_BASENAME (FILE, alias); \
putc ('\n', FILE);\
+ fputs ("\t.lglobl\t", FILE); \
+ RS6000_OUTPUT_BASENAME (FILE, alias); \
+ putc ('\n', FILE);\
} \
fputs ("\t.set\t.", FILE);\
RS6000_OUTPUT_BASENAME (FILE, alias); \
[PATCH, committed] check_weak_available for AIX
When objdump is not available, check_weak_available is unhappy on AIX.
This hard-codes that AIX supports weak, as is implemented for other
OSes.
Bootstrapped on powerpc-ibm-aix7.1.0.0
Thanks, David
* lib/target-supports.exp (check_weak_available): Return true for AIX.
Index: target-supports.exp
===
--- target-supports.exp (revision 202225)
+++ target-supports.exp (working copy)
@@ -226,6 +226,12 @@
return 1
}
+# All AIX targets should support it
+
+if { [istarget *-*-aix*] } {
+return 1
+}
+
# All solaris2 targets should support it
if { [istarget *-*-solaris2*] } {
[PATCH, committed] Skip undefined weak in testsuite on AIX
AIX does not support undefined weak. Skip those tests in the testsuite.
Also, select COFF as AIX file format without requiring objdump.
* gcc.dg/attr-weakref-1.c: Skip on AIX.
* gcc.dg/torture/pr53922.c: Skip on AIX.
* lib/file-format.exp (gcc_target_object_format): AIX is COFF.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Thanks, David
Index: gcc.dg/attr-weakref-1.c
===
--- gcc.dg/attr-weakref-1.c (revision 202260)
+++ gcc.dg/attr-weakref-1.c (working copy)
@@ -4,7 +4,7 @@
// This test requires support for undefined weak symbols. This support
// is not available on hppa*-*-hpux*. The test is skipped rather than
// xfailed to suppress the warning that would otherwise arise.
-// { dg-skip-if "" { "*-*-darwin*" "hppa*-*-hpux*" } "*" { "" } }
+// { dg-skip-if "" { "*-*-darwin*" "hppa*-*-hpux*" "*-*-aix*" } "*" { "" } }
// For kernel modules and static RTPs, the loader treats undefined weak
// symbols in the same way as undefined strong symbols. The test
// therefore fails to load, so skip it.Index: gcc.dg/torture/pr53922.c
===
--- gcc.dg/torture/pr53922.c(revision 202260)
+++ gcc.dg/torture/pr53922.c(working copy)
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-require-weak "" } */
/* { dg-skip-if "No undefined" { *-*-mingw* } { "*" } { "" } } */
+/* { dg-skip-if "No undefined weak" { *-*-aix* } { "*" } { "" } } */
/* { dg-skip-if "No undefined weak" { hppa*-*-hpux* && { ! lp64 } } {
"*" } { "" } } */
/* { dg-options "-Wl,-undefined,dynamic_lookup" { target *-*-darwin* } } */
Index: lib/file-format.exp
===
--- lib/file-format.exp (revision 202260)
+++ lib/file-format.exp (working copy)
@@ -38,6 +38,9 @@
} else {
set gcc_target_object_format_saved som
}
+} elseif { [istarget *-*-aix*] } {
+ # AIX doesn't necessarily have objdump, so hand-code it.
+ set gcc_target_object_format_saved coff
} else {
set objdump_name [find_binutils_prog objdump]
set open_file [open objfmtst.c w]
Re: [PATCH, powerpc] Rework VSX scalar floating point support
Mike, Why does rs6000_init_hard_regno_mode_ok() include #if 0 code? Because the patch affects e500, has this patch been tested in an e500 configuration? The cover message did not make it clear that you are merging SFmode and DFmode patterns using mode iterators. That really should have been a separate patch. We'll proceed with the current form. But, would you please clarify the ChangeLog entry for rs6000.md to make it clear exactly which patterns are being deleted instead of listing everything as "Likewise"? Thanks, David
Re: [RS6000] powerpc64 -mcmodel=medium large symbol offsets
On Fri, Sep 6, 2013 at 3:13 AM, Alan Modra wrote:
> The following testcase taken from the linux kernel is miscompiled on
> powerpc64-linux.
>
> /* -m64 -mcmodel=medium -O -S -fno-section-anchors */
> static int x;
>
> unsigned long
> foo (void)
> {
> return ((unsigned long) &x) - 0xc000;
> }
>
> generates
> addis 3,2,x+4611686018427387904@toc@ha
> addi 3,3,x+4611686018427387904@toc@l
> blr
>
> losing the top 32 bits of the offset. Sadly, the assembler and linker
> do not complain, which is a hole in the ABI. (@ha and _HA relocs as
> per the ABI won't complain about overflow since they might be used in
> a @highesta, @highera sequence loading a 64-bit value.)
>
> This patch stops combine merging large offsets into a symbol addend
> by copying code from reg_or_add_cint_operand to a new predicate,
> add_cint_operand, and using that to restrict the range of offsets.
> Bootstrapped and regression tested powerpc64-linux. OK to apply?
>
> * config/rs6000/predicates.md (add_cint_operand): New.
> * config/rs6000/rs6000.md (largetoc_high_plus): Restrict offset
> using add_cint_operand.
> (largetoc_high_plus_aix): Likewise.
This patch should include a testcase.
But what user feedback are you expecting if the offset is too large,
such as your example? In my test with the patch, it produces an
unrecognizable insn error, which seems less than friendly.
Thanks, David
Re: [RS6000] powerpc64 -mcmodel=medium large symbol offsets
On Mon, Sep 9, 2013 at 5:07 AM, Alan Modra wrote: > Revised patch with testcase. This one also fixes a small problem with > reg_or_add_cint_operand in that any 32-bit value is valid for SImode. > Compare with reg_or_sub_cint_operand. > > Bootstrapped and regression tested powerpc64-linux. OK to apply? > > gcc/ > * config/rs6000/predicates.md (add_cint_operand): New. > (reg_or_add_cint_operand): Use add_cint_operand. > * config/rs6000/rs6000.md (largetoc_high_plus): Restrict offset > using add_cint_operand. > (largetoc_high_plus_aix, small_toc_ref): Likewise. > gcc/testsuite/ > * gcc.target/powerpc/medium_offset.c: New. Okay. This seems much better. Thanks, David
Re: [RS6000] Fix PR58330 powerpc64 atomic store split in two
On Mon, Sep 9, 2013 at 8:21 AM, Alan Modra wrote: > This patch prevents the powerpc backend from combining a 64-bit > volatile load or store with a bswap insn when the resulting combined > insn will be implemented as two lwbrx or stwbrx machine insns. > Bootstrapped and regression tested powerpc64-linux. > > PR target/58330 > * config/rs6000/rs6000.md (bswapdi2_64bit): Disable for volatile mems. > gcc/testsuite/ > * gcc.target/powerpc/pr58330.c: New. Heh, this is an interesting bug. Okay. Thanks, David
Re: [RS6000] powerpc64 -mcmodel=medium large symbol offsets
On Wed, Sep 11, 2013 at 7:12 AM, Alan Modra wrote: > On Mon, Sep 09, 2013 at 06:37:03PM +0930, Alan Modra wrote: >> gcc/ >> * config/rs6000/predicates.md (add_cint_operand): New. >> (reg_or_add_cint_operand): Use add_cint_operand. >> * config/rs6000/rs6000.md (largetoc_high_plus): Restrict offset >> using add_cint_operand. >> (largetoc_high_plus_aix, small_toc_ref): Likewise. >> gcc/testsuite/ >> * gcc.target/powerpc/medium_offset.c: New. > > I missed seeing one testcase regression caused by this patch. :-( > gcc.c-torture/compile/pr41634.c at -O3 gets an "insn does not satisfy > its constraints". Fixed with the following. OK to apply? > > * config/rs6000/rs6000.c (toc_relative_expr_p): Use add_cint_operand. Okay. Thanks, David
Re: [PATCH], PR target/58452, Fix gcc 4.8/trunk linuxpaired breakage
On Tue, Sep 17, 2013 at 8:03 PM, Michael Meissner wrote: > While doing some work on power8, I wanted to make sure that for existing > systems, I was generating the same code. So I built some code and ran it > through various -mcpu= options. When I built a powerpc-linuxpaired > compiler, the compiler has trouble with a simple loop that should be > vectorized. I traced the code to changes in the vectorizer that required the > predicates for movmismalign* to accept memory operands. > I will do the usual bootstrap/make check tomorrow. Assuming it has no > regressions, can I check this patch it to both the 4.8 branch and trunk? > > 2013-09-17 Michael Meissner > > PR target/58452 > * config/rs6000/paired.md (movmisalignv2sf): Fix to allow memory > operaands. Okay. Thanks, David
Re: libtool update for powerpc64le-linux
I guess I can't really expect to gain an approval to import the upstream libtool into gcc. Even *I* don't really trust me, although having looked at it a little I think I could even update libjava/libltdl. So how about just continuing the status quo and applying a libtool patch that is already upstream? Bootstrapped powerpc64le-linux and powerpc64-linux. OK to apply? * libtool.m4 (_LT_ENABLE_LOCK ): Remove non-canonical ppc host match. Support little-endian powerpc linux hosts. libjava/libltdl/ * acinclude.m4 (_LT_ENABLE_LOCK ): Remove non-canonical ppc host match. Support little-endian powerpc linux hosts. * configure: Regenerate. boehm-gc/ * configure: Regenerate. gcc/ * configure: Regenerate. * aclocal.m4: Regenerate. fixincludes/ * configure: Regenerate. libatomic/ * configure: Regenerate. libbacktrace/ * configure: Regenerate. libffi/ * configure: Regenerate. libgfortran/ * configure: Regenerate. libgomp/ * configure: Regenerate. libitm/ * configure: Regenerate. libjava/ * configure: Regenerate. libjava/classpath/ * configure: Regenerate. libmudflap/ * configure: Regenerate. libobjc/ * configure: Regenerate. libquadmath/ * configure: Regenerate. libsanitizer/ * configure: Regenerate. libssp/ * configure: Regenerate. libstdc++-v3/ * configure: Regenerate. libvtv/ * configure: Regenerate. lto-plugin/ * configure: Regenerate. zlib/ * configure: Regenerate. This is okay. Please ensure that you use the correct version of autoconf to regenerate the files. I don't think that the same version of autoconf is used in all directories. Please visually inspect the diff, which only should change the specific lines. And please manually re-generate any configure files shared with "src". Thanks, David
Re: [PATCH] Fix PR58417
This patch has caused 6 new libstdc++ failures on AIX. All look like: /home/dje/src/src/libstdc++-v3/testsuite/ext/random/normal_mv_distribution/cons/default.cc:49:1: internal compiler error: in build_polynomial_chrec, at tree-chrec.h:148 } - David
Re: [PATCH, powerpc] Rework#2 VSX scalar floating point support, patch #1
On Fri, Sep 20, 2013 at 7:32 PM, Michael Meissner wrote: > I am now breaking the patches down to be more bite size. Ultimately, I hope > these patches will provide support to allow scalar floating point to occupy > the > Altivec (upper) registers if the ISA allows it (ISA 2.06 for DFmode, ISA 2.07 > for SFmode). One effect of later patches will be to go back to using the > traditional DFmode instructions for VSX if all of the registers come from the > traditional floating point register set. > > This patch adds the new switches, and constraints that will be used in future > patches. It produces exactly the same code on the targets I tested on and > passes the bootstrap/make check stages. Is it ok to apply this patch? > > I have tested the code generation for the following targets: > > power4, power5, power5+, power6, power6x, power7, power8 for 64/32-bit > power7 with VSX disabled using altivec instructions for 64/32-bit > power7 with both VSX and altivec disabled for 64/32-bit > cell 64/32-bit > e5500, e6500 64/32-bit > G4 32-bit > G5 64/32-bit > linuxpaired 32-bit > linuxspe 32-bit > > 2013-09-20 Michael Meissner > > * config/rs6000/rs6000.h (enum r6000_reg_class_enum): Add new > constraints: wu, ww, and wy. Repurpose wv constraint added during > power8 changes. Put wg constraint in alphabetical order. > > * config/rs6000/rs6000.opt (-mvsx-scalar-float): New debug switch > for future work to add ISA 2.07 VSX single precision support. > (-mvsx-scalar-double): Change default from -1 to 1, update > documentation comment. > (-mvsx-scalar-memory): Rename debug switch to -mupper-regs-df. > (-mupper-regs-df): New debug switch to control whether DF values > can go in the traditional Altivec registers. > (-mupper-regs-sf): New debug switch to control whether SF values > can go in the traditional Altivec registers. > > * config/rs6000/rs6000.c (rs6000_debug_reg_global): Print wu, ww, > and wy constraints. > (rs6000_init_hard_regno_mode_ok): Use ssize_t instead of int for > loop variables. Rename -mvsx-scalar-memory to -mupper-regs-df. > Add new constraints, wu/ww/wy. Repurpose wv constraint. > (rs6000_debug_legitimate_address_p): Print if we are running > before, during, or after reload. > (rs6000_secondary_reload): Add a comment. > (rs6000_opt_masks): Add -mupper-regs-df, -mupper-regs-sf. > > * config/rs6000/constraints.md (wa constraint): Sort w > constraints. Update documentation string. > (wd constraint): Likewise. > (wf constraint): Likewise. > (wg constraint): Likewise. > (wn constraint): Likewise. > (ws constraint): Likewise. > (wt constraint): Likewise. > (wx constraint): Likewise. > (wz constraint): Likewise. > (wu constraint): New constraint for ISA 2.07 SFmode scalar > instructions. > (ww constraint): Likewise. > (wy constraint): Likewise. > (wv constraint): Repurpose ISA 2.07 constraint that we not used in > the previous submissions. > * doc/md.texi (PowerPC and IBM RS6000): Likewise. This patch is okay. Thanks, David
Re: [PATCH, powerpc] Rework#2 VSX scalar floating point support, patch #2
On Mon, Sep 23, 2013 at 4:06 PM, Michael Meissner wrote: > This patch is an infrastructure patch that combines the 3 reload helper > function arrays into a single array of structures. All machines generate the > same code with this patch (and no regressions were found in bootstrap/make > check). Is it ok to apply? > > 2013-09-23 Michael Meissner > > * config/rs6000/rs6000.c (rs6000_vector_reload): Delete, combine > reload helper function arrays into a single array reg_addr. > (reload_fpr_gpr): Likewise. > (reload_gpr_vsx): Likewise. > (reload_vsx_gpr): Likewise. > (struct rs6000_reg_addr): Likewise. > (reg_addr): Likewise. > (rs6000_debug_reg_global): Change rs6000_vector_reload, > reload_fpr_gpr, reload_gpr_vsx, reload_vsx_gpr uses to reg_addr. > (rs6000_init_hard_regno_mode_ok): Likewise. > (rs6000_secondary_reload_direct_move): Likewise. > (rs6000_secondary_reload): Likewise. Okay. Thanks, David
Re: [PATCH, powerpc] Rework#2 VSX scalar floating point support, patch #3
On Tue, Sep 24, 2013 at 4:33 PM, Michael Meissner
wrote:
> This patch adds the initial support for putting DI, DF, and SF values in the
> upper registers (traditional Altivec registers) using the -mupper-regs-df and
> -mupper-regs-sf patches. Those switches will not be enabled by default until
> the rest of the changes are made. This patch passes the bootstrap test and
> make check test. I tested all of the targets I tested previously (power4-8,
> G4/G5, SPE, cell, e5500/e5600, and paired floating point), and all machines
> generate the same code. Is it ok to install this patch?
>
> [gcc]
> 2013-09-24 Michael Meissner
>
> * config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok): Allow
> DFmode, DImode, and SFmode in the upper VSX registers based on the
> -mupper-regs-{df,sf} flags. Fix wu constraint to be ALTIVEC_REGS
> if -mpower8-vector. Combine -mvsx-timode handling with the rest
> of the VSX register handling.
>
> * config/rs6000/rs6000.md (f32_lv): Use %x0 for VSX regsters.
> (f32_sv): Likewise.
> (zero_extendsidi2_lfiwzx): Add support for loading into the
> Altivec registers with -mpower8-vector. Use wu/wv constraints to
> only do VSX memory options on Altivec registers.
> (extendsidi2_lfiwax): Likewise.
> (extendsfdf2_fpr): Likewise.
> (mov_hardfloat, SF/SD modes): Likewise.
> (mov_hardfloat32, DF/DD modes): Likewise.
> (mov_hardfloat64, DF/DD modes): Likewise.
> (movdi_internal64): Likewise.
>
> [gcc/testsuite]
> 2013-09-24 Michael Meissner
>
> * gcc.target/powerpc/p8vector-ldst.c: New test for -mupper-regs-sf
> and -mupper-regs-df.
Okay.
Thanks, David
[PATCH, committed] Update t-rs6000 for automatic dependencies
All of the rs6000-specific dependencies are included and discovered automatically. Bootstrapped on powerpc-ibm-aix7.1.0.0. David * config/rs6000/t-rs6000 (rs6000.o): Remove. (rs6000-c.o): Use COMPILE and POSTCOMPILE. Index: config/rs6000/t-rs6000 === --- config/rs6000/t-rs6000 (revision 202942) +++ config/rs6000/t-rs6000 (working copy) @@ -20,22 +20,10 @@ TM_H += $(srcdir)/config/rs6000/rs6000-builtin.def -rs6000.o: $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ - $(RTL_H) $(REGS_H) hard-reg-set.h \ - real.h insn-config.h conditions.h insn-attr.h flags.h $(RECOG_H) \ - $(OBSTACK_H) $(TREE_H) $(EXPR_H) $(OPTABS_H) except.h function.h \ - output.h dbxout.h $(BASIC_BLOCK_H) toplev.h $(GGC_H) $(HASHTAB_H) \ - $(TM_P_H) $(TARGET_H) $(TARGET_DEF_H) langhooks.h reload.h gt-rs6000.h \ - cfgloop.h $(OPTS_H) $(COMMON_TARGET_H) dumpfile.h \ - $(srcdir)/config/rs6000/rs6000-cpus.def +rs6000-c.o: $(srcdir)/config/rs6000/rs6000-c.c + $(COMPILE) $< + $(POSTCOMPILE) -rs6000-c.o: $(srcdir)/config/rs6000/rs6000-c.c \ -$(srcdir)/config/rs6000/rs6000-protos.h \ -$(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(CPPLIB_H) \ -$(TM_P_H) $(C_PRAGMA_H) errors.h coretypes.h $(TM_H) - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ - $(srcdir)/config/rs6000/rs6000-c.c - $(srcdir)/config/rs6000/rs6000-tables.opt: $(srcdir)/config/rs6000/genopt.sh \ $(srcdir)/config/rs6000/rs6000-cpus.def $(SHELL) $(srcdir)/config/rs6000/genopt.sh $(srcdir)/config/rs6000 > \
Re: [PATCH, powerpc] Rework#2 VSX scalar floating point support, patch #3
On Thu, Sep 26, 2013 at 4:51 PM, Michael Meissner wrote: > I discovered that I was setting the wv/wu constraints incorrectly to > ALTIVEC_REGS, which leads to reload failures in some cases. > > Is this patch ok to apply along with the previous patch assuming it bootstraps > and has no regressions with make check? It builds the programs that had > failures with the previous patch. > > 2013-09-26 Michael Meissner > > * config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Don't > allow wv/wu constraints to be ALTIVEC_REGISTERS unless DF/SF can > occupy the Altivec registers. Okay. Can you add a testcase to catch this in the future? Thanks, David
Re: [PATCH, powerpc] Rework#2 VSX scalar floating point support, patch #4
On Tue, Oct 1, 2013 at 1:52 PM, Michael Meissner wrote: > This patch moves most of the VSX DFmode operations from vsx.md to rs6000.md to > use the traditional floating point instructions (f*) instead of the VSX scalar > instructions (xs*) if all of the registers come from the traditional floating > point register set. The add, subtract, multiply, divide, reciprocal estimate, > square root, absolute value, negate, round functions, and multiply/add > instructions were changed. Some of the converts have not been changed with > these patches. If the -mupper-regs-df switch is used, it will attempt to use > the upper registers (those that overlay on the traditional Altivec register > set). > > This patch also combines the scalar SFmode/DFmode support on non-SPE systems. > It adds in ISA 2.07 (power8) single precision floating point support if the > -mupper-regs-sf switch is used. > > At present, neither -mupper-regs-df nor -mupper-regs-sf is usable if reload > has > to do anything. A future patch will address this. > > I did need to adjust a few tests that were specifically testing VSX scalar > code > generation. In addition, I put in a simple test to make sure the initial > -mupper-regs-df and -mupper-regs-sf works correctly. > > I tested this an except for power7, power8 I could not find any changes in > code > generated for power4, power5, power6, power6x, G4, G5, cell, e5500, e6500, > xilinx (sp_full, sp_lite, dp_full, dp_lite, none), 8548/8540 (spe), 750cl > (paired floating point). > > For VSX systems there is code generation differences: > > 1) The traditional fp instruction is generated instead of VSX; > > 2) Because of #1, the code generator favors the 4 operand of multiply/add > instructions, where the target register does not overlap with any of > the inputs over the VSX version that that requires overlap. > > 3) A few of the vectorized tests on power8 now generate more direct move > instructions, instead of moving values through the stack than > previously. These tests are integer tests, where you are doing an > operation between an integer vector and a scalar value. Previously in > some cases, the register allocator would store the value from a GPR > and > reload it to the vector registers. > > 4) There is a slight scheduling difference in doing long double abs, that > causes a different register to be used. The code for long double abs > needs to be improved in any case (the early splitting is causing > spills > to the stack). > > I had no differences in doing bootstrap and make check (with the testsuite > fixes applied). > > In addition, I am running Spec 2006 floating point tests on a power7 box to > compare the effects of going back to the traditional floating point tests. > For > most tests, there is less than 2% difference between the runs. One benchmark > (482.sphinx3) is slightly faster with these changes, and it is dominated by > floating point multiply/add operations. > > Can I apply these patches? > > [gcc] > 2013-09-30 Michael Meissner > > * config/rs6000/rs6000-builtin.def (XSRDPIM): Use floatdf2, > ceildf2, btruncdf2, instead of vsx_* name. > > * config/rs6000/vsx.md (vsx_add3): Change arithmetic > iterators to only do V2DF and V4SF here. Move the DF code to > rs6000.md where it is combined with SF mode. Replace with > just 'v' since only vector operations are handled with these insns > after moving the DF support to rs6000.md. > (vsx_sub3): Likewise. > (vsx_mul3): Likewise. > (vsx_div3): Likewise. > (vsx_fre2): Likewise. > (vsx_neg2): Likewise. > (vsx_abs2): Likewise. > (vsx_nabs2): Likewise. > (vsx_smax3): Likewise. > (vsx_smin3): Likewise. > (vsx_sqrt2): Likewise. > (vsx_rsqrte2): Likewise. > (vsx_fms4): Likewise. > (vsx_nfma4): Likewise. > (vsx_copysign3): Likewise. > (vsx_btrunc2): Likewise. > (vsx_floor2): Likewise. > (vsx_ceil2): Likewise. > (vsx_smaxsf3): Delete scalar ops that were moved to rs6000.md. > (vsx_sminsf3): Likewise. > (vsx_fmadf4): Likewise. > (vsx_fmsdf4): Likewise. > (vsx_nfmadf4): Likewise. > (vsx_nfmsdf4): Likewise. > (vsx_cmpdf_internal1): Likewise. > > * config/rs6000/rs6000.h (TARGET_SF_SPE): Define macros to make it > simpler to select whether a target has SPE or traditional floating > point support in iterators. > (TARGET_DF_SPE): Likewise. > (TARGET_SF_FPR): Likewise. > (TARGET_DF_FPR): Likewise. > (TARGET_SF_INSN): Macros to say whether floating point support > exists for a given operation for expanders. > (TARGET_DF_INSN): Likewise. > > * config/rs6000/rs6000.c (Ftrad): New mode attributes to allow > co
[PATCH] Disable updating VRSAVE everywhere except Darwin
The following proposed patch disables setting, saving and restoring the VRSAVE register on all targets except Darwin. VRSAVE was removed from the AIX ABI and was suppose to have been removed from the PPC SVR4 ABI. All recent versions of the Linux kernel set and maintain VRSAVE itself, as a process-level flag, not as individual bits, so no need for the compiler to set the register or to save and restore it across calls. All uses of VRSAVE (e.g., GLibc) will continue to work using the value set by the kernel. Comments? - David * config/rs6000/rs6000.c (rs6000_option_override_internal): Do not set TARGET_ALTIVEC_VRSAVE for TARGET_ELF. (rs6000_stack_info): Only set vrsave_mask for Darwin. Index: rs6000.c === *** rs6000.c(revision 191810) --- rs6000.c(working copy) *** rs6000_option_override_internal (bool gl *** 2725,2734 else rs6000_altivec_abi = 1; } - - /* Enable VRSAVE for AltiVec ABI, unless explicitly overridden. */ - if (!global_options_set.x_TARGET_ALTIVEC_VRSAVE) - TARGET_ALTIVEC_VRSAVE = rs6000_altivec_abi; } /* Set the Darwin64 ABI as default for 64-bit Darwin. --- 2725,2730 *** rs6000_stack_info (void) *** 17842,17848 else info_ptr->spe_gp_size = 0; ! if (TARGET_ALTIVEC_ABI) info_ptr->vrsave_mask = compute_vrsave_mask (); else info_ptr->vrsave_mask = 0; --- 17838,17845 else info_ptr->spe_gp_size = 0; ! /* Only set VRSAVE register on Darwin. */ ! if (DEFAULT_ABI == ABI_DARWIN) info_ptr->vrsave_mask = compute_vrsave_mask (); else info_ptr->vrsave_mask = 0;
Re: [PATCH] Disable updating VRSAVE everywhere except Darwin
On Sat, Sep 29, 2012 at 11:08 AM, Segher Boessenkool wrote: >> The following proposed patch disables setting, saving and restoring >> the VRSAVE register on all targets except Darwin. >> >> VRSAVE was removed from the AIX ABI and was suppose to have been >> removed from the PPC SVR4 ABI. All recent versions of the Linux >> kernel set and maintain VRSAVE itself, as a process-level flag, not as >> individual bits, so no need for the compiler to set the register or to >> save and restore it across calls. All uses of VRSAVE (e.g., GLibc) >> will continue to work using the value set by the kernel. > > I don't think you can assume all embedded users do not use VRSAVE (or > even the majority). And what about *BSD? Freescale customers do not use it. Most embedded processors do not contain VMX. The SVR4 ABI is being corrected to correctly describe that it is not used. *BSDs can set it if they want, but it actually is less efficient to use the mask. - David
[PATCH,fixincludes] Wrap fcntl.h on AIX
AIX fcntl.h redefines "open", which conflicts with g++ fstream header.
This patch wraps fcntl.h to use aliases in the same way that stdio.h
currently is wrapped.
Okay?
Thanks, David
* inclhack.def (AAB_aix_fcntl): New fix.
* fixincl.x: Regenerate.
* tests/base/fcntl.h [AAB_AIX_FCNTL_CHECK]: New.
Index: inclhack.def
===
--- inclhack.def(revision 191846)
+++ inclhack.def(working copy)
@@ -65,6 +65,45 @@
};
+/* On AIX when _LARGE_FILES is defined fcntl.h defines open to
+ * open64 and creat to creat64. This fixes fcntl.h to
+ * undef those defines and use __asm__ to alias the symbols if
+ * building with g++ and -D_LARGE_FILES
+ */
+fix = {
+hackname = AAB_aix_fcntl;
+files = fcntl.h;
+select= "define open[ \t]open64";
+mach = "*-*-aix*";
+test-text = ''; /* no way to test */
+
+c_fix = wrap;
+
+c_fix_arg = "";
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined __GNUG__ && defined _LARGE_FILES && defined __cplusplus
+ #define __need__aix_fcntl_h_fix
+ #ifdef __need__aix_fcntl_h_fix
+ #undef open
+ #undef creat
+ #undef openat
+ /* Alias the symbols using asm */
+ extern "C" {
+ extern int open(const char *, int, ...) __asm__("open64");
+ extern int creat(const char *, mode_t) __asm__("creat64");
+ #if (_XOPEN_SOURCE >= 700)
+ extern int openat(int, const char *, int, ...) __asm__("open64at");
+ #endif
+ }
+ #endif
+ #endif
+
+ _EOArg_;
+};
+
+
/*
* On Mac OS 10.3.9, the 'long double' functions are available in
* libSystem, but are not prototyped in math.h.
Re: [PATCH,fixincludes] Wrap fcntl.h on AIX
On Sat, Sep 29, 2012 at 2:00 PM, Bruce Korb wrote: > Does "make check" complain if a replacement/wrap fix doesn't have a test? > If so, I'll be fixing it when I have time -- towards the end of October. > (The patch I sent a few days ago ought to do it, but I've not fully tested > yet.) > Anyway, looks pretty reasonable to me... The stdio fix already includes the same test. - David
Re: [PATCH rs6000 testsuite] Fix a couple tests for VSX scalar instructions
On Mon, Oct 1, 2012 at 6:03 PM, Pat Haugen wrote: > This patch fixes a couple failures that occur if the testsuite is run with > -mvsx and the VSX scalar sqrt instructions are generated. Ok for trunk? > > -Pat > > > testsuite/ChangeLog: > 2012-10-01 Pat Haugen > > * gcc.target/powerpc/pr46728-1.c: Accept xssqrtdp. > * gcc.target/powerpc/pr46728-2.c: Likewise. LGTM. Thanks, David
Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2d
On Mon, Oct 1, 2012 at 7:11 PM, Michael Meissner wrote: > 2012-10-01 Michael Meissner > > * config/rs6000/rs6000.c (rs6000_option_override_internal): If > -mcpu= is not specified and the compiler is not configured > using --with-cpu=, use the bits from the TARGET_DEFAULT to > set the initial options. > > I reworked the patch to allow TARGET_DEFAULT bits to be set if there is no > -mcpu= and the compiler was not configured using --with-cpu=, so > that > we don't first clear all of the ISA bits, set them from the cpu, and then > merge > back in the TARGET_DEFAULT bits. This version of the patch is good. Thanks, David
Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars
Tobias,
Sorry to return to this patch so long after the discussion, but I have
been investigating testsuite failures on AIX and this patch introduced
a number of Fortran failures.
+ if (sym->module)
+ name = gfc_get_string (".__%s_MOD_%s", sym->module, sym->name);
+ else
+ name = gfc_get_string (".%s", sym->name);
Symbols beginning with "." have a well-known meaning on AIX, so the
compiler cannot assume that it is safe to mangle a name by prepending
a period.
For instance, the test allocatable_function_5.s generates the
following global symbol definitions in the assembler:
.globl __m_MOD_mbar
.globl .__m_MOD_mbar
.csect __m_MOD_mbar[DS]
__m_MOD_mbar: <--- function
descriptor __m_MOD_mbar
.long .__m_MOD_mbar, TOC[tc0], 0
.csect .text[PR]
.__m_MOD_mbar: <--- function address
.__m_MOD_mbar
...
.globl .__m_MOD_mbar
.csect .data[RW],4
.align 2
.__m_MOD_mbar: <--- mangled string
name .__m_MOD_mbar
.space 4
Unsurprisingly, two symbols with the same name are a problem and the
AIX assembler complains about the redefinition.
I am not sure why you chose a period and how best to correct this.
Thanks, David
Re: [PATCH] rs6000: Remove 'A' output modifier
On Wed, Oct 3, 2012 at 6:28 PM, Segher Boessenkool wrote: > It was used for old POWER only, which has been removed. > > Tested etc.; okay to apply? > > > Segher > > > 2012-10-04 Segher Boessenkool > > gcc/ > * config/rs6000/rs6000.c (print_operand) ['A']: Delete. Okay. Thanks, David
Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars
For C and C++, identifiers beginning with underscore and upper case letter or with two underscores are reserve to the implementation. C++ uses _Z for mangling. Maybe Fortran could prepend "_F". Something beginning with an underscore seems like a much better choice, given the rules about reserved identifiers. Thanks, David On Wed, Oct 3, 2012 at 5:00 PM, Tobias Burnus wrote: > David, > > > David Edelsohn wrote: >> >> I am not sure why you chose a period and how best to correct this. > > > Well, in principle any name which the user cannot enter would do. (Not > enter: At least not as valid Fortran identifier.) > > The reason for choosing "." is that is used elsewhere in > gfortran for such identifier for the string-length variable belonging to > , e.g. "._result" in trans-decl.c. I assume the reason that it > didn't pop up with those is that those are local variables, but I wouldn't > be surprised if it would break elsewhere. > > I wonder whether "@" would work, otherwise, one could also use "_". The only > other problem is that it will break the ABI. On the other hand, it's a > rather new feature and if we bump the .mod version number, the chance that > one effectively forces the user to re-compile is rather high. So far we > always bumped the .mod version number as something changed. There are also > some other patches pending which effectively lead to a bump in the .mod > version. > > (The .mod version won't affect code which doesn't use modules such as > BLAS/LAPACK or any Fortran 66/77 code, but those won't be affected by the > ABI change anyway as there the name doesn't propagate as it does with > modules..) > > > Thanks for investigating the test-suite failure. > > Tobias
