Re: Deprecation/removal of nios2 target support

On 4/18/24 10:06, Jeff Law wrote: ACK.  Just one more note to the wider audience.  I looked at QEMU's user mode support for nios2 on/off over the last couple years.  It never seemed to work well enough be able to run the GCC testsuite reliably. I looked at the problems with the nios2 user-mo

Deprecation/removal of nios2 target support

Tomorrow I plan to push patches to mark the nios2 target as obsolete in GCC 14. Background: Intel has EOL'ed the Nios II processor IP and is now directing their FPGA customers to a RISC-V platform instead. https://www.intel.com/content/www/us/en/content-details/781327/intel-is-discontinuing-i

Re: Sourceware mitigating and preventing the next xz-backdoor

On 4/1/24 09:06, Mark Wielaard wrote: A big thanks to everybody working this long Easter weekend who helped analyze the xz-backdoor and making sure the impact on Sourceware and the hosted projects was minimal. This email isn't about the xz-backdoor itself. Do see Sam James FAQ https://gist.githu

Re: Announcement: Porting the Docs to Sphinx - tomorrow

On 11/11/22 13:52, Gerald Pfeifer wrote: On Tue, 8 Nov 2022, Martin Liška wrote: After the migration, people should be able to build (and install) GCC even if they miss Sphinx (similar happens now if you miss makeinfo). My nightly *install* (not build) on amd64-unknown-freebsd12.2 broke (from

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/19/22 05:09, Martin Liška wrote: On 10/18/22 00:26, Sandra Loosemore wrote: On 10/17/22 07:28, Martin Liška wrote: Hello. Based on the very positive feedback I was given at the Cauldron Sphinx Documentation BoF, I'm planning migrating the documentation on 9th November. There are

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/17/22 07:28, Martin Liška wrote: Hello. Based on the very positive feedback I was given at the Cauldron Sphinx Documentation BoF, I'm planning migrating the documentation on 9th November. There are still some minor comments from Sandra when it comes to the PDF output, but we can address

Re: Pushing XFAILed test cases

On 7/16/21 9:32 AM, Thomas Schwinge wrote: [much snipped] Of course, we shall assume a certain level of quality in the XFAILed test cases: I'm certainly not suggesting we put any random junk into the testsuite, coarsely XFAILed. (I have not reviewed Sandra's test cases to that effect, but know

Re: Proposal for the transition timetable for the move to GIT

On 12/6/19 12:46 PM, Eric S. Raymond wrote: Richard Biener : To me, looking from the outside, the talks about reposurgeon doing damage and a rewrite (in the last minute) would fix it doesn't make a trustworthy appearance either ;) *shrug* Hard problems are hard. Every time I do a conversion

Re: Documentation style for options with optional levels

On 4/10/19 5:13 AM, Jonathan Wakely wrote: For options that can be used as -foo or -foo=level we have a variety of different styels for documenting what the default level is. See below for several examples. I find this a bit confusing when try to see what it means to use the option without a leve

Re: Can anybody help us to approved our registering request?

On 08/23/2018 07:04 AM, 瞿仙淼 wrote: Yes, it’s registering for account on sourceware.org/gcc.gnu.org . I have not complete the request form in https://sourceware.org/cgi-bin/pdw/ps_form.cgi because I want to find someone who can sponsoring my account first, then I can fill this personal's email

Re: "position independent" vs "position-independent" in documentation

On 04/30/2018 05:56 AM, Jonathan Wakely wrote: Should we standardize on "position-independent" and add it to https://gcc.gnu.org/codingconventions.html#Spelling ? The same generic English usage rules apply here as to other compound phrases; hyphenate when immediately before a noun, don't hyphe

Re: -g and -fvar-tracking

On 04/24/2018 01:05 AM, Jakub Jelinek wrote: On Mon, Apr 23, 2018 at 10:15:57PM -0600, Sandra Loosemore wrote: Can somebody remind me why using -g doesn't also enable -fvar-tracking by default? At least for -g2, which is supposed to emit debug information about local variables? It seems

-g and -fvar-tracking

Can somebody remind me why using -g doesn't also enable -fvar-tracking by default? At least for -g2, which is supposed to emit debug information about local variables? It seems kind of counterintuitive to me that specifying a -O option enables a pass to collect better debug information but sp

Re: "file name" vs "filename"

On 04/01/2018 02:56 PM, Joel Sherrill wrote: On Sun, Apr 1, 2018, 3:16 PM Gerald Pfeifer > wrote: And now to the most important question of all. ;-)  Should we use "file name" or "filename" when referring to the name of a file? Our docs currently are ab

Re: $target.h vs $target-protos.h

On 02/19/2018 09:45 AM, Joseph Myers wrote: On Sun, 18 Feb 2018, Sandra Loosemore wrote: Thanks, this makes sense. I think I could produce a documentation patch that explains that the difference is early vs late inclusion, and explains that any declarations involving tree or rtx types must go

Re: $target.h vs $target-protos.h

On 02/18/2018 12:10 PM, Joseph Myers wrote: On Sun, 18 Feb 2018, Sandra Loosemore wrote: So what is the purpose of having a separate $target-protos.h? It looks like the original explanation was <https://gcc.gnu.org/ml/gcc-patches/1999-09n/msg00866.html>, "Because tm_p.h needs to

$target.h vs $target-protos.h

The internals manual says that a backend for $target should have $target.h and $target-protos.h files, but doesn't say what the difference between them is or what belongs in which file. Current practice seems to be a mix of (1) $target.h contains macro definitions and $target-protos.h contain

Re: Status of m32c target?

On 01/19/2018 10:14 AM, Jeff Law wrote: cc0 needs to die. That doesn't mean that any particular target needs to be dropped -- it just means that someone has to step forward to do the conversion. Unifying two parallel threads: might this be a good project for GSoC? -Sandra

Re: Status of m32c target?

On 01/15/2018 05:46 AM, Joseph Myers wrote: On Mon, 15 Jan 2018, Sebastian Huber wrote: On 13/01/18 00:16, Jeff Law wrote: On 01/12/2018 04:07 PM, Joseph Myers wrote: On Fri, 12 Jan 2018, Jeff Law wrote: I was going to suggest deprecation for gcc-8 given how badly it was broken in gcc-7 and

Re: Exhaustive Instructions for Toolchain Generation

On 10/05/2017 03:52 PM, Jonathan Wakely wrote: Maybe it's best if this thread is allowed to die. Yes, thank you. :-) -Sandra

Re: Exhaustive Instructions for Toolchain Generation

On 10/05/2017 02:16 PM, R0b0t1 wrote: I find it hard to care about someone's position or affiliation but instead choose to care about what they do and how they act. If it was Sandra's intent to ask me for free work, then I am not sure how that qualifies as "the right thing." Per my latest respon

Re: pass manager question

On 10/03/2017 10:45 AM, Sandra Loosemore wrote: On 10/03/2017 05:36 AM, Martin Jambor wrote: Hi, On Mon, Oct 02, 2017 at 01:27:05PM -0600, Sandra Loosemore wrote: Is there an idiom for target-specific back end code to ask the pass manager if a particular pass (e.g., "split1") has a

Re: Exhaustive Instructions for Toolchain Generation

On 10/03/2017 03:27 PM, R0b0t1 wrote: On Sun, Oct 1, 2017 at 4:35 PM, Sandra Loosemore mailto:san...@codesourcery.com>> wrote: [snip] FAOD, R0b0t1 forwarded mail I deliberately sent off-list back to the list. I do know that business solicitations are frowned upon on the mailing

Re: pass manager question

On 10/03/2017 05:36 AM, Martin Jambor wrote: Hi, On Mon, Oct 02, 2017 at 01:27:05PM -0600, Sandra Loosemore wrote: Is there an idiom for target-specific back end code to ask the pass manager if a particular pass (e.g., "split1") has already run? (I might be wrong but) I don't

pass manager question

Is there an idiom for target-specific back end code to ask the pass manager if a particular pass (e.g., "split1") has already run? I have some nios2 addressing mode improvement patches in the works that depend on deferring splitting of some complex address forms until after cse and fwprop, ins

Re: Linux and Windows generate different binaries

On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote: I have seen reproducible builds being discussed here, but what is the position on inter c-lib and OS reproducible builds? I think we consider unstable sort problems bugs and have fixed them in the past. Bugzilla search turned up #289

Re: Obsolete powerpc*-*-*spe*

On 03/15/2017 08:26 AM, Segher Boessenkool wrote: Since SPE and VLE only share the part of the rs6000 port that doesn't change at all (except for a bug fix once or twice a year), and everything else needs special cases all over the place, it seems to me it would be best for everyone if we split

Re: Obsolete powerpc*-*-*spe*

On 02/16/2017 03:19 PM, Segher Boessenkool wrote: On Thu, Feb 16, 2017 at 02:49:47PM -0700, Sandra Loosemore wrote: I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This includes the spe.h installed header file, all the __builtin_spe* intrinsics, the -mfloat-gprs= command-line option

Re: Obsolete powerpc*-*-*spe*

On 02/13/2017 08:07 PM, Segher Boessenkool wrote: Hi all, I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This includes the spe.h installed header file, all the __builtin_spe* intrinsics, the -mfloat-gprs= command-line option, and the support for the SPE ABIs. No one has properly test

Re: Doc question: is "templatized" a word?

On 02/11/2017 06:21 AM, Jonathan Wakely wrote: On 11 February 2017 at 08:48, Gerald Pfeifer wrote: On Fri, 10 Feb 2017, Sandra Loosemore wrote: The documentation for -Wno-non-template-friend refers to "non-templatized friend functions" and "templatized functions".

Doc question: is "templatized" a word?

The documentation for -Wno-non-template-friend refers to "non-templatized friend functions" and "templatized functions". I don't see the term "templatized" used anywhere in the C++ standard. This paragraph also uses "nontemplate function", which I assume refers to the same thing the C++ stand

Re: Converting to LRA (calling all maintainers)

On 01/03/2017 02:22 PM, Eric Botcazou wrote: p.s. Are there plans for converting the SPARC port? The SPARC port has now been converted. Note that the status of the PowerPC port is a bit confusing because both doc/invoke.texi and htdocs/backends.html say that it still uses reload. Have any b

Re: Do we really need a CPP manual?

On 12/16/2016 08:45 AM, Joseph Myers wrote: On Thu, 15 Dec 2016, Sandra Loosemore wrote: Looking at the structure of the whole manual, though, I see that most of it is in fact a tutorial on how to use the preprocessor language, like you would find in a C programming book. Is this a useful

Do we really need a CPP manual?

I've had an item on my todo list for a while to try to update the CPP manual, mainly because I've been aware that it has duplicate entries for several of the same command-line options that appear in invoke.texi that have gotten bit-rotten or otherwise out of sync with respect to the GCC manual

Re: Mingw-w64 exception handling configuration

On 05/12/2016 09:27 AM, Sandra Loosemore wrote: I see that the default EH behavior for a biarch mingw-w64 target GCC is to use SJLJ for the 32-bit multilib and SEH for the 64-bit one, but that there are #errors in cygming.h and mingw32.h that prevent you from configuring a biarch build with

Mingw-w64 exception handling configuration

I see that the default EH behavior for a biarch mingw-w64 target GCC is to use SJLJ for the 32-bit multilib and SEH for the 64-bit one, but that there are #errors in cygming.h and mingw32.h that prevent you from configuring a biarch build with --disable-sjlj-exceptions to use DWARF-2 and SEH, r

Re: Nios2 arch=r1/r2

On 03/09/2016 03:03 AM, BELBACHIR Selim wrote: Hi, I'm looking at gcc-nios2 options -march. It seems two instruction sets can be selected (r1/r2) but I cannot find out where theses instructions set are described. On the other end I found this document https://www.altera.com/content/dam/altera-

C/C++ standards supported by the preprocessor

I noticed that the section on preprocessor options in the GCC manual (which is also shared by the CPP manual) still claims that the default -std= values are gnu90 for C and gnu++98 for C++, and does not list any C++ versions after gnu++98. AFAICT from digging through code and trying some expe

Re: basic asm and memory clobbers

On 11/19/2015 06:23 PM, David Wohlferd wrote: About the only immediate task would be to ensure that the documentation for traditional asms clearly documents the desired semantics and somehow note that there are known bugs in the implementation (ie 24414, handling of flags registers, and probably

Re: inline asm and multi-alternative constraints

On 11/02/2015 04:06 PM, Jeff Law wrote: On 10/30/2015 09:09 PM, David Wohlferd wrote: I have updated the non-md text with (most of) the changes I think it needs (attached). These changes are pleasantly minor, mostly just adding some example text and a bit of formatting. However. Trying to ac

Re: Proposed doc update for Explicit Reg Vars 3/3

On 10/22/2015 02:10 PM, Jeff Law wrote: As for when the shift occurs to bugfixing, it's usually in early/mid November each year. That also happens the be the deadline for development patches to have been posted for review, hence most folks are busy trying to wrap up their development work. I'

GCC and gender (was Re: 33 unknowns left)

On 08/26/2015 02:50 PM, Eric S. Raymond wrote: About Catherine Moore: One of the things that is quite noticeable about this list is the number of apparently female contributors, which while regrettably small in absolute terms is still rather more than I'm used to seeing in a sample this size.

Re: NIOS and atomic primitives

On 04/18/2015 07:35 PM, Joel Sherrill wrote: Hi with nios2-rtems on gcc 4.9.2, we are getting undefineds for some atomic primitives. Are these implemented or is some magic bit of configurery missing for nios-rtems? __sync_fetch_and_add_4 is missing on a simple C++ IO streams sanity test. libg

Re: Fixing inconsistent uses of address costs

On 03/27/2015 03:43 AM, Kyrill Tkachov wrote: On 27/03/15 03:29, Bin.Cheng wrote: [much snippage] As for tree ivopts, address cost is used in both ways. For any address computation that's invalid, it tries to legitimize it into two parts, the first part results in alu instructions, the second

Re: need help with Pointer Bounds Checking documentation

On 02/25/2015 09:47 AM, Ilya Enkovich wrote: 2015-02-25 19:16 GMT+03:00 Sandra Loosemore : On 02/25/2015 12:56 AM, Ilya Enkovich wrote: 2015-02-24 19:47 GMT+03:00 Sandra Loosemore : Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-* options are listed in c-family

Re: need help with Pointer Bounds Checking documentation

On 02/25/2015 12:56 AM, Ilya Enkovich wrote: 2015-02-24 19:47 GMT+03:00 Sandra Loosemore : Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-* options are listed in c-family/c.opt, but they are not listed in the GCC manual. The section on intrinsics is not enough, by

Re: need help with Pointer Bounds Checking documentation

On 02/24/2015 01:14 AM, Ilya Enkovich wrote: 2015-02-20 19:39 GMT+03:00 Sandra Loosemore : On 02/20/2015 01:12 AM, Ilya Enkovich wrote: 2015-02-20 3:48 GMT+03:00 Sandra Loosemore : The section "Pointer Bounds Checker builtins" in extend.texi is on my list for being in need of co

Re: need help with Pointer Bounds Checking documentation

On 02/20/2015 01:12 AM, Ilya Enkovich wrote: 2015-02-20 3:48 GMT+03:00 Sandra Loosemore : The section "Pointer Bounds Checker builtins" in extend.texi is on my list for being in need of copy-editing, but reading through the existing text, I am quite confused. In several places it

need help with Pointer Bounds Checking documentation

The section "Pointer Bounds Checker builtins" in extend.texi is on my list for being in need of copy-editing, but reading through the existing text, I am quite confused. In several places it refers to turning the Pointer Bounds Checker off, but how do you do that? I don't see any documented c

Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference

On 02/19/2015 03:09 PM, Jakub Jelinek wrote: If you have hw where NULL is mapped and you know your code violates the C/C++ standards by placing objects at that address, simply do use the option that is designed for that purpose. As I pointed out earlier, though, that won't help you if your pro

Re: Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference

Jakub Jelinek wrote: On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote: Starting with gcc 4.9, -O2 implicitly invokes -fisolate-erroneous-paths-dereference: which https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html documents as Detect paths that trigger erroneo

Re: [ping] Re: proper name of i386/x86-64/etc targets

On 01/20/2015 12:21 PM, H.J. Lu wrote: On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore wrote: Ummm, this seems like an inconsistent position. "32-bit x86" isn't even a new name; it's a restricting adjective "32-bit" on the existing name "x86". But

Re: [ping] Re: proper name of i386/x86-64/etc targets

On 01/20/2015 11:40 AM, H.J. Lu wrote: On Tue, Jan 20, 2015 at 10:27 AM, Sandra Loosemore wrote: Since there seems to be arguments against using both "IA-32" and "i386" for the 32-bit x86 architecture, how about, uh, "32-bit x86"? With the other names in par

Re: [ping] Re: proper name of i386/x86-64/etc targets

On 01/20/2015 08:11 AM, Michael Matz wrote: Hi, On Tue, 20 Jan 2015, Uros Bizjak wrote: At least, IA-32 is clear, although IA-64 may be confusing :-). FWIW, i386 is also vendor specific. Wikipedia agrees [1]: I wouldn't use a wikipedia article that only cites sources from after 2008 (and

[ping] Re: proper name of i386/x86-64/etc targets

On 01/01/2015 05:30 PM, Sandra Loosemore wrote: I've noticed that the GCC user documentation is quite inconsistent about the name(s) it uses for i386/x86-64/etc targets. invoke.texi has a section for "i386 and x86-64 Options", but in other places the manual uses x86, X86, i

Re: organization of C Extensions in manual

On 01/17/2015 04:44 PM, David Wohlferd wrote: The page for Extensions to the C Language Family (https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html) is very long (60+ items) and completely unordered. This makes it hard to find things, even when you know they are there. I have taken a first sho

Re: organization of optimization options in manual

On 01/14/2015 11:15 PM, Jeff Law wrote: > On 01/14/15 23:12, Sandra Loosemore wrote: >> I'll see if I can put together a >> plan for splitting things up if there are too many leftovers maybe >> others can help by suggesting different/additional categories. &g

Re: organization of optimization options in manual

On 01/17/2015 11:30 AM, Joel Sherrill wrote: On January 17, 2015 8:34:04 AM CST, Gary Funck wrote: On 01/14/15 23:15:59, Jeff Law wrote: Sounds good. I think just starting with the list & creating the buckets with the list. Then post here and we'll iterate and try to nail that down bef

Re: organization of optimization options in manual

On 01/14/2015 08:41 PM, Jeff Law wrote: With the section being ~60 pages, my first thought is we have way too many options! Heh, at least we have documentation for all those options. :-) But that's not likely to change. Though perhaps the process will encourage some culling of options that

organization of optimization options in manual

The "Options That Control Optimization" section of the manual is currently divided into three parts (not subsections, just separate option lists): (1) General options like -O[n] (2) Options that individually control options enabled by default at some -O[n] setting (3) Options controlling op

output directory for -fvtv-debug and -fvtv-counts

I noticed that the documentation for the -fvtv-* options in invoke.texi needed a little copy-editing and markup correction. I started working on a patch, but I'm stuck on this: The documentation currently says the compile-time log files for these options are written in "the dump file director

Re: testing policy for C/C++ front end changes

On 11/11/2014 02:05 AM, Richard Biener wrote: On Mon, Nov 10, 2014 at 4:28 PM, Sandra Loosemore wrote: On 11/10/2014 05:03 AM, Richard Biener wrote: On Mon, Nov 10, 2014 at 5:50 AM, Jeff Law wrote: On 11/09/14 16:13, Sandra Loosemore wrote: https://gcc.gnu.org/contribute.html#testing

Re: testing policy for C/C++ front end changes

On 11/10/2014 05:03 AM, Richard Biener wrote: On Mon, Nov 10, 2014 at 5:50 AM, Jeff Law wrote: On 11/09/14 16:13, Sandra Loosemore wrote: https://gcc.gnu.org/contribute.html#testing and noticed that the policy is to require a complete bootstrap for C changes, but not for C++. Given that

testing policy for C/C++ front end changes

Forgive me if this has been raised before -- I tried searching the archives but couldn't think of good keywords that would weed out unrelated posts I was checking the testing requirements for a C front end patch https://gcc.gnu.org/contribute.html#testing and noticed that the policy is to

PowerPC builds broken on 4.9 and trunk

as reported in PR60102. I'd really hope this could be fixed for 4.9.1 but I'm not sure the relevant people are paying much attention to the issue. Can we at least update the priority/severity of the bug so that it's more likely to show up on the radar? I did look at trying to fix this my

Re: gcc 4.7.3 plans?

On 03/18/2013 03:03 AM, Richard Biener wrote: On Sat, Mar 16, 2013 at 10:24 AM, xunxun wrote: 于 2013/1/29 星期二 19:24, Richard Biener 写道: There will be a 4.7.3 release (shortly) before 4.8.0 releases. There is quite a number of regression fixes that are suitable for backporting to the 4.7 bran

Re: LTO multiple definition failures

On 01/02/2012 12:22 AM, Andi Kleen wrote: Sandra Loosemore writes: I'm still finding my way around LTO; can anyone who's more familiar with this help narrow down where to look for the cause of this? I don't even know if this is a compiler or ld bug at this point. I'm I

LTO multiple definition failures

I've been investigating some LTO-related test failures in a GCC port for a DSP target that has not yet been submitted to the FSF. The bug I've hit looks like the same issue with spurious multiple definitions that was previously reported on the gcc-help list: http://gcc.gnu.org/ml/gcc-help/201

Re: IRA vs CANNOT_CHANGE_MODE_CLASS, + 4.7 IRA regressions?

On 07/29/2011 12:13 PM, Vladimir Makarov wrote: On 07/27/2011 05:59 PM, Sandra Loosemore wrote: [snip] So, here's my question. Is it worthwhile for me to continue this approach of trying to make the MIPS backend smarter? Or is the way IRA deals with CANNOT_CHANGE_MODE_CLASS fundamen

Re: IRA vs CANNOT_CHANGE_MODE_CLASS, + 4.7 IRA regressions?

On 07/28/2011 02:11 AM, Richard Guenther wrote: On Wed, Jul 27, 2011 at 11:59 PM, Sandra Loosemore wrote: [snip] So, here's my question. Is it worthwhile for me to continue this approach of trying to make the MIPS backend smarter? Or is the way IRA deals with CANNOT_CHANGE_MODE_

IRA vs CANNOT_CHANGE_MODE_CLASS, + 4.7 IRA regressions?

Consider this bit of code: extern double a[20]; double test1 (int n) { double accum = 0.0; int i; for (i=0; imipsisa32r2-sde-elf-gcc -O3 -fno-inline -fno-unroll-loops -march=74kf1_1 -S abstest.c With a GCC 4.6 compiler, this produces: ... .L3: mtc1$3,$f2 ldc1$f0

Re: Coding conventions -- command line option vs command-line option

Joseph S. Myers wrote: On Mon, 17 Sep 2007, Gerald Pfeifer wrote: And now to the most important issue of all to address before we can release GCC 4.3.0. ;-) In our current documentation we have both "command-line option" and "command line option". Like other such cases, we should make a choic

Re: Bootstrap broken: ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN'

Christian Joensson wrote: Using checkout Thu Sep 6 05:56:16 UTC 2007 (revision 128174), I get a bootstrap failure: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada -I../

Re: ICE building libgcc2.c for MIPS, too

Ian Lance Taylor wrote: Sandra Loosemore <[EMAIL PROTECTED]> writes: I'm now at revision 126547, and am getting a different ICE when building the same configuration: /scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale.cc: In member function 'std::st

Re: ICE building libgcc2.c for MIPS, too

Ian Lance Taylor wrote: Sandra Loosemore <[EMAIL PROTECTED]> writes: The error reported here http://gcc.gnu.org/ml/gcc/2007-07/msg00339.html is also happening when building for target mipsisa32r2-elfoabi on i686-pc-linux-gnu. This should be fixed by revision 126536. Sorry f

ICE building libgcc2.c for MIPS, too

The error reported here http://gcc.gnu.org/ml/gcc/2007-07/msg00339.html is also happening when building for target mipsisa32r2-elfoabi on i686-pc-linux-gnu. -Sandra

Re: Bootstrap is broken on x86_64, comparison between signed and unsigned in optabs.c

2-gcc] Error 2 gmake[2]: Leaving directory `/home/uros/gcc-build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/home/uros/gcc-build' gmake: *** [all] Error 2 It must be very recent change. Broken by: 2007-07-05 Sandra Loosemore <[EMAIL PROTECTED]> David Ung <

Re: Question about LTO dwarf reader vs. artificial variables and formal arguments

Steven Bosscher wrote: I want to make gfortran produce better debug information, but I want to do it in a way that doesn't make it hard/impossible to read back in sufficient information for LTO to work for gfortran. I haven't really been following the whole LTO thing much, but if I understan

Re: GCC 4.3 project to merge representation changes

Mark Mitchell wrote: I don't believe there is a GCC 4.3 project page to merge the work that you folks did on CALL_EXPRs and TYPE_ARG_TYPEs. Would one of you please create a Wiki page for that? There are already a bunch of notes about this on the LTO page: http://gcc.gnu.org/wiki/LinkTimeOp

Re: representation of struct field offsets

Mark Mitchell wrote: Are you going through the stor_layout.c:place_field routines when creating structure types? If so, I wouldn't; here, you know where stuff is supposed to go, so I would just put it there, and set DECL_FIELD_OFFSET, etc., accordingly. No, I'm not using the fancy stor_lay

representation of struct field offsets

I've been having a heck of a time figuring out how to translate the offsets for struct fields from the DWARF encoding back to GCC's internal encoding for the LTO project. I've got a handle on the DWARF encoding and how to do the necessary big/little endian conversions, but for the GCC side, the