Office Hours for the GNU Toolchain on 2024-06-27 at 11am EST5EDT.

Office Hours for the GNU Toolchain on 2024-06-27 at 11am EST5EDT. Agenda: * https://gcc.gnu.org/wiki/OfficeHours#Next Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.

Office Hours for the GNU Toolchain on 2024-05-30 at 11am EST5EDT.

Office Hours for the GNU Toolchain on 2024-05-30 at 11am EST5EDT. Agenda: * https://gcc.gnu.org/wiki/OfficeHours#Next Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.

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

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

gcc-wwwdocs branch master updated. 3e9f71f2c5ae175b2a4b209156f2241fa0646381

--- commit 3e9f71f2c5ae175b2a4b209156f2241fa0646381 Author: Carlos O'Donell Date: Thu Apr 25 11:29:02 2024 -0400 wwwdocs: contribute.html: Update consensus on patch content. Discussion is here: https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/

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

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. ---

Invitation: Office Hours for the GNU Toolchain @ Thu May 30, 2024 11am - 12pm (EDT) (gcc@gcc.gnu.org)

-TT_R5q Office hours for the GNU Toolchain:https://gcc.gnu.org/wiki/OfficeHoursMeeting link:https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 Organizer Carlos O'Donell codon...@redhat.com Guests Carlos O'Donell - organizer Nick Clifton Jakub Jelinek David Edelsohn Siddhesh Poyarekar Jason

Invitation: Office Hours for the GNU Toolchain @ Monthly from 11am to 12pm on the last Thursday (EDT) (gcc@gcc.gnu.org)

=AOvVaw2V18NEONPlH-coE-TT_R5q Office hours for the GNU Toolchain:https://gcc.gnu.org/wiki/OfficeHoursMeeting link:https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 Organizer Carlos O'Donell codon...@redhat.com Guests Carlos O'Donell - organizer Nick Clifton Jakub Jelinek David Edelsohn Siddhesh

Office Hours for the GNU Toolchain on 2024-04-25 at 11am EST5EDT.

Office Hours for the GNU Toolchain on 2024-04-25 at 11am EST5EDT. Agenda: * https://gcc.gnu.org/wiki/OfficeHours#Next Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.

Office Hours for the GNU Toolchain on 2024-03-28 at 11am EST5EDT.

Office Hours for the GNU Toolchain on 2024-03-28 at 11am EST5EDT. Agenda: * https://gcc.gnu.org/wiki/OfficeHours#Next Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.

Office Hours for the GNU Toolchain on 2024-02-29 at 11am EST5EDT.

Office Hours for the GNU Toolchain on 2024-02-29 at 11am EST5EDT. Agenda: * https://gcc.gnu.org/wiki/OfficeHours#Next Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.

Re: New TLS usage in libgcc_s.so.1, compatibility impact

On 1/15/24 08:55, Adhemerval Zanella Netto wrote: > > > On 15/01/24 09:46, Szabolcs Nagy wrote: >> The 01/13/2024 13:49, Florian Weimer wrote: >>> This commit >>> >>> commit 8abddb187b33480d8827f44ec655f45734a1749d >>> Author: Andrew Burgess >>> Date: Sat Aug 5 14:31:06 2023 +0200 >>> >>>

Office Hours for the GNU Toolchain on 2024-01-25 at 11am EST5EDT.

Office Hours for the GNU Toolchain on 2024-01-25 at 11am EST5EDT. Agenda: * https://gcc.gnu.org/wiki/OfficeHours#Next Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.

Office Hours for the GNU Toolchain on 2023-11-30 at 11am EST5EDT.

Office Hours for the GNU Toolchain on 2023-11-30 at 11am EST5EDT. Agenda: * https://gcc.gnu.org/wiki/OfficeHours#Next Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.

Re: Checks that autotools generated files were re-generated correctly

On 11/7/23 02:38, Maxim Kuvyrkov wrote: >> On Nov 6, 2023, at 21:19, Christophe Lyon >> wrote: >> >> Hi! >> >> On Mon, 6 Nov 2023 at 18:05, Martin Jambor >> wrote: >>> >>> Hello, >>> >>> I have inherited Martin Liška's buildbot script that checks that >>> all sorts of autotools generated

Office Hours for the GNU Toolchain on October 17th at 11am EDT.

Office Hours for the GNU Toolchain on October 17th at 11am EDT. Agenda: * First Office Hours and test of the meeting system. * No specific agenda will be presented, but feel free to attend. Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.

Re: [RFC] GCC Security policy

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)

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

RFP is open for the Toolchains and Kernel Track at LPC 2022

The Linux Plumbers Conference 2022 (https://lpc.events) will be held from 12 to 14 of September 2022 in Dublin. As part of the conference we will be having a Toolchains and Kernel track that will focus on topics of interest related to building the Linux kernel, and kernel development in general.

Re: https://patchwork.sourceware.org/project/gcc/

On 9/29/21 07:22, Jonathan Wakely wrote: > On Wed, 29 Sept 2021 at 11:04, Thomas Schwinge > wrote: >> Also, we'll need some user guide: web page, or wiki page, or, >> preferably?, on itself. >> How are we using the different states, archived,

The official glibc IRC channel is now on OFTC as #glibc.

Community, The official glibc IRC channel is now on OFTC as #glibc. gcc developers, please feel free to visit #glibc :-) We also have an unofficial IRC channel #glibc on Libera.Chat -- Cheers, Carlos.

Re: New x86-64 micro-architecture levels

On 7/22/20 6:34 AM, Florian Weimer wrote: > * Jan Beulich: > >> On 21.07.2020 20:04, Florian Weimer wrote: >>> * Premachandra Mallappa: >>> [AMD Public Use] Hi Floarian, > I'm including a proposal for the levels below. I use single > letters for them, but I expect

Re: New x86-64 micro-architecture levels

On 7/22/20 5:26 AM, Richard Biener via Libc-alpha wrote: > So for the bike-shedding I indeed think x86-10{0,1,2,3} > or x86-{A,B,C,..}, eventually duplicating as x86_64- as > suggested by Jan is better than x86-2014 or x86-avx2. Agreed. If we really want to be clear, call it a "level" or

Re: Separate commit mailing lists for trunk/branches possible?

On 7/17/20 3:41 PM, Florian Weimer wrote: > * Carlos O'Donell via Gcc: > >> FYI, for glibc we use the AdaCore git commit hooks (like gdb). >> >> There we use this configuration: >> >> # Only send emails for master and release branches. >>

Re: Separate commit mailing lists for trunk/branches possible?

On 7/17/20 2:11 PM, Frank Ch. Eigler via Overseers wrote: > Hi - > >> Would it be reasonable to have the mailing list split into more than >> one, that is at least the original covering the trunk, and then one >> or more for branches? [...] > > (This matter is for the gcc community to decide.

Feedback on the GNU Social contract and new wiki.gnu.tools.

Myself and several other GNU Maintainers have been publicly discussing a GNU Social contract on gnu-misc-disc...@gnu.org and what it means to be a GNU Project volunteer. We are continuing that discussion by reaching out (by email) to all GNU Maintainers. We look forward to your feedback! Please

Setting up a wiki for GNU Project volunteers?

A wiki for GNU Project volunteers would provide a central place for cross-project collaboration, including collaboration between gcc, glibc, gdb, and binutils. This is an invitation to discuss having a high-level wiki for GNU Project volunteers. The conversation is on gnu-misc-discuss:

Public discussions on GNU Project governance.

and opinions about governance and how it relates to the GNU Project. Please keep the conversations kind [1] and strictly about governance and not about specific people and their respective abilities. If you need an example: "Carlos O'Donell is an aweful leader and speller" is off-topic, but &qu

Re: glibc-2.2{8,9} multiarch build failure on x86_64 with gcc 9

On 5/1/19 2:24 PM, Arvind Sankar wrote: gcc 9 when configured for fortran installs ISO_Fortran_Binding.h in gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include For x86_64's 32-bit architecture support, this creates a subdirectory named 'include' inside

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On 10/19/2017 09:45 AM, Joseph Myers wrote: > On Thu, 19 Oct 2017, Thomas Schwinge wrote: > >> Hi! >> >> Still waiting for any kind of reaction -- general process-change inertia, >> chicken-and-egg problem, I suppose. ;-/ >> >> I have now put the proposed text onto a wiki page, so that those >>

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On 10/19/2017 09:45 AM, Joseph Myers wrote: > On Thu, 19 Oct 2017, Thomas Schwinge wrote: > >> Hi! >> >> Still waiting for any kind of reaction -- general process-change inertia, >> chicken-and-egg problem, I suppose. ;-/ >> >> I have now put the proposed text onto a wiki page, so that those >>

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

venient handle to use, > <https://gcc.gnu.org/wiki/Reviewed-by>. I've started using Reviewed-by: Carlos O'Donell <car...@redhat.com> and Signed-off-by: Carlos O'Donell <car...@redhat.com> in all my glibc reviews. Since then I've seen 5 such items go into the git commit messages. Progress? :-) -- Cheers, Carlos.

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On 09/21/2017 12:38 PM, Richard Biener wrote: > On September 21, 2017 8:18:39 PM GMT+02:00, Carlos O'Donell > <car...@redhat.com> wrote: >> On 09/21/2017 11:56 AM, Richard Biener wrote: >>>> Not yet. >>> >>> I think given an OK from an offici

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On 09/21/2017 11:56 AM, Richard Biener wrote: >> Not yet. > > I think given an OK from an official reviewer entitles you to commit > it indeed IS matching the formal statement. It better does... Isn't it better to be explicit about this; rather than assuming? >> All of this is nothing compared

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On 09/21/2017 10:50 AM, Thomas Schwinge wrote: > So my question is, if I've gotten a patch reviewed by someone who is not > yet ;-) familiar with that new process, and I nevertheless want to > acknowledge their time invested in review by putting "Reviewed-by" into > the commit log, is it fine to

Re: RFC: Add ___tls_get_addr

On 07/05/2017 12:02 PM, Rich Felker wrote: > Note that if you make the change and have gcc generate calls to the > new ___tls_get_addr symbol, it's going to be problematic for people > trying to link to older glibc versions that don't have it. This is a normal problem to have, and there are

Re: RFC: Add ___tls_get_addr

On 07/05/2017 11:38 AM, H.J. Lu wrote: > On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by > GCCs older than GCC 4.9.4: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 > > continue to work even if vector instructions are used by functions called > from

Re: [PATCH] Implement new hook for max_align_t_align

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

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

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

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

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

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

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.

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.

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.

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)

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)

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.

Re: RFC: Doc update for attribute

On 05/20/2014 03:02 AM, David Wohlferd wrote: After thinking about this some more, I believe I have some better text. Previously I used the word discouraged to describe this practice. The existing docs use the term avoid. I believe what you want is something more like the attached. Direct and

Re: RFC: Doc update for attribute

On 05/20/2014 03:59 AM, Georg-Johann Lay wrote: Am 05/16/2014 07:16 PM, schrieb Carlos O'Donell: On 05/12/2014 11:13 PM, David Wohlferd wrote: After updating gcc's docs about inline asm, I'm trying to improve some of the related sections. One that I feel has problems with clarity

Re: RFC: Doc update for attribute

On 05/12/2014 11:13 PM, David Wohlferd wrote: After updating gcc's docs about inline asm, I'm trying to improve some of the related sections. One that I feel has problems with clarity is __attribute__ naked. I have attached my proposed update. Comments/corrections are welcome. In a

[PATCH] MAINTAINERS: Update email address.

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

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

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

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

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

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)

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

Re: [Patches] C++ linking problem when locale are disabled in eglic.

On Tue, Mar 13, 2012 at 6:43 AM, Jonathan Wakely jwakely@gmail.com wrote: This should have been CC'd to the libstdc++ list too. C++ programs don't link anymore with gcc 4.5.3 and eglibc 2.15 with OPTION_EGLIBC_LOCALE_CODE=n. It seems that gcc/libstdc++-v3/acinclude.m4 doesn't check for

[RFC] Implementation and documentation of -iwithprefix do not match?

, then it appears that there would be no issue. Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716

Re: Possible GCC 4.3 driver regression caused by your patch

breaks my build, what error are you seeing? Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716

Re: History of m68k ABI and `-malign-int'?

On Thu, Jan 17, 2008 at 01:08:16AM +0100, Andreas Schwab wrote: Carlos O'Donell [EMAIL PROTECTED] writes: Why is 16-bit int alignment the default for m68k in gcc? Which ABIs influenced this decision? The original ABI was defined by Sun PCC. Note that the SysV ABI actually uses

History of m68k ABI and `-malign-int'?

int alignment? Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716

Re: [PATCH] Relocated compiler should not look in $prefix.

On Mon, Oct 16, 2006 at 03:32:27PM -0700, Mark Mitchell wrote: Ian Lance Taylor wrote: Carlos O'Donell [EMAIL PROTECTED] writes: A relocated compiler should not look in $prefix. I agree. I can't approve your patches, though. This patch is OK, once we reach Stage 1. Checked

Re: pr27650 - dllimport of virtual methods broken.

/27650 * g++.dg/ext/dllimport12.C: New file. Mark, What is your opinion on this patch? Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716

pr27650 - dllimport of virtual methods broken.

. The fix works, but is it correct? Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716

Re: Imported GNU Classpath 0.92

On Wed, Aug 23, 2006 at 08:47:32AM +0200, Mark Wielaard wrote: On Tue, 2006-08-22 at 16:33 -0400, Carlos O'Donell wrote: Has the 'make html' target been fixed? I would like to enable this target so that html support doesn't bitrot. No sorry. I didn't know it was broken. I see that it only

Re: Imported GNU Classpath 0.92

this target so that html support doesn't bitrot. Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716

Re: Bootstrap broken on ppc-darwin

. Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716

Re: Bootstrap broken on ppc-darwin

. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716 2006-07-17 Carlos O'Donell [EMAIL PROTECTED] * dbxout.c (dbxout_function_end): Do not increment scope_labelno. (dbxout_begin_prologue): Increment scope_labelno. Index: gcc/dbxout.c

Searching configured and relocated prefix.

to find, you can get NFS time-outs, etc. However, the strategy above will break situations where people expect to find some of their bits in a directory indicated by GCC_EXEC_PREFIX, and the rest in the configured prefix. Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331

Examples of callee returning struct, but caller allocating space?

separately then an optimization in the caller could cause a problem. Rightly though the caller can't optimize without breaking ABI. Rightly the callee can't opimize away the size check without breaking ABI. Without coordination we can't safely remove the checks. Cheers, Carlos. -- Carlos O'Donell