[PATCH] PR libstdc++/59392: Fix ARM EABI uncaught throw from unexpected exception handler

vered by Google's blanket copyright assignment.) No regressions in 'make check-c++' on arm-linux-gnueabihf. Ok for trunk and 4.8? Thanks, Roland libstdc++-v3/ 2013-12-06 Roland McGrath Mark Seaborn PR libstdc++/59392 * libsupc++/eh_call.cc (__cx

[PATCH PR 63758] fix liblto_plugin.so undefined _environ reference on OSX host

x27;t know why. But it's documented in OSX's environ(7) man page that shared libraries cannot refer to environ directly. This patch fixed it for me. It's not very autoconfy, but it's simple and it works. OK for trunk and 4.9 branch? Thanks, Roland libiberty/ 2

[PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

This fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 (which I've just filed). OK for trunk? I'm not sure if this kind of fix is appropriate for gcc-6-branch or not, but I'd like to backport it there too if it is acceptable. Thanks, Roland gcc/ 2016-09-15

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

ping? On Thu, Sep 15, 2016 at 4:09 PM, Roland McGrath wrote: > This fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 (which I've > just filed). > > OK for trunk? > > I'm not sure if this kind of fix is appropriate for gcc-6-branch or not, > but I'd li

[COMMITTED PATCH] add myself to write after approval list

2012-11-15 Roland McGrath * MAINTAINERS (Write After Approval): Add myself. --- a/MAINTAINERS +++ b/MAINTAINERS @@ -457,6 +457,7 @@ Simon Martin simar...@users.sourceforge.net Ranjit Mathew rmat...@hotmail.com

[PATCH] Fix -Wformat-security warning in arm.c

This fixes a gratuitous warning. Thanks, Roland gcc/ 2013-03-25 Roland McGrath * config/arm/arm.c (arm_print_operand: case 'w'): Use fputs rather than fprintf with a non-constant, non-format string. --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -17997,

Re: [PATCH] Fix -Wformat-security warning in arm.c

Committed to trunk. Thanks, Roland

Re: [PATCH] Fix -Wformat-security warning in arm.c

Backport committed to gcc-4_8-branch.

[PATCH] x86: Use ud2 assembly mnemonic when available.

Non-ancient assemblers support the "ud2" mnemonic, so there is no need to emit the literal opcode as data. OK for trunk and 4.8? Thanks, Roland gcc/ 2014-02-13 Roland McGrath * configure.ac (HAVE_AS_IX86_UD2): New test for 'ud2' mnemonic. * co

Re: [PATCH] x86: Use ud2 assembly mnemonic when available.

Did you read the patch? It uses an empirical configure check to discover if the assembler does in fact support ud2.

Re: [PATCH] x86: Use ud2 assembly mnemonic when available.

On Thu, Feb 13, 2014 at 10:58 PM, Uros Bizjak wrote: > You forgot to tell us how the patch tested... Right. It's a pretty obviously harmless change. I tested that the configure check passes with binutils-2.22, and eyeball'd a -S compile of a trivial function calling __builtin_trap() to see it u

Re: [PATCH] PR libstdc++/59392: Fix ARM EABI uncaught throw from unexpected exception handler

Committed (r208519 on trunk and r208520 on 4.8) after approval posted in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392. Only the dates are changed from what I posted originally. Thanks, Roland On Fri, Dec 6, 2013 at 3:24 PM, Roland McGrath wrote: > [This patch is on the git-only bra

[PATCH] libiberty: fix psignal parameter type

le functions changes over time. I think the fragility of that hard-coding ought to be addressed somehow. But regardless, this change alleviates the immediate problem, and is otherwise harmless. Thanks, Roland libiberty/ 2011-10-18 Roland McGrath * strsignal.c (psignal): Use const

Re: [PATCH] libiberty: fix psignal parameter type

On Tue, Oct 18, 2011 at 9:50 AM, Andrew Pinski wrote: > libiberty is no longer compiled for the target so this should never > happen really. I see. I was indeed using an older source base, and just noticed that all the offending configure logic was still the same. Perhaps all the --with-newlib

Re: [PATCH] libiberty: fix psignal parameter type

On Tue, Oct 18, 2011 at 10:18 AM, Ian Lance Taylor wrote: > On Tue, Oct 18, 2011 at 9:49 AM, Roland McGrath wrote: >> >> libiberty/ >> 2011-10-18  Roland McGrath   >> >>        * strsignal.c (psignal): Use const second in parameter type. >>        *

[top-level patch] Do proper target tool checks for readelf

n merged over to src/, and instances where changes were committed directly to src/. I'm able to commit (after approval) to src/ CVS, but not to GCC. Ok for src/ trunk, or should somebody be putting this into GCC first? I've omitted the generated files from the patch, but of course would in

Re: [top-level patch] Do proper target tool checks for readelf

On Wed, Nov 2, 2011 at 8:32 PM, Ian Lance Taylor wrote: > The top level is not automatically merged between gcc and src.  However, > people are expected to merge manually.  Normally gcc is considered to be > the master. Ok. src/MAINTAINERS could be clearer about that. >> Ok for src/ trunk, or s

Re: [top-level patch] Do proper target tool checks for readelf

On Thu, Nov 3, 2011 at 10:39 AM, Ian Lance Taylor wrote: > Ideally I'd like to see a build maintainer approve it.  Perhaps I missed > that. Ah. The src/MAINTAINERS file says, "Any global maintainer can approve changes to these files, ...", which in that context I think includes you. But since ".

Re: [top-level patch] Do proper target tool checks for readelf

On Thu, Nov 3, 2011 at 10:55 AM, DJ Delorie wrote: > The patch looks OK to me. Thanks! As I'm still not a GCC committer, someone please check it in for me. If people would like me to handle the merge over to src/ myself, I'd be glad to do that step. Thanks, Roland

Re: [top-level patch] Do proper target tool checks for readelf

On Thu, Nov 3, 2011 at 11:05 AM, Roland McGrath wrote: > On Thu, Nov 3, 2011 at 10:55 AM, DJ Delorie wrote: >> The patch looks OK to me. > > Thanks!  As I'm still not a GCC committer, someone please check it in for me. > If people would like me to handle the merge over

Re: [PATCH] Fix ARM constant-pool layout calculations under -falign-labels

haven't actually > tried to get to reproduce on any vanilla ARM target. But the logic of the > change seems straightforward and sound. gcc/ 2012-08-22 Roland McGrath * config/arm/arm.c (get_label_padding): Use align_labels as minimum. diff --git a/gcc/config/arm/arm

[PATCH] ARM: exclude fixed_regs for stack-alignment save/restore

inux-gnueabi/include/ but configuring with --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include did not succeed in building libgcc.) But the change seems pretty obviously correct IMHO. Thanks, Roland gcc/ 2012-06-14 Roland McGrath * config/arm/arm.c (arm_get_frame_of

Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore

On Thu, Jun 14, 2012 at 1:13 PM, Mike Stump wrote: > On Jun 14, 2012, at 10:16 AM, Roland McGrath wrote: >> But if e.g. I use -ffixed-r9 then I think it's a reasonable expectation >> that no code is generated that touches r9 in any way, shape, or form. > > Also,

Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore

Here's the version of the change that incorporates Mike's suggestion. Thanks, Roland gcc/ 2012-06-14 Roland McGrath * config/arm/arm.c (arm_get_frame_offsets): Never use a fixed register as the extra register to save/restore for stack-alignment padding. diff -

Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore

OK then. If you like the original patch, would you like to commit it for me? Thanks, Roland

Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore

On Mon, Jun 18, 2012 at 9:34 AM, Roland McGrath wrote: > OK then.  If you like the original patch, would you like to commit it for me? ping?

[PATCH] x86: use 'rep bsf' syntax when assembler supports it

embler accepts the latter. Thanks, Roland gcc/ 2012-06-22 Roland McGrath * configure.ac (HAVE_AS_IX86_REP_BSFBSR): New test. * configure: Regenerate. * config.in: Regenerate. * config/i386/i386.h (REP_BEFORE_BSF): New macro. * config/i386/i386.md (ctz

Re: [PATCH] x86: use 'rep bsf' syntax when assembler supports it

On Fri, Jun 22, 2012 at 11:57 AM, Uros Bizjak wrote: > Please do not introduce new macro, just use #ifdef > HAVE_AS_IX86_REP_BSFBSR directly in i386.md. Would you want the same #ifdef in two places if I extend this to handle 'rep ret' too, or would a macro then be preferable? To me, the macro is

Re: [off list] Re: [PATCH] x86: use 'rep bsf' syntax when assembler supports it

trunk within the last five minutes or so to have an assembler that passes the test now. Thanks, Roland gcc/ 2012-06-22 Roland McGrath * configure.ac (HAVE_AS_IX86_REP_LOCK_PREFIX): Also require that the assembler accept 'rep bsf ...', 'rep bsr ...

Re: [off list] Re: [PATCH] x86: use 'rep bsf' syntax when assembler supports it

wered to do it myself. Thanks, Roland gcc/ 2012-07-02 Roland McGrath * configure.ac (HAVE_AS_IX86_REP_LOCK_PREFIX): Also require that the assembler accept 'rep bsf ...', 'rep bsr ...', 'rep ret', and 'rep nop'.

Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore

Richard, here is the patch against the current trunk, as I promised last week in Prague. Please apply. Thanks, Roland gcc/ 2012-07-17 Roland McGrath * config/arm/arm.c (arm_get_frame_offsets): Never use a fixed register as the extra register to save/restore for stack

Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore

ping?

Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore

Thanks muchly!

[PATCH] Fix ARM constant-pool layout calculations under -falign-labels

uce on any vanilla ARM target. But the logic of the change seems straightforward and sound. Thanks, Roland 2012-08-01 Roland McGrath * config/arm/arm.c (get_label_padding): Use align_labels as minimum. diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index 701ab4c..9bdb

Re: [PATCH] Fix ARM constant-pool layout calculations under -falign-labels

On Thu, Aug 2, 2012 at 1:57 AM, Julian Brown wrote: > FWIW, I've hit this issue in the past, and used a patch as follows to > fix it: > > @@ -12015,7 +12025,10 @@ create_fix_barrier (Mfix *fix, HOST_WIDE >gcc_assert (GET_CODE (from) != BARRIER); > >/* Count the length of this insn.

[PATCH] don't presume undelegitimized UNSPEC_TLS SYMBOL_REF is a decl

I am not a GCC committer, so if you like the change, please commit it for me.) Thanks, Roland 2012-06-06 Roland McGrath * dwarf2out.c (const_ok_for_output_1): Detect a TLS UNSPEC using SYMBOL_REF_TLS_MODEL rather than DECL_THREAD_LOCAL_P, in case it's not a VAR_DE

[PATCH] libgcc: If __GLIBC__ is defined, don't refer to pthread_cancel.

-0ubuntu7.10). Thanks, Roland libgcc/ 2012-06-08 Roland McGrath * gthr-posix.h [neither FreeBSD nor Solaris] (__gthread_active_p): If __GLIBC__ is defined, refer to __pthread_key_create instead of pthread_cancel. diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h

Re: [PATCH] don't presume undelegitimized UNSPEC_TLS SYMBOL_REF is a decl

ping? On Wed, Jun 6, 2012 at 2:04 PM, Roland McGrath wrote: > cf this change: > >        2010-11-19  Jakub Jelinek   > >                PR target/45870 >                * dwarf2out.c (const_ok_for_output_1): Don't complain about >                non-delegitimized TLS

Re: [PATCH] don't presume undelegitimized UNSPEC_TLS SYMBOL_REF is a decl

On Mon, Jun 11, 2012 at 1:42 PM, Richard Henderson wrote: > Applied. Thanks!

Re: [PATCH] libgcc: If __GLIBC__ is defined, don't refer to pthread_cancel.

On Mon, Jun 11, 2012 at 2:16 PM, Richard Henderson wrote: > Applied. Thanks!

[PATCH] libgcc: refer to pthread_create, not pthread_cancel

s directly at all or don't have any idea what pthread_cancel is. What do folks think about this change? It obviously should have no effect whatsoever on builds not using glibc. I'm pretty confident that it won't have any bad effect on a build using any extant version of glibc tha

Re: [PATCH] libgcc: refer to pthread_create, not pthread_cancel

I see. There certainly should have been a comment in the code about why pthread_cancel was chosen. I still think it's a particularly poor choice. For glibc, I think pthread_getspecific or pthread_key_create are better choices. Those are much smaller functions that don't bring very much dead cod

Re: [RFC PATCH] Typed DWARF stack

It's been a while since I read Cary's proposal, and I am no longer likely to do much work of my own in this area. So I'll just respond at the high level. I like very much the essential notion of the stack being of typed entities with no specification of how the consumer actually implements it. I

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

A direct cherry-pick of the trunk change (db7548a2771bbf34cf7430712af7ac670b429958 / r259969) applies fine to today's 8 branch and has no check-gcc regressions on x86_64-linux-gnu. OK to commit to 8 branch now? Thanks, Roland

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

Committed. Thanks, Roland

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

Anybody want to look at this? It rebases identically on today's trunk. I'd like to commit it to trunk and gcc-7-branch and gcc-6-branch ideally. Thanks, Roland On Thu, Sep 22, 2016 at 1:15 PM, Roland McGrath wrote: > ping? > > On Thu, Sep 15, 2016 at 4:09 PM, Roland McGr

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

new patch I'd like to commit. It has no regressions on x86_64-linux-gnu, but I'm not set up to test other configurations. gcc/ 2018-02-27 Roland McGrath PR other/77609 * varasm.c (default_section_type_flags): Set SECTION_NOTYPE for any section for which we don&

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

On Tue, Feb 27, 2018 at 8:14 PM, Ian Lance Taylor wrote: > Still OK, but it should wait until after the tree is back in stage 1. I've been hoping to get this fixed on stable branches (6, 7). Are you saying that this bug can only be fixed in 9? Or will it be OK to backport to 6, 7, and 8 once stag

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

OK. I'll come back in stage 1. Thanks, Roland

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

I'm back for stage 1! The same patch from https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01549.html rebases cleanly and I didn't change anything but the date on the log entry since what I posted there. The fresh rebase is on the roland/pr77609 git branch for your convenience. It has no check-gcc

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

ping On Sat, Apr 28, 2018 at 2:42 AM Roland McGrath wrote: > I'm back for stage 1! > The same patch from https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01549.html > rebases cleanly and I didn't change anything but the date on the log entry > since what I posted there.

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

Committed. Thanks, Roland