Re: FW: [PATCH] [MIPS] microMIPS gcc support
"Maciej W. Rozycki" writes:
> On Wed, 23 Jan 2013, Richard Sandiford wrote:
>> > Index: config/mips/gnu-user.h
>> > ===
>> > --- config/mips/gnu-user.h (revision 195351)
>> > +++ config/mips/gnu-user.h (working copy)
>> > @@ -137,3 +137,12 @@ extern const char *host_detect_local_cpu (int argc
>> > #define ENDFILE_SPEC \
>> >GNU_USER_TARGET_MATHFILE_SPEC " " \
>> >GNU_USER_TARGET_ENDFILE_SPEC
>> > +
>> > +#undef SUBTARGET_OVERRIDE_OPTIONS
>> > +#define SUBTARGET_OVERRIDE_OPTIONS \
>> > +do {\
>> > + /* microMIPS PLT entries are non-microMIPS. */ \
>> > + TARGET_INTERLINK_COMPRESSED = 1; \
>> > +} while (0)
>> > +
>> > +
>>
>> Hmm, that sounds like a reason to set TARGET_INTERLINK_UNCOMPRESSED
>> rather than TARGET_INTERLINK_COMPRESSED. I.e. we need to avoid direct
>> branches from microMIPS code to standard PLTs.
>>
>> But that means that microMIPS code can't even jump directly to functions
>> that have a micromips attribute when the call might go via a PLT.
>> TARGET_INTERLINK_(UN)COMPRESSED doesn't cover that case. I think instead
>> we need to handle it directly in mips_function_ok_for_sibcall,
>> keyed off TARGET_ABICALLS_PIC0. Specific suggestion below.
> [...]
>> >/* We can't do a sibcall if the called function is a MIPS16 function
>> > because there is no direct "jx" instruction equivalent to "jalx" to
>> > switch the ISA mode. We only care about cases where the sibling
>> > and normal calls would both be direct. */
>> >if (decl
>> > - && mips_use_mips16_mode_p (decl)
>> > + && ((compression_mode & (MASK_MIPS16 | MASK_MICROMIPS)) != 0)
>> >&& const_call_insn_operand (XEXP (DECL_RTL (decl), 0), VOIDmode))
>> > return false;
>> >
>> > - /* When -minterlink-mips16 is in effect, assume that non-locally-binding
>> > - functions could be MIPS16 ones unless an attribute explicitly tells
>> > + /* When -minterlink-compressed is in effect, assume that
>> > non-locally-binding
>> > + functions could be MIPS16 or microMIPS unless an attribute
>> > explicitly tells
>> > us otherwise. */
>> > - if (TARGET_INTERLINK_MIPS16
>> > + if (TARGET_INTERLINK_COMPRESSED
>> >&& decl
>> >&& (DECL_EXTERNAL (decl) || !targetm.binds_local_p (decl))
>> > - && !mips_nomips16_decl_p (decl)
>> > + && (compression_mode & MASK_MICROMIPS) == 0
>> > + && (compression_mode & MASK_MIPS16) == 0
>> >&& const_call_insn_operand (XEXP (DECL_RTL (decl), 0), VOIDmode))
>> > return false;
>>
>> should be something like:
>>
>> /* Direct Js are only possible to functions that use the same ISA encoding.
>> There is no JX counterpart of JALX. */
>> if (decl
>> && const_call_insn_operand (XEXP (DECL_RTL (decl), 0), VOIDmode)
>> && mips_call_may_need_jalx_p (decl))
>> return false;
>>
>> with:
>>
>> /* Return true if a call to DECL may need to use JALX. */
>>
>> static bool
>> mips_call_may_need_jalx_p (decl)
>> {
>> /* If the current translation unit would use a different mode for DECL,
>> assume that the call needs JALX. */
>> if (mips_get_compress_mode (decl) != TARGET_COMPRESSION)
>> return true;
>>
>> /* mips_get_compress_mode is always accurate for locally-binding
>> functions in the current translation unit. */
>> if (!DECL_EXTERNAL (decl) && targetm.binds_local_p (decl))
>> return false;
>>
>> /* PLTs use the standard encoding, so calls that might go via PLTs
>> must use JALX. */
>> if (TARGET_COMPRESSED
>> && TARGET_ABICALLS_PIC0
>> && DECL_EXTERNAL (decl)
>> && !targetm.binds_local_p (decl))
>> return true;
>>
>> /* When -minterlink-compressed is in effect, assume that functions
>> could use a different encoding mode unless an attribute explicitly
>> tells us otherwise. */
>> if (TARGET_INTERLINK_COMPRESSED)
>> {
>> if (!TARGET_COMPRESSION && mips_get_compress_off_flags (decl) == 0)
>> return true;
>> if (TARGET_COMPRESSION && mips_get_compress_on_flags (decl) == 0)
>> return true;
>> }
>>
>> return false;
>> }
>>
>> The TARGET_ABICALLS_PIC0 case should deal with the gnu-user.h comment above.
>
> How about instead of complicating this we simply add support for
> microMIPS encoding in the PLT? I think I should be able to squeeze out
> some time next week to dust off and retest the binutils patch I've had
> pending far too long now. This way we won't have to maintain separate
> cases where tail calls may or may not be made via the PLT.
>
> Note that we need that support sooner or later anyway due to the prospect
> of pure-microMIPS processors.
Just so I know: what does the PLT patch do for external functions
that are jumped to by both microMIPS and non-microMIP
Re: [Patch, microblaze]: Add microblaze*-*-elf target
On 01/24/2013 04:37 PM, David Holsgrove wrote: On 25 January 2013 01:38, Michael Eager wrote: On 01/23/2013 08:24 PM, David Holsgrove wrote: Hi Michael, On 24 January 2013 00:58, Michael Eager wrote: On 01/20/2013 09:42 PM, David Holsgrove wrote: gcc/Changelog 2013-01-21 Edgar E. Iglesias * config.gcc (microblaze*-*-elf): Add new target libgcc/Changelog 2013-01-21 Edgar E. Iglesias * config.host (microblaze*-*-elf): Add new target Hi David -- The generic microblaze*-*-* target is currently used for --target=microblaze-xilinx-elf. After adding a microblaze*-*-elf target, what targets would use generic target? If there are no known configurations which would match, there's little value in keeping a target which is never built. I don't have any objection to renaming the target from microblaze*-*-* to microblaze-*-*-elf. Hi Michael, I agree, our default target would be a microblaze*-*-elf, so I can rename the target to reflect this, and update the config.gcc / config.host. I've attached an updated version of the patch for your review. I'll also reply to my patch adding Little Endian support as this will be updated also. Modified Changelog: gcc: * config.gcc (microblaze*-*-*): Rename microblaze*-*-elf, update tm_file. libgcc: * config.host (microblaze*-*-*): Rename microblaze*-*-elf, update extra_parts. Committed revision 195487. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: PR54662 - microblaze-linux target makefile
On 01/23/2013 01:13 PM, David Holsgrove wrote: Hi Michael, On 24 January 2013 01:07, Michael Eager wrote: On 01/20/2013 09:46 PM, David Holsgrove wrote: gcc/Changelog 2013-01-21 David Holsgrove * config.gcc (microblaze*-linux*): Add tmake_file to allow building of microblaze-c.o libgcc/Changelog 2013-01-21 David Holsgrove * libgcc/config/microblaze/t-microblaze: Set LIB2FUNCS_EXCLUDE to exclude functions from being built with libgcc.c and use the microblaze assembly. Hi David -- The patch is OK, but I'm confused about the PR mentioned. GCC PR54662 doesn't seem to be related. Apologies - thats a typo, the PR I meant to reference was PR54663. Committed revision 195488. Modified ChangeLog: gcc: PR target/54663 * config.gcc (microblaze*-linux*): Add tmake_file to allow building of microblaze-c.o libgcc: * config.host(microblaze*-linux*): tmake_file: Remove t-slibgcc-nolc-override, add t-slibgcc-libgcc. * config/microblaze/t-microblaze: Set LIB2FUNCS_EXCLUDE to exclude functions from being built with libgcc.c and use the microblaze assembly. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PING^2] Re: [PATCH 1/2] Document HLE / RTM intrinsics
Andi Kleen writes: PING^2!! > Andi Kleen writes: > >> From: Andi Kleen >> >> The TSX HLE/RTM intrinsics were missing documentation. Add this to the >> manual. >> >> Ok for release / trunk? > > Could someone please review/approve this (documentation only) patch? > Thanks. > > -Andi > >> 2013-01-11 Andi Kleen >> >> * doc/extend.texi: Document __ATOMIC_HLE_ACQUIRE, >> __ATOMIC_HLE_RELEASE. Document __builtin_ia32 TSX intrincs. >> Document _x* TSX intrinsics. -- a...@linux.intel.com -- Speaking for myself only
Re: [Patch, fortran] PR55984 [4.8 Regression] [OOP] ICE: gfc_trans_code(): Bad statement code & PR56047 [4.8 Regression]
Hi Paul, > This patch builds on Janus's suggestion in the PR. The ChangeLog > explains it all. > > Bootstrapped and regtested on x86_64/FC17 - OK for trunk? looks good to me. Thanks a bunch! Cheers, Janus > 2013-01-26 Paul Thomas > > PR fortran/55789 > PR fortran/56047 > * gfortran.h : Add associate_var to symbol_attr. > * resolve.c (resolve_assoc_var): Set associate_var attribute. > If the target class_ok is set, set it for the associate > variable. > * check.c (allocatable_check): Associate variables should not > have the allocatable attribute even if their symbols do. > * class.c (gfc_build_class_symbol): Symbols with associate_var > set will always have a good class container. > > 2013-01-26 Paul Thomas > > PR fortran/55789 > * gfortran.dg/associate_14.f90: New test. > > PR fortran/56047 > * gfortran.dg/associate_13.f90: New test.
Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On Fri, Jan 25, 2013 at 8:55 AM, Michael Haubenwallner
wrote:
> Same here, building everything out-of-source. The prerequisites used are:
> * CONFIG_SHELL=/usr/local/bin/bash 4.1.7 from bullfreeware (symlinks to
> /opt/freeware/bin/)
> * /usr/bin/{gcc,g++} 4.6.1 from bullfreeware (symlinks to /opt/freeware/bin/)
> * /usr/bin/gmake 3.82 from bullfreeware (symlinks to /opt/freeware/bin/)
> * gmp-5.0.4: as shared library, configured with --prefix=/prereq ABI=32
> * mpfr-3.1.1: as shared library, configured with --prefix=/prereq
> --with-gmp=/prereq
> * mpfr-3.1.1: as shared library, configured with --prefix=/prereq
> --with-{gmp,mpfr}=/prereq
> * gawk-3.1.7, flex-2.5.35, m4-1.4.13 from some Gentoo Prefix instance,
> nowhere in PATH,
> thus: export {AWK,FLEX}=/gentoo/prefix/usr/bin/{awk,flex} and this patch:
> http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00960.html
>
> For gcc:
> * $CONFIG_SHELL configure --prefix=/does/not/exist/yet
> --with-{gmp,mpfr,mpc}=/prereq \
> --enable--languages=c,c++ --disable-werror --disable-nls
> * gmake bootstrap
I committed your patch.
By the way, NLS works if you build and install GNU libiconv (1.14) and
add --with-libiconv-prefix=/prereq to force GCC bootstrap to use GNU
libiconv instead of AIX libiconv.
Thanks, David
Re: [PATCH 1/2] [pr53679] libgo: add a --enable-werror configure flag
On Fri, Jan 25, 2013 at 7:20 PM, Mike Frysinger wrote: > On Friday 25 January 2013 19:13:55 Ian Lance Taylor wrote: >> On Tue, Jan 15, 2013 at 9:45 AM, Mike Frysinger wrote: >> > On Tuesday 15 January 2013 09:56:06 Ian Lance Taylor wrote: >> >> On Sun, Dec 23, 2012 at 3:30 PM, Mike Frysinger wrote: >> >> > diff --git a/libgo/configure.ac b/libgo/configure.ac >> >> > index 8cde50b..63d8cbc 100644 >> >> > --- a/libgo/configure.ac >> >> > +++ b/libgo/configure.ac >> >> > @@ -50,8 +50,11 @@ AC_PROG_AWK >> >> > >> >> > WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual' >> >> > AC_SUBST(WARN_FLAGS) >> >> > >> >> > -dnl FIXME: This should be controlled by --enable-maintainer-mode. >> >> > -WERROR="-Werror" >> >> > +AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror], >> >> > + [turns on -Werror >> >> > @<:@default=yes@:>@])]) +if test "x$enable_werror" != "xno"; then >> >> > + WERROR="-Werror" >> >> > +fi >> >> > >> >> > AC_SUBST(WERROR) >> >> > >> >> > glibgo_toolexecdir=no >> >> >> >> Can you say something about when you needed this? What errors were you >> >> seeing? >> > >> > the referenced PR describes one: >> > /build/src/gcc-4.7.1/libgo/runtime/print.c: In function 'gwrite': >> > /build/src/gcc-4.7.1/libgo/runtime/print.c:20:3: error: ignoring return >> > value of 'write', declared with attribute warn_unused_result >> > [-Werror=unused-result] cc1: all warnings being treated as errors >> > >> > this bites distros that enable security settings by default (such as >> > fortify and ssp). but ignoring even that, i don't believe releases >> > should build all the time with -Werror -- i'm fine with defaulting to on >> > as long as there is a configure flag to turn it off which is what this >> > does like is already handled in much of the sourceware tree. -Werror is >> > great for development, but sucks when deployed on actual systems. the >> > assumptions made at time of checkin rarely stay constant forever (in >> > this case, a changing lib C can easily break it). -mike >> >> Thanks for the explanation. >> >> Committed to mainline. > > thanks! mind if i commit it to gcc-4.6 and gcc-4.7 too ? I certainly don't mind. You should probably get agreement from the release managers although this seems safe enough. Ian
Re: [Patch, fortran] PR55984 [4.8 Regression] [OOP] ICE: gfc_trans_code(): Bad statement code & PR56047 [4.8 Regression]
Thanks, Janus. Committed as revision 195492. Cheers Paul On 27 January 2013 00:15, Janus Weil wrote: > Hi Paul, > >> This patch builds on Janus's suggestion in the PR. The ChangeLog >> explains it all. >> >> Bootstrapped and regtested on x86_64/FC17 - OK for trunk? > > looks good to me. Thanks a bunch! > > Cheers, > Janus > > > >> 2013-01-26 Paul Thomas >> >> PR fortran/55789 >> PR fortran/56047 >> * gfortran.h : Add associate_var to symbol_attr. >> * resolve.c (resolve_assoc_var): Set associate_var attribute. >> If the target class_ok is set, set it for the associate >> variable. >> * check.c (allocatable_check): Associate variables should not >> have the allocatable attribute even if their symbols do. >> * class.c (gfc_build_class_symbol): Symbols with associate_var >> set will always have a good class container. >> >> 2013-01-26 Paul Thomas >> >> PR fortran/55789 >> * gfortran.dg/associate_14.f90: New test. >> >> PR fortran/56047 >> * gfortran.dg/associate_13.f90: New test.
