[gcc r15-844] VAX/doc: Fix issues with FP format option documentation

https://gcc.gnu.org/g:314448fc65f40c98ee8bc02dfb54ea49d2f2c60d commit r15-844-g314448fc65f40c98ee8bc02dfb54ea49d2f2c60d Author: Maciej W. Rozycki Date: Mon May 27 05:07:32 2024 +0100 VAX/doc: Fix issues with FP format option documentation Use the correct names of the D_floating

[gcc r15-843] vax: Fix descriptions of the FP format options [PR79646]

https://gcc.gnu.org/g:a7f6543f21303583356fd2d2d1805bffbecc1bc5 commit r15-843-ga7f6543f21303583356fd2d2d1805bffbecc1bc5 Author: Abe Skolnik Date: Mon May 27 05:07:32 2024 +0100 vax: Fix descriptions of the FP format options [PR79646] Replace "Target" with "Generate" consistently

Re: [PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Fri, 28 Aug 2020, Jakub Jelinek wrote: > > As far as `-fexceptions' and `-fasynchronous-unwind-tables' are concerned > > it aligns with my understanding, i.e. in this specific scenario we need > > `-fasynchronous-unwind-tables' for libcalls (all of them) so that an > >

[WIP][PATCH] RISC-V: Add `-mgprel' option for GP-relative addressing

Implement `-mgprel', forcing `-mexplicit-relocs' whenever the option is active due to the lack of GAS macro support for GP-relative addressing. gcc/ * riscv/riscv-protos.h (riscv_symbol_type): Add SYMBOL_GPREL enumeration constant. * config/riscv/riscv.c

[PATCH] RISC-V/libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

Use `-fasynchronous-unwind-tables' rather than `-fexceptions -fnon-call-exceptions' in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables for the affected functions while not pulling the unwinder proper, which is not required here. Beyond saving program space it fixes a RISC-V

Re: [PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Wed, 26 Aug 2020, Jakub Jelinek wrote: > On Wed, Aug 26, 2020 at 01:08:00PM +0200, Richard Biener via Gcc-patches > wrote: > > You only need -fexceptions for that, then you can throw; from a signal > > handler > > for example. If you want to be able to catch the exception somewhere up > >

Re: [PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

Hi Kito, > I just found the mail thread about div mod with -fnon-call-exceptions, > I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS unchanged > should be the best way to go. > > Non-call exceptions and libcalls > https://gcc.gnu.org/legacy-ml/gcc/2001-06/msg01108.html > > Non-call

Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Wed, 19 Aug 2020, Richard Earnshaw wrote: > > That said I'm of course happy to keep the ARM overrides if you consider > > them still necessary in the context of the generic change made. Let me > > know what you prefer, and if required, I will submit v3 with the ARM > > pieces removed.

[PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, , and replace `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables for

Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Tue, 18 Aug 2020, Richard Earnshaw wrote: > > Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, > > , and replace > > `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' > > in

[PING][PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Thu, 6 Aug 2020, Maciej W. Rozycki wrote: > Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, > , and replace > `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' > in LIB2_DIVMOD_FUNCS

[PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, , and replace `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables for

Re: [PATCH] RISC-V/libgcc: Reduce the size of RV64 millicode by 6 bytes

On Thu, 30 Jul 2020, Andrew Waterman wrote: > IIRC, I didn't use this approach originally because I wanted to avoid > the additional dynamic instruction. But I agree that code size is the > more important metric for users of this feature. LGTM. Applied now, thanks for your review. Maciej

[PATCH] RISC-V/libgcc: Reduce the size of RV64 millicode by 6 bytes

Rewrite code sequences throughout the 64-bit RISC-V `__riscv_save_*' routines replacing `li t1, -48', `li t1, -64', and `li t1, -80', instructions, which do not have a compressed encoding, respectively with `li t1, 3', `li t1, 4', and `li t1, 4', which do, and then adjusting the remaining code

[PATCH] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, , and replace `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables for

Re: RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0'

On Tue, 14 Jul 2020, Richard Biener wrote: > > > Arguably this might probably be called a deficiency in libgcc, however > > > the objects are built with `-fexceptions -fnon-call-exceptions' > > > > I consider that broken. It doesn't make any sense to build a lowlevel > > runtime library like

RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' (was: Re: [PATCH] Allow memset local PLT reference for RISC-V.)

On Sun, 12 Jul 2020, Maciej W. Rozycki wrote: > I don't think we have a way to redirect the reference to `__GI_memset'. Additionally, I need to mention that where `libgcc.a' has been built at `-O0', RV32 `ld.so' fails linking due to unresolved `malloc' and `free' references from numerous

Re: dejagnu version update? [CORRECTION: not a regression in DejaGnu; GDB testsuite bug]

[cc-ing Joel as the originator, and ] On Tue, 9 Jun 2020, Jacob Bachmeyer wrote: > >> I ran a quick bisection and the culprit turned out to be: > >> > >> ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit > >> commit ba60272a5ac6f6a7012acca03f596a6ed003f044 > >> Author: Jacob

Re: dejagnu version update?

On Tue, 26 May 2020, Rob Savoye wrote: > > I'll run some RISC-V remote GCC/GDB testing and compare results for > > DejaGnu 1.6/1.6.1 vs trunk. It will take several days though, as it takes > > many hours to go through these testsuite runs. > > That'd be great. I'd rather push out a stable

Re: dejagnu version update?

On Tue, 26 May 2020, Rob Savoye wrote: > I processed the patch backlog for DejaGnu, and have gone through the > bug list. It'd be nice if somebody could try master with a more complex > environment, etc... if I'm going to push out a release. For cross > testing all I have is a PI and QEMU.

Re: dejagnu version update?

On Sat, 16 May 2020, Rob Savoye wrote: > > Overall perhaps a patch management system might be good having to make > > chasing patches easier, such as patchwork, and we already use Git, so we > > As an old GNU project, we're required to use what the FSF prefers, > which is on savannah.

Re: dejagnu version update?

On Thu, 14 May 2020, Rob Savoye wrote: > Right now working through patches is probably more important. :-) > There's zero patches on the DejaGnu savannah site, so I'd ask anybody to > submit them so I don't have to dig them out of email archives. I have reposted the single patch I have had

Re: dejagnu version update?

On Thu, 14 May 2020, Rob Savoye wrote: > Personally, I tried to find funding to refactor DejaGnu in Python, > since Tcl is unmaintained too, but nobody was interested. Thank you for your contribution to DejaGnu over the years and for your input on this occasion. However it does not appear

Re: dejagnu version update?

Hi Rainer, > > Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this > > very week I have been chasing a phenomenon with Expect's `wait' semantics > > causing a reliable hang in remote testing if `ssh' to the target board > > stops responding for whatever reason. I have come

Re: dejagnu version update?

On Wed, 13 May 2020, Rainer Orth wrote: > > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me. > > If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and > 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang > indefinitely until one manually

Re: [PATCH v5 GCC] libffi/test: Fix compilation for build sysroot

On Wed, 22 Apr 2020, Jeff Law wrote: > > libffi/ > > * Makefile.am (DISTCLEANFILES): New variable. > > * configure.ac: Produce `local.exp'. > > * Makefile.in: Regenerate. > > * configure: Regenerate. > > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New > >

[PATCH v5 GCC] libffi/test: Fix compilation for build sysroot

Fix a problem with the libffi testsuite using a method to determine the compiler to use resulting in the tool being different from one the library has been built with, and causing a catastrophic failure from the inability to actually choose any compiler at all in a cross-compilation

Re: [PATCH] Do not use HAVE_DOS_BASED_FILE_SYSTEM for Cygwin.

On Thu, 16 Apr 2020, Martin Li?ka wrote: > The patch is fix for Cygwin where we should not define > HAVE_DOS_BASED_FILE_SYSTEM > and use back slashes as a path component separator. [...] > diff --git a/ltmain.sh b/ltmain.sh > index 79f9ba89af5..8ad183010f0 100644 > --- a/ltmain.sh > +++

Re: Help, Where I can find proper libtool version?

On Wed, 15 Apr 2020, 易会战 via Gcc wrote: > I am trying to add a library into gcc source code tree. The gcc source > have used libtool 2.2.7a 1.1334. but I cannot find the version. It is "libtool (GNU libtool 1.3134 2009-11-30) 2.2.7a" AFAICT, that is 1.3134 rather than 1.1334. I take it there

Re: Not usable email content encoding

On Tue, 14 Apr 2020, Christopher Faylor wrote: > >I think that means that dmarc_moderation_action: "Munge From" can > >simply be switched off then (at least I don't see which other headers > >e.g. gcc@ is rewriting that would cause DMARC to scream; and if there > >are any, then it would be

Re: [PING][PATCH][wwwdocs] GCC 10: Document RISC-V target's requirement for binutils 2.30

On Thu, 9 Apr 2020, Jeff Law wrote: > > > Match GCC commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather > > > than fmv.x.s/fmv.s.x") and commit 879bc686a0aa ("doc: RISC-V: Update > > > binutils requirement to 2.30"). > > > > Ping for: > > > >

[PING][PATCH][wwwdocs] GCC 10: Document RISC-V target's requirement for binutils 2.30

On Thu, 2 Apr 2020, Maciej W. Rozycki wrote: > Match GCC commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather > than fmv.x.s/fmv.s.x") and commit 879bc686a0aa ("doc: RISC-V: Update > binutils requirement to 2.30"). Ping for:

Re: Not usable email content encoding

On Tue, 7 Apr 2020, Christopher Faylor wrote: > >In a way that's amusing and just reinforces my p.o.v. that DMARC is > >bollocks. > > Not that it means anything but I agree 100%. > > It's like whoever made the "standard" just said "to hell with mailing > lists". Maybe they just didn't know

Re: Not usable email content encoding

On Tue, 7 Apr 2020, Christopher Faylor wrote: > >Can we please switch it off? It's not like we really had a problem before > >the switch to mailman. > > You can't really make statements like this which imply that you are > aware of "problems" on sourceware when you're not a sourceware >

Re: [PATCH v4 1/5] libatomic/test: Fix compilation for build sysroot

On Mon, 6 Apr 2020, Jeff Law wrote: > > libatomic/ > > * configure.ac: Add testsuite/libatomic-site-extra.exp to output > > files. > > * configure: Regenerate. > > * libatomic/testsuite/libatomic-site-extra.exp.in: New file. > > * testsuite/Makefile.am

Re: [PATCH v4 5/5] libgomp/test: Remove a build sysroot fix regression

On Mon, 6 Apr 2020, Jeff Law wrote: > > libgomp/ > > * configure.ac: Add testsuite/libgomp-site-extra.exp to output > > files. > > * configure: Regenerate. > > * testsuite/libgomp-site-extra.exp.in: New file. > > * testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST):

Re: Not usable email content encoding

Hi Frank, > > I am fairly sure it breaks `git am' too, requiring a `From' override in > > the change description for author attribution in patch application to work > > reliably (I tend to work on my outbox when applying my own patches, so I > > avoid this issue, but I am sure the issue will

Re: Not usable email content encoding

On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > Out of curiousity, is this rewriting you are talking about the cause for a > > lot of mails showing up as "From: GCC List" rather than their real senders? > > This has become very annoying recently. > > Yes, for emails from domains with

Re: [PATCH v4 GCC 2/5] libffi/test: Fix compilation for build sysroot

On Mon, 6 Apr 2020, Jeff Law wrote: > > libffi/ > > * configure.ac: Add testsuite/local.exp to output files. > > * configure: Regenerate. > > * testsuite/local.exp.in: New file. > > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New > > variable. > > *

[PATCH v4 5/5] libgomp/test: Remove a build sysroot fix regression

Fix a problem with commit c8e759b4215b ("libgomp/test: Fix compilation for build sysroot") that caused a regression in some standalone test environments where testsuite/libgomp-test-support.exp is used, but the compiler is expected to be determined by `[find_gcc]', and set the GCC_UNDER_TEST

[PATCH v4 GCC 3/5] libffi/test: Make `libffi-init' use $CC_FOR_TARGET

Update code in `libffi-init' to use $CC_FOR_TARGET in determining the value of $ld_library_path, as using a different compiler location from one actually used in testing may have odd consequences. As this obviously loses the setting of $gccdir provide a replacement way to determine the

[PATCH v4 4/5] libgo/test: Complement compilation fix for build sysroot

Complement commit b72813a68c94 ("libgo: fix DejaGNU testsuite compiler when using build sysroot") and move testsuite/libgo-test-support.exp.in to testsuite/libgo-site-extra.exp.in. Update testsuite/lib/libgo.exp to handle the `--tool_exec' option to `runtest' as with other top-level GCC

[PATCH v4 GCC 2/5] libffi/test: Fix compilation for build sysroot

Fix a problem with the libffi testsuite using a method to determine the compiler to use resulting in the tool being different from one the library has been built with, and causing a catastrophic failure from the inability to actually choose any compiler at all in a cross-compilation

[PATCH v4 1/5] libatomic/test: Fix compilation for build sysroot

Fix a problem with the libatomic testsuite using a method to determine the compiler to use resulting in the tool being different from one the library has been built with, and causing a catastrophic failure from the lack of a suitable `--sysroot=' option where the `--with-build-sysroot='

[PATCH v4 0/5] Fix library testsuite compilation for build sysroot

Hi, This is v4 of patch series, originally posted here: v2

[PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET

Update code in `libffi-init' to use $CC_FOR_TARGET in determining the value of $ld_library_path, as using a different compiler location from one actually used in testing may have odd consequences. As this obviously loses the setting of $gccdir provide a replacement way to determine the

[PATCH libffi 4/4] Correct indentation throughout `libffi-init'

--- testsuite/lib/libffi.exp |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) libffi-init-whitespace.diff Index: libffi/testsuite/lib/libffi.exp === --- libffi.orig/testsuite/lib/libffi.exp +++

[PATCH libffi 2/4] Use a documented way to pass $compiler_vendor to DejaGNU

Use Autoconf substitution in the template used for extra DejaGNU site configuration, which is a documented supported way to pass information from the `configure' script, rather than resorting to a hack with extracting an undocumented internal setting from `config.log' to pass the compiler

[PATCH libffi 1/4] Use a template to pass $CC and $CXX to DejaGNU

Use an Autoconf template rather an inline piece of scriptery to set DejaGNU's $CC_FOR_TARGET and $CXX_FOR_TARGET variables from $CC and $CXX respectively, making it easier to maintain and making it take advantage of Automake's dependency and rule generation. Relocate the generated `local.exp'

[PATCH libffi 0/4] Robustify compiler and library path selection in the testsuite

Hi, In the course of a discussion at one of the GCC mailing lists here: I have realised that some parts related to libffi testing have not been merged to GCC, and they are needed to choose the right compiler in a

Re: [PATCH] doc: RISC-V: Update binutils requirement to 2.30

On Thu, 2 Apr 2020, Maciej W. Rozycki wrote: > > OK. Can you also update gcc-10/changes.html? > > Change now applied, thank you for your review, and patch posted for > wwwdocs [I meant to give a link to the message in the archive here, but it > seems behind by ~2.5 hours; something to look

Re: [PATCH] doc: RISC-V: Update binutils requirement to 2.30

On Thu, 2 Apr 2020, Richard Biener wrote: > > > Our installation instructions state binutils 2.28 as the requirement for > > > all the RISC-V targets, however the change for fmv.x.w/fmv.w.x instruction > > > support was only added in the binutils 2.30 development cycle. > > > > Here's the

[PATCH][wwwdocs] GCC 10: Document RISC-V target's requirement for binutils 2.30

Match GCC commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x") and commit 879bc686a0aa ("doc: RISC-V: Update binutils requirement to 2.30"). --- Hi, OK to apply? Maciej --- htdocs/gcc-10/changes.html | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-)

[committed][wwwdocs] GCC 10: Reorder S/390 target alphabetically

--- Hi, Committed as obvious. Maciej --- htdocs/gcc-10/changes.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index 1e1eaf43..3d8e0ba9 100644 --- a/htdocs/gcc-10/changes.html +++

[PATCH] doc: RISC-V: Update binutils requirement to 2.30

Complement commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x") and document a binutils 2.30 requirement in the installation manual, matching the addition of fmv.x.w/fmv.w.x mnemonics to GAS. gcc/ * doc/install.texi (Specific) : Update

Re: [PATCH v3 4/4] libgomp/test: Remove a build sysroot fix regression

On Thu, 26 Mar 2020, Chung-Lin Tang wrote: > > Changes from v2: > > > > - Do not use `--tool_exec' with AM_RUNTESTFLAGS. > > > > - Move the definition of GCC_UNDER_TEST from > >testsuite/libgomp-test-support.exp to > >testsuite/libgomp-site-extra.exp. > > Hi Maciej, > sorry, I didn't

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

On Mon, 30 Mar 2020, Mike Stump wrote: > > I have actually considered extracting the bits already, but I hesitated > > putting that forward that as having looked at the part that we require I > > have thought it to be very messy: > > Yeah, sometimes it's like that. I glanced at the work, if

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

On Tue, 24 Mar 2020, Mike Stump wrote: > > Have we made any conclusions WRT the way to move forward with this stuff? > > Things remain broken and I'd prefer to get the issues off the plate while > > the stuff is hot, or at least mildly warm. I'm about to get distracted > > with other work. >

Re: [PATCH] RISC-V: Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x

On Wed, 18 Mar 2020, Jim Wilson wrote: > > The new mnemonics have been supported by GAS for a little while now and > > the old ones have been retained, however this is still a change that > > breaks backwards compatibility. So I wonder if we shouldn't have an > > autoconf test included for this

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

On Fri, 28 Feb 2020, H.J. Lu wrote: > > > > However that hack has been actually made to address this very problem > > > > discussed with this submission, so why not simply sync our copy of > > > > libffi > > > > with the upstream version? Then we can decide if changing the hack into > > > >

Re: [PATCH] RISC-V: Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x

On Tue, 18 Feb 2020, Kito Cheng wrote: > - fmv.x.s/fmv.s.x renamed to fmv.x.w/fmv.w.x in the latest RISC-V ISA >manual. The new mnemonics have been supported by GAS for a little while now and the old ones have been retained, however this is still a change that breaks backwards