Re: [PATCH] wwwdocs: contribute.html: Update consensus on patch content.

2024-05-01 Thread Carlos O'Donell
On 4/25/24 14:32, Richard Biener wrote: > > >> Am 25.04.2024 um 17:44 schrieb Carlos O'Donell : >> >> Discussion is here: >> https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/ >> >> Rough consensus fro

[PATCH] wwwdocs: contribute.html: Update consensus on patch content.

2024-04-25 Thread Carlos O'Donell
Discussion is here: https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/ Rough consensus from Jakub Jelinek, Richard Biener and others is that maintainers are for the change. This changes the contribution notes to allow it. ---

Re: [RFC] GCC Security policy

2023-08-08 Thread Carlos O'Donell via Gcc-patches
On 8/8/23 13:46, David Edelsohn wrote: > I believe that upstream projects for components that are imported > into GCC should be responsible for their security policy, including > libgo, gofrontend, libsanitizer (other than local patches), zlib, > libtool, libphobos, libcody, libffi, eventually

Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

2023-01-20 Thread Carlos O'Donell via Gcc-patches
On 1/19/23 23:26, Bernhard Reutner-Fischer wrote: > On 19 January 2023 20:39:08 CET, Jason Merrill wrote: >> On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches >> wrote: >>> >>> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches: This function definition was

Re: [PATCH] Implement new hook for max_align_t_align

2016-10-12 Thread Carlos O'Donell
On 10/12/2016 10:17 AM, John David Anglin wrote: > On 2016-10-12 9:48 AM, Jason Merrill wrote: >> On Wed, Oct 12, 2016 at 4:02 AM, Jakub Jelinek wrote: >>> On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote: dropping the alignment means that the padding before

Re: [PATCH] Implement new hook for max_align_t_align

2016-10-12 Thread Carlos O'Donell
On 10/11/2016 04:04 PM, John David Anglin wrote: > On 2016-10-11 2:50 PM, Jason Merrill wrote: >> /* Alignment, in bits, a C conformant malloc implementation has to >> provide. >> The HP-UX malloc implementation provides a default alignment of 8 >> bytes. >> This can be increased with

Re: [gofrontend-dev] Go patch committed: Avoid warning by using a local var for std::ofstream

2016-09-21 Thread Carlos O'Donell
On 09/21/2016 10:56 AM, Florian Weimer wrote: > * John David Anglin: > >> On Tue, Sep 20, 2016 at 09:27:17PM +0200, Florian Weimer wrote: >>> * Ian Lance Taylor: >>> GCC PR 77625 is about a warning while compiling the Go frontend. The Go frontend called `new std::ofstream()`, and the

Re: [PATCH] Support x86-64 TLS code sequences without PLT

2016-06-06 Thread Carlos O'Donell
On 06/03/2016 05:21 PM, H.J. Lu wrote: > We can generate x86-64 TLS code sequences for general and local dynamic > models without PLT, which uses indirect call via GOT: > > call *__tls_get_addr@GOTPCREL(%rip) > > instead of direct call: > > call __tls_get_addr[@PLT] What are the actual pros

Re: An abridged "Writing C" for the gcc web pages

2016-05-03 Thread Carlos O'Donell
On 05/03/2016 06:39 PM, Bernd Schmidt wrote: > On 05/03/2016 09:59 PM, Richard Sandiford wrote: >> >> And sometimes there are multiple acceptable ways of writing the >> same code. Which wins is an aesthetic choice, which tools tend to >> be bad at handling. E.g. if a parameter list is too long

Re: An abridged "Writing C" for the gcc web pages

2016-05-03 Thread Carlos O'Donell
On 05/03/2016 03:59 PM, Richard Sandiford wrote: > Jeff Law <l...@redhat.com> writes: >> On 05/02/2016 02:40 PM, Carlos O'Donell wrote: >>> >>> However, in the end, I think that yet-another-document is not the >>> solution we want. What we actually ne

Re: An abridged "Writing C" for the gcc web pages

2016-05-02 Thread Carlos O'Donell
On 04/22/2016 12:21 PM, Bernd Schmidt wrote: > (Apologies if you get this twice, the mailing list didn't like the > html attachment in the first attempt). > > We frequently get malformatted patches, and it's been brought to my > attention that some people don't even make the effort to read the

Re: [PATCH] extend.texi: Expand on the perils of using the 'leaf' attribute.

2016-03-15 Thread Carlos O'Donell
On 03/14/2016 06:15 PM, Sandra Loosemore wrote: > On 03/14/2016 12:40 PM, Carlos O'Donell wrote: >> Using the 'leaf' attribute is difficult in certain use cases, and >> the documentation rightly points out that signals is one such >> problem. >> >> We should ad

Re: [PATCH] extend.texi: Expand on the perils of using the 'leaf' attribute.

2016-03-15 Thread Carlos O'Donell
On 03/14/2016 06:15 PM, Sandra Loosemore wrote: > On 03/14/2016 12:40 PM, Carlos O'Donell wrote: >> Using the 'leaf' attribute is difficult in certain use cases, and >> the documentation rightly points out that signals is one such >> problem. >> >> We should ad

[PATCH] extend.texi: Expand on the perils of using the 'leaf' attribute.

2016-03-14 Thread Carlos O'Donell
s. gcc/ 2016-03-14 Carlos O'Donell <car...@redhat.com> * doc/extend.texi (Common Function Attributes): Describe ifunc impact on leaf attribute. Index: extend.texi === --- extend.texi (revision 234183) +++

Re: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)

2014-07-08 Thread Carlos O'Donell
On 07/08/2014 08:50 AM, Jakub Jelinek wrote: Hi! This is an attempt to move the warning about transposed memset arguments from the glibc headers to gcc FEs. The problem with the warning in glibc is that it uses __builtin_constant_p and e.g. jump threading very often makes the warning

Re: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)

2014-07-08 Thread Carlos O'Donell
On 07/08/2014 03:24 PM, Jason Merrill wrote: I don't think we want to warn about e.g. 1-1, only about literal 0. What rationale would you give for not warning on 1-1? Cheers, Carlos.

[PATCH] MAINTAINERS: Update email address.

2013-08-09 Thread Carlos O'Donell
I'm working at Red Hat now as the glibc team lead within the tools group. Please feel free to reach out to me if you have any glibc related questions. Still having fun working on GNU tools :-) Committed. 2013-08-09 Carlos O'Donell car...@redhat.com * MAINTAINERS (Write After

Re: [PATCH, libstdc++] Fix 22_locale/time_get/get_weekday/char/38081-[12].cc tests for glibc 2.17

2013-02-11 Thread Carlos O'Donell
On 02/11/2013 12:28 PM, H.J. Lu wrote: On Mon, Feb 11, 2013 at 9:18 AM, Paolo Carlini paolo.carl...@oracle.com wrote: On 02/11/2013 04:33 PM, Julian Brown wrote: Hi, It seems that glibc 2.17 changes the abbreviated names of weekdays for ru_RU locales by removing an extraneous ., as

Re: PATCH to libstdc++ to use __cxa_thread_atexit_impl if available

2013-01-22 Thread Carlos O'Donell
On 01/22/2013 07:24 PM, Siddhesh Poyarekar wrote: Cc'ing Carlos on this so that he's aware of it. Siddhesh Jakub Jelinek ja...@redhat.com wrote: On Sat, Jan 19, 2013 at 12:22:23PM -0500, Jason Merrill wrote: Siddhesh has a patch to implement the thread atexit functionality in glibc in

Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI

2012-04-26 Thread Carlos O'Donell
On Mon, Apr 23, 2012 at 5:36 PM, Michael Hope michael.h...@linaro.org wrote: 2012-04-24  Michael Hope  michael.h...@linaro.org            Richard Earnshaw  rearn...@arm.com        * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.        (GLIBC_DYNAMIC_LINKER_HARD_FLOAT):

Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI

2012-04-23 Thread Carlos O'Donell
On Sun, Apr 22, 2012 at 6:20 PM, Michael Hope michael.h...@linaro.org wrote: Change the dynamic linker path for ARM hard float executables. Matches the path discussed and agreed on last week[1].  Carlos will follow up with the matching patch to GLIBC[2].  I'm happy to if he's busy. I'm

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

2012-04-10 Thread Carlos O'Donell
On Tue, Apr 3, 2012 at 6:56 PM, Joseph S. Myers jos...@codesourcery.com wrote: (e) Existing practice for cases that do use different dynamic linkers is to use a separate library directory, not just dynamic linker name, as in lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot

Re: struct siginfo vs. siginfo_t (was: GNU C Library master sources branch, master, updated. glibc-2.15-229-g4efeffc)

2012-03-15 Thread Carlos O'Donell
On Thu, Mar 15, 2012 at 11:05 AM, Thomas Schwinge tho...@codesourcery.com wrote: Hi! On 26 Feb 2012 18:17:52 -, drep...@sourceware.org wrote: http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=4efeffc1d583597e4f52985b9747269e47b754e2 commit