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

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

ping On Sat, Apr 28, 2018 at 2:42 AM Roland McGrath <mcgra...@google.com> 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 > s

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

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

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,

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

the 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 <mcgra...@google.com> PR other/77609 * varasm.c (default_section_type_flags): Set SECTION_NOTYPE for any

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 <mcgra...@google.com> wrote: > ping? > > On Thu, Sep 15, 2016 at

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 <mcgra...@google.com> 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, &g

[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 Roland McGrath <<

Re: RFC: Move .plt after .text in x86-64 binaries

The relative order of multiple executable sections inside the executable segment (distinct from nonexecutable read-only segment) is not important to NaCl.

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

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/ 2014-11-05 Roland McGrath mcgra

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 mcgra...@google.com wrote: [This patch

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

On Thu, Feb 13, 2014 at 10:58 PM, Uros Bizjak ubiz...@gmail.com 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

[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 mcgra...@google.com * configure.ac (HAVE_AS_IX86_UD2): New test for 'ud2' mnemonic. * configure

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.

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

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 mcgra...@google.com Mark Seaborn mseab...@google.com PR libstdc++/59392 * libsupc++/eh_call.cc

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

I've read through the MPX spec once, but most of it is still not very clear to me. So please correct any misconceptions. (HJ, if you answer any or all of these questions in your usual style with just, It's not a problem, I will find you and I will kill you. Explain!) Will an MPX-using binary

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

Backport committed to gcc-4_8-branch.

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

Committed to trunk. Thanks, Roland

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

This fixes a gratuitous warning. Thanks, Roland gcc/ 2013-03-25 Roland McGrath mcgra...@google.com * 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

Re: Bootstrapping glibc vs. dependency on system headers

As to the general case, I think float.h is probably the best choice and stdarg.h probably just as good. It's been a very long time since anything but GCC itself installed headers by those names. For libc, I think always using $CC -E is fine. You don't need to bother with the MSG_CHECKING and

[COMMITTED PATCH] add myself to write after approval list

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

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

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 mcgra...@google.com * config/arm/arm.c (get_label_padding): Use align_labels as minimum. diff --git a/gcc/config/arm/arm.c b/gcc/config

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

On Thu, Aug 2, 2012 at 1:57 AM, Julian Brown jul...@codesourcery.com 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

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

vanilla ARM target. But the logic of the change seems straightforward and sound. Thanks, Roland 2012-08-01 Roland McGrath mcgra...@google.com * 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

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

Thanks muchly!

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

ping?

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 mcgra...@google.com * config/arm/arm.c (arm_get_frame_offsets): Never use a fixed register as the extra register to save

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

-06-22 Roland McGrath mcgra...@google.com * 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 (ctzmode2): Use it. diff --git a/gcc

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

On Fri, Jun 22, 2012 at 11:57 AM, Uros Bizjak ubiz...@gmail.com 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

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

or so to have an assembler that passes the test now. Thanks, Roland gcc/ 2012-06-22 Roland McGrath mcgra...@google.com * configure.ac (HAVE_AS_IX86_REP_LOCK_PREFIX): Also require that the assembler accept 'rep bsf ...', 'rep bsr ...', and 'rep ret'. * configure

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

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

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

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

/ 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 mcgra...@google.com * config/arm/arm.c (arm_get_frame_offsets

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

On Thu, Jun 14, 2012 at 1:13 PM, Mike Stump mikest...@comcast.net 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, I can't help

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 mcgra...@google.com * config/arm/arm.c (arm_get_frame_offsets): Never use a fixed register as the extra register to save/restore for stack-alignment padding

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 mcgra...@google.com wrote: cf this change:        2010-11-19  Jakub Jelinek  ja...@redhat.com                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 r...@redhat.com 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 r...@redhat.com wrote: Applied. Thanks!

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

-0ubuntu7.10). Thanks, Roland libgcc/ 2012-06-08 Roland McGrath mcgra...@google.com * 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

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

not a GCC committer, so if you like the change, please commit it for me.) Thanks, Roland 2012-06-06 Roland McGrath mcgra...@google.com * 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

Re: Fwd: Using movw/movt rather than minipools in ARM gcc

On Mon, Apr 30, 2012 at 9:02 AM, Richard Earnshaw rearn...@arm.com wrote: It very much depends on your processor. I suppose we are probably concerned primarily with recentish OMAP and Tegra2 sorts of processors, but we are looking for generic good performance solutions for ARMv7-A class

Re: RFC: Add STB_GNU_SECONDARY

Please provide an example that illustrates why you think you need this. Thanks, Roland

Re: RFC: Add STB_GNU_SECONDARY

Currently we use weak undefined symbol, foo, to do if (foo != 0) foo is defined. else foo isn't defined. We want is to define foo as a secondary symbol so that we can always use foo without checking. If there is a primary one in a .o file and .so file, we will get the primary one,

Re: Building libstdc++ with current glibc, NULL and pthread.h

The change seems fine. But I think the log entry should have an explicit pointer to the POSIX interpretation citation by way of rationale. Thanks, Roland

Re: -fno-inline-functions vs glibc's initfini

Want me to prepare a s/-fno-inline-functions/-fno-inline/ patch? My reading was that actually we would want both of those switches (the first to avoid inlining as an implicit optimization, the second to avoid inlining of functions declared inline). But whatever the exact detail, yes, please

Re: -fno-inline-functions vs glibc's initfini

From Richard's response it sounds like there is an easy fix that's compatible with both old and new GCC (-fno-inline). I think we can do that right away without trouble, and get it onto release branches too. On the libc side more generally, I've become skeptical that the generic C version of

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

[PATCH] libgcc: refer to pthread_create, not pthread_cancel

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 that had pthreads at all. Thanks, Roland 2012-01-26 Roland

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

On Thu, Nov 3, 2011 at 11:05 AM, Roland McGrath mcgra...@google.com wrote: On Thu, Nov 3, 2011 at 10:55 AM, DJ Delorie d...@redhat.com 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

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

On Wed, Nov 2, 2011 at 8:32 PM, Ian Lance Taylor i...@google.com 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/

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

On Thu, Nov 3, 2011 at 10:39 AM, Ian Lance Taylor i...@google.com 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.

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

On Thu, Nov 3, 2011 at 10:55 AM, DJ Delorie d...@redhat.com 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

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

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 include them in a commit. Thanks, Roland 2011-11-02 Roland

[PATCH] libiberty: fix psignal parameter type

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 mcgra...@google.com * strsignal.c (psignal): Use const

Re: [PATCH] libiberty: fix psignal parameter type

On Tue, Oct 18, 2011 at 9:50 AM, Andrew Pinski pins...@gmail.com 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

Re: [PATCH] libiberty: fix psignal parameter type

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

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.

Re: x32 psABI draft version 0.2

I'm wondering if we should define a section header flag (sh_flags) and/or an ELF header flag (e_flags) for x32 for the people unhappy about keying it to the ELF class... I don't see what's wrong with paying attention to the class. IMHO sh_flags only makes sense if you might ever mix x32 and

Re: DWARF v4 .debug_line and .debug_frame formats

I'd say we should switch to version 4 only when we need the new fields (i.e. if ia64 or other VLIW starts using the new VLIW .debug_line features, let it use version 4, but for other targets 3 would be good enough). Similarly for .debug_frame. I agree that makes sense. The .debug_info v4

DWARF v4 .debug_line and .debug_frame formats

Are there any plans to make GCC and/or GAS emit the version 4 variants of the .debug_line and/or .debug_frame formats? The .debug_line version 4 format only adds the maximum operations per instruction header field and associated logic, which is only meaningful for VLIW machines (i.e. ia64--are

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

Feel free to send some gcc patches. I see no point in this. We have -Wl. I deal with a lot of host systems where shell scripts aren't a viable option for ld. Why make everyone write the wrapper script? Makes sense to me to have gcc decide. Like I said, I don't object to any new gcc

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

I'm still not entirely convinced that this is the way to go. It seems to me that ideally one wants to be able to select the linker at runtime. I don't see how this patch supports that. What am I missing? It covers the first step by letting you run ld.bfd or ld.gold to choose. Having the

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

Mainly because an alternative is to install them in subdirectories with the name ld. Then gcc can run them directly using a -B option. I don't know which approach is best. I think it keeps things simplest for humans to understand if the actual binaries are available as ld.bfd and ld.gold. If

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

why not make this more explicit by adding an option --ldld which is directly understood by the gcc driver? Feel free to send some gcc patches. I see no point in this. We have -Wl.

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

--with is wrong for this. It's not about the ambient system built against. It's a feature selection for how you build binutils, which means --enable.

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

I can't really tell how that's different from the patch I posted. It looks fine to me. Thanks, Roland

Re: Unwinding CFI gcc practice of assumed `same value' regs

GCC's unwinder doesn't distinguish undefined from same_value, because it doesn't matter for EH unwinding purposes. Both mean nothing to be done for this register. The distinction only matters to informative unwinding purposes like debugging. I'm not sure why libgcc's unwinder really ought to

Re: Request for clarification on the 128bit long double requirments

* If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support that, would it be possible to activate the support on the GLIBC 2.4 branch? This is not an option. When glibc 2.4 is released, the GLIBC_2.4 version set will never change again. Each platform will either change by the

Re: Request for clarification on the 128bit long double requirments

I hope I can clarify the situation. Planning and communication surely could have been much better, and as the person who coordinated the efforts that were made, I can be blamed for what we did and when we did it. glibc has lacked the manpower to be as organized as we would like to be, and given

Re: i_am_not_a_leaf() and -fno-unit-at-a-time

initfini.c needs -fno-unit-at-a-time. It's not a normal compilation, but a special hack for generating assembly fragments. The development libc uses the flag for that file.