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
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
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
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
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
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,
Committed to trunk.
Thanks,
Roland
Backport committed to gcc-4_8-branch.
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
Did you read the patch? It uses an empirical configure check to
discover if the assembler does in fact support ud2.
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
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
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
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
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.
>> *
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
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
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 ".
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
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
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
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
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,
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 -
OK then. If you like the original patch, would you like to commit it for me?
Thanks,
Roland
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?
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
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
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 ...
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'.
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
ping?
Thanks muchly!
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
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.
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
-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
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
On Mon, Jun 11, 2012 at 1:42 PM, Richard Henderson wrote:
> Applied.
Thanks!
On Mon, Jun 11, 2012 at 2:16 PM, Richard Henderson wrote:
> Applied.
Thanks!
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
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
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
The libcpp code uses `#ifdef HAVE_SETLOCALE` but its configure doesn't
have the corresponding check.
Ok for trunk and 14 branch?
(Sorry for the attachment, my MUA is difficult.)
Thanks,
Roland
libcpp/
2025-03-27 Roland McGrath
* configure.ac: Check for setlocale.
* configure, conf
I've spent more than my fair share of my life fiddling with autoconf
installations, so I just hand-editted the patches to elide the
unwanted changes.
Now committed on both trunk and releases/14.
Thanks,
Roland
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
Committed.
Thanks,
Roland
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
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&
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
OK. I'll come back in stage 1.
Thanks,
Roland
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
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.
Committed.
Thanks,
Roland
54 matches
Mail list logo
