Re: Pending bugs for GNU
On Saturday 14 January 2006 02:18, Alfred M. Szmidt wrote: > But this seems very awkward for people who only send a patch ones in a > blue moon; Why? There are lots of people who only send a few patches per year and they all know how to contribute them. > and not much good info on that either, the manual just says > `report bugs to the bugtracker'; more or less. Not true. For developers we have other quite extensive documentation in the gcc internals manual and on various web pages that tell you the procedures and expectations when you want to contribute a patch. Those few users who want to help developing gcc can find links to that documentation in the chapter "Contributing to GCC development" in the users manual. It seems you overlooked that chapter. Gr. Steven
Re: Pending bugs for GNU
Please read the web page: http://gcc.gnu.org/contribute.html This assumes a stable access to the 'net so that such information can be extracted when one is reading the documentation. Which isn't always the case for everyone. URL's shouldn't point to important information of this type in a info manual. Is there any way to get it included directly?
Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
> make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java > Wow, that's awkward. I understand, but I have a patch to make it easier. Patches for the toplevel take a long time to review, and I cannot handle posting too many patches and tracking them. Not even two patches. Currently I have a pending patch at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00473.html that I would have liked to be in 4.1 too, so I am not sending out the changes that I have in my tree to make this easier. However, the patch is not very twisty, and reviewing does not require thorough knowledge of cross compilation for example. You are a GWP, so you could help. A previous version of the patch is at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00404.html but I've withdrawn it because I could make it even more similar to the old scheme. If you want to review the newer version, I'll send it on monday and CC you. Same goes for the documentation updates. > Remind me why it's a good idea to force me to mess with bootstrapping > at all, when all I want is to build a copy of the compiler that I can > use for debugging problems? First, because "make stage1-bubble" above only takes as much time as a non-bootstrapped build. Is the command line harder than "make all-gcc; make -C gcc cc1plus f951 jc1"? Maybe, but after the patch I mentioned above it will be the same as before toplevel bootstrap. Second, because the toplevel bootstrap did fix bugs. For example, the inability to bootstrap a 64-bit compiler with a 32-bit compiler (because libiberty was not built as a 64-bit binary) -- this requires a five line patch that was posted by Richard Guenther but has not been reviewed yet, either. Or the binary compatibility problems when the compilation platform had a 4-byte bool. From the *user* point of view this is surely a progression. Third, because nobody said it was a bad idea in the 16 months between the first (not the only) call for testing and the definitive enabling of toplevel bootstrap. Fourth, because toplevel bootstrap is a prerequisite for many further cleanups and improvements, including moving libgcc to the toplevel and bootstrapping libada. Eric Botcazou wrote: > Glad to see that a GWP maintainer eventually speaks up. :-) Well, Kenner is also GWP. Still, it remains to be seen why the other did not speak up. I am the first person that would like to know it. > FWIW I personally think this toplevel bootstrap thing is a step backward, now > typing "make" triggers such a complex machinery that nobody seems to able to > understand what it does. So the previous system was easy? IMO it's just that it's been tested for 15 years. Personally it took me a lot of time to understand the working of bubblestrap, stage*_copy, stage*_build, and so on The point is that you have to decide in advance if the toplevel will bootstrap. If you use --disable-bootstrap, it will not. --disable-bootstrap will *not* disappear; rather, "../configure --disable-bootstrap && make bootstrap", which currently triggers the old-style GCC-only bootstrap, will disappear. What I usually do, is developing in a --disable-bootstrap tree, and when I'm reasonably sure, start a fresh bootstrap (because I have a script that also does the comparison with a baseline run, and I let it run overnight). In more complex cases, like debugging a miscompilation or otherwise failing bootstrap, I debug in a tree configured for bootstrap. Paolo
Re: Pending bugs for GNU
Alfred M. Szmidt <[EMAIL PROTECTED]> wrote: >Please read the web page: >http://gcc.gnu.org/contribute.html > > This assumes a stable access to the 'net so that such information can > be extracted when one is reading the documentation. Which isn't > always the case for everyone. URL's shouldn't point to important > information of this type in a info manual. Is there any way to get it > included directly? Yes, contribute a patch using the instructions at: http://gcc.gnu.org/contribute.html Giovanni Bajo
BIGGEST_ALIGNMENT on AIX 32-bit
Hi,
Its current setting is 128. It originally had been 64 and was bumped to 128
in 2001 when Altivec support was added; yet:
aix.h:
/* AIX does not support Altivec. */
#undef TARGET_ALTIVEC
#define TARGET_ALTIVEC 0
#undef TARGET_ALTIVEC_ABI
#define TARGET_ALTIVEC_ABI 0
That's problematic (in particular for Ada) because nothing is 128-bit aligned
on AIX 32-bit. The stack is not:
rs6000.h:
/* Boundary (in *bits*) on which stack pointer should be aligned. */
#define STACK_BOUNDARY \
((TARGET_32BIT && !TARGET_ALTIVEC && !TARGET_ALTIVEC_ABI) ? 64 : 128)
The sections are not either:
xcoff.h:
/* Output before writable data.
Align entire section to BIGGEST_ALIGNMENT. */
#define DATA_SECTION_ASM_OP "\t.csect .data[RW],3"
rs6000.c:
/* A get_unnamed_decl callback, used for read-only sections. PTR
points to the section string variable. */
static void
rs6000_xcoff_output_readonly_section_asm_op (const void *directive)
{
fprintf (asm_out_file, "\t.csect %s[RO],3\n",
*(const char *const *) directive);
}
/* Likewise for read-write sections. */
static void
rs6000_xcoff_output_readwrite_section_asm_op (const void *directive)
{
fprintf (asm_out_file, "\t.csect %s[RW],3\n",
*(const char *const *) directive);
}
As a result, the Ada compiler cannot pass the ACATS testsuite on AIX 32-bit.
We therefore are proposing to revert to the pre-Altivec setting.
--
Eric Botcazou
Re: BIGGEST_ALIGNMENT on AIX 32-bit
> Eric Botcazou writes: Eric> That's problematic (in particular for Ada) because nothing is 128-bit aligned Eric> on AIX 32-bit. AIX does support Altivec. David
Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
> So the previous system was easy? IMO it's just that it's been tested for > 15 years. Personally it took me a lot of time to understand the working of > bubblestrap, stage*_copy, stage*_build, and so on The previous "make" was easy. Now even "make" is too much intricate for common mortals. > The point is that you have to decide in advance if the toplevel will > bootstrap. If you use --disable-bootstrap, it will not. I know, I exclusively use that nowadays. :-) > --disable-bootstrap will *not* disappear;rather, "../configure > --disable-bootstrap && make bootstrap", which currently triggers the > old-style GCC-only bootstrap, will disappear. That's good news and actually sufficient to allay most of my concerns. And you can count on me to yell if --disable-bootstrap breaks. :-) -- Eric Botcazou
R: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
> > So the previous system was easy? IMO it's just that it's been tested for > > 15 years. Personally it took me a lot of time to understand the working of > > bubblestrap, stage*_copy, stage*_build, and so on > > The previous "make" was easy. Now even "make" is too much intricate for > common mortals. Despite all the strange things that it appears to do, "make" is equivalent to $ make stage3-bubble $ make all-host all-target Except that host tools (fastjar mostly) are made with the *new* GCC rather than the old one. "stage3-bubble" is a bubblestrap... the name is not more awkward than the old one, and with the advantage that you also have "stage2-bubble" and so on. > > The point is that you have to decide in advance if the toplevel will > > bootstrap. If you use --disable-bootstrap, it will not. > > I know, I exclusively use that nowadays. :-) I don't mind, with the sole advice to try *not using* "../configure --disable-bootstrap && make bootstrap". Everything else will remain as is, or improved (in the sense that backwards-compatibility will increase). After I get the famous patch in, you'll find out that most of the time, this rule of thumb applies: 1) in the toplevel directory, you can work like in the past 2) in the gcc directory (which, almost always, will be the stage1 gcc directory while developing), plain "make" or "make cc1" will do. No more, really no more "make restage1", "make bubblestrap" and other strange targets. Right now, the main difference with the old system is that without specifying STAGE1_LANGUAGES, you cannot build unoptimized C++ and Fortran and Java front-ends. I agree that it can be awkward; I probably never found that because I rarely work on the front-ends. > > --disable-bootstrap will *not* disappear;rather, "../configure > > --disable-bootstrap && make bootstrap", which currently triggers the > > old-style GCC-only bootstrap, will disappear. > > That's good news and actually sufficient to allay most of my concerns. And > you can count on me to yell if --disable-bootstrap breaks. :-) Of course. I think it would be quite insane to *mandate* a bootstrap. Jason's concern in this respect is more than understood. My apologies if this was not made clear enough. Paolo
Re: BIGGEST_ALIGNMENT on AIX 32-bit
> AIX does support Altivec. Great, but not GCC as far as I can see: [EMAIL PROTECTED]:~/build/gcc/powerpc-ibm-aix5.3> gcc/xgcc -Bgcc -E -dM t.h -maltivec | grep __ALTIVEC__ [EMAIL PROTECTED]:~/build/gcc/powerpc-ibm-aix5.3> So why not revert to the original BIGGEST_ALIGNMENT setting until Altivec is supported? That would be more in keeping with all the other settings on AIX. -- Eric Botcazou
Re: BIGGEST_ALIGNMENT on AIX 32-bit
> Eric Botcazou writes: Eric> So why not revert to the original BIGGEST_ALIGNMENT setting until Altivec is Eric> supported? That would be more in keeping with all the other settings on AIX. And how does that solve the problem when Altivec is "supported"? This just covers up problem, doesn't fix it. David
Re: BIGGEST_ALIGNMENT on AIX 32-bit
> And how does that solve the problem when Altivec is "supported"? Let's first fix existing problems. :-) But a partial solution could be to make BIGGEST_ALIGNMENT depend on TARGET_ALTIVEC_ABI and later set TARGET_ALTIVEC_ABI unconditionally to 1 when Altivec support is added: #define BIGGEST_ALIGNMENT ((TARGET_32BIT && !TARGET_ALTIVEC_ABI) ? 64 : 128) That would actually be sufficient for Ada, as the biggest problem is the STACK_BOUNDARY vs BIGGEST_ALIGNMENT discrepancy. The Ada compiler does not run into the problem I talked about in my original message on Darwin because TARGET_ALTIVEC_ABI is set to 1 there, so STACK_BOUNDARY == BIGGEST_ALIGNMENT. -- Eric Botcazou
Re: R: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
Except that host tools (fastjar mostly) are made with the *new* GCC rather than the old one. And the reason is what? I don't see even any theoretical merit in the whole staging thing: 1. Bugs can theoretically cancel them self out. 2. The compiler isn't stressing himself more then the target library stuff, which gets build anyway. 3. Why on earth should I insist to work with s self compiled gcc, when the native compiler is generating better and faster code? 4. Release builds for platforms are self hosted anyway so what? 5. For the case of cross compilation the whole reasoning behind it falls apart like a home build from cards. But there is one thing i see for certain: It takes insane amounts of time, since the compiler is usually building itself with the EXTRA SLOW version of itself containing runtime assertions. And thus: 6. Longer build cycles (in esp. when overlapping with the sleep cycle) result in less productive time and thus likely *less* actual functional testing of the resulting compiler when focusing on a particular single property of it - which is the working mode of 99% of the people here I assume. Testing the resulting compiler has already a name: make test Everything else is just adding to confusion.
Re: BIGGEST_ALIGNMENT on AIX 32-bit
Why isn't this bug an incorrect use of BIGGEST_ALIGNMENT somewhere in the compiler? David
Re: BIGGEST_ALIGNMENT on AIX 32-bit
The conflict is actually 32bit, AIX, Altivec, and Ada (together). So, how about for now, just say that Ada can't support Altivec on 32bit AIX. My point is that I'd like to keep Altivec support on 32bit AIX for other languages. On Jan 14, 2006, at 9:03 AM, Eric Botcazou wrote: And how does that solve the problem when Altivec is "supported"? Let's first fix existing problems. :-) But a partial solution could be to make BIGGEST_ALIGNMENT depend on TARGET_ALTIVEC_ABI and later set TARGET_ALTIVEC_ABI unconditionally to 1 when Altivec support is added: #define BIGGEST_ALIGNMENT ((TARGET_32BIT && !TARGET_ALTIVEC_ABI) ? 64 : 128) That would actually be sufficient for Ada, as the biggest problem is the STACK_BOUNDARY vs BIGGEST_ALIGNMENT discrepancy. The Ada compiler does not run into the problem I talked about in my original message on Darwin because TARGET_ALTIVEC_ABI is set to 1 there, so STACK_BOUNDARY == BIGGEST_ALIGNMENT. -- Eric Botcazou
Re: BIGGEST_ALIGNMENT on AIX 32-bit
Perry Smith wrote: The conflict is actually 32bit, AIX, Altivec, and Ada (together). So, how about for now, just say that Ada can't support Altivec on 32bit AIX. My point is that I'd like to keep Altivec support on 32bit AIX for other languages. I am confused, how can Altivec be properly supported if the stack does not have sufficient alignment.
Re: Command line options and pragmas
DJ Delorie wrote: For example, if you have two warnings in one statement, you can't control one but not the other if they use the same -W option. A minor point, but if we used line numbers we'd be really close to "this should work" that people would claim it's a bug when it doesn't. Seems rather marginal to worry about this. Surely this is letting best be the enemy of good. And as for it being a bug, that's just a matter of clear documentation. Plus, we'd need to keep track of a linked list of flag state structures. Sounds doable ... Some folks made convincing arguments that it wouldn't always work the way the user wanted, too. We don't always have a line number, for example. Which warning state takes effect? When we have a "first used here" type diagnostic, which warning state is used? Well the warning is going to be issued at some source location in any case, so the answer is that the suppression or control has to apply to that location. But I'm willing to implement something if people think it's the best thing to do.
Re: BIGGEST_ALIGNMENT on AIX 32-bit
> Why isn't this bug an incorrect use of BIGGEST_ALIGNMENT somewhere > in the compiler? Because you must have BIGGEST_ALIGNMENT <= STACK_BOUNDARY (or PREFERRED_STACK_BOUNDARY) in order to be able to allocate objects with BIGGEST_ALIGNMENT on the stack. Otherwise the offsets are not sufficiently rounded, even if the stack register is aligned on BIGGEST_ALIGNMENT on function entry. -- Eric Botcazou
Re: BIGGEST_ALIGNMENT on AIX 32-bit
> The conflict is actually 32bit, AIX, Altivec, and Ada (together). Not quite. > My point is that I'd like to keep Altivec support on 32bit AIX for > other languages. Well, GCC has *no* Altivec support on AIX. -- Eric Botcazou
Re: BIGGEST_ALIGNMENT on AIX 32-bit
> > > Why isn't this bug an incorrect use of BIGGEST_ALIGNMENT somewhere > > in the compiler? > > Because you must have BIGGEST_ALIGNMENT <= STACK_BOUNDARY (or > PREFERRED_STACK_BOUNDARY) in order to be able to allocate objects with > BIGGEST_ALIGNMENT on the stack. Otherwise the offsets are not sufficiently > rounded, even if the stack register is aligned on BIGGEST_ALIGNMENT on > function entry. Huh? Where is this requirement documented because I don't see it at all in tm.texi? Also what is Ada using BIGGEST_ALIGNMENT for, that just seems wrong. Thanks, Andrew Pinski
Re: BIGGEST_ALIGNMENT on AIX 32-bit
> Huh? Where is this requirement documented because I don't see it at all > in tm.texi? It's a logical consequence of the code in assign_stack_local_1. > Also what is Ada using BIGGEST_ALIGNMENT for, that just seems > wrong. Well, the manual reads: -- Macro: BIGGEST_ALIGNMENT Biggest alignment that any data type can require on this machine, in bits. My reading is that a local variable is entitled to require BIGGEST_ALIGNMENT. -- Eric Botcazou
Re: BIGGEST_ALIGNMENT on AIX 32-bit
Andrew Pinski wrote: Huh? Where is this requirement documented because I don't see it at all in tm.texi? Also what is Ada using BIGGEST_ALIGNMENT for, that just seems wrong. Ada uses BIGGEST_ALIGNMENT as the largest value that can be specified for alignment of a type (which seems a reasonable use, no?) Thanks, Andrew Pinski
Re: BIGGEST_ALIGNMENT on AIX 32-bit
On Jan 14, 2006, at 10:19 AM, Robert Dewar wrote: Perry Smith wrote: The conflict is actually 32bit, AIX, Altivec, and Ada (together). So, how about for now, just say that Ada can't support Altivec on 32bit AIX. My point is that I'd like to keep Altivec support on 32bit AIX for other languages. I am confused, how can Altivec be properly supported if the stack does not have sufficient alignment. Couldn't (and shouldn't) the start sequence in crt0 align the stack? It seems someone somewhere has to do that eventually anyway. I would not assume the OS is going to cooperate.
gcc-4.2-20060114 is now available
Snapshot gcc-4.2-20060114 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060114/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 109704 You'll find: gcc-4.2-20060114.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060114.tar.bz2 C front end and core compiler gcc-ada-4.2-20060114.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060114.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060114.tar.bz2 C++ front end and runtime gcc-java-4.2-20060114.tar.bz2 Java front end and runtime gcc-objc-4.2-20060114.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060114.tar.bz2The GCC testsuite Diffs from 4.2-20060107 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
stab strings on AIX
I have a tool that I use to look at AIX dumps. It understands stab strings that xlc (the IBM compiler) produces. I feed it a file produced by gcc/g++ and it complains. The same thing happens with dbx (IBM's debugger). Of course, gdb understands it fine. Has gcc/g++ extended the stab strings or is my tool (and dbx) just incomplete? If there has been an extension to the stab strings, can someone point me to where it is documented (even if it is in the source). I *thought* I had a complete implementation as documented in the AIX pubs but they may be incomplete. So, another possibility is maybe I just need a pointer to the complete stab string specification. Thank you, Perry
Re: BIGGEST_ALIGNMENT on AIX 32-bit
> Couldn't (and shouldn't) the start sequence in crt0 align the stack? > It seems someone somewhere has to do that eventually anyway. I would > not assume the OS is going to cooperate. Yes, but that's not sufficient. The compiler must align local objects too. -- Eric Botcazou
Re: stab strings on AIX
> Perry Smith writes: Perry> I have a tool that I use to look at AIX dumps. It understands stab Perry> strings that xlc (the IBM compiler) produces. I feed it a file Perry> produced by gcc/g++ and it complains. The same thing happens with Perry> dbx (IBM's debugger). Of course, gdb understands it fine. Perry> Has gcc/g++ extended the stab strings or is my tool (and dbx) just Perry> incomplete? If there has been an extension to the stab strings, can Perry> someone point me to where it is documented (even if it is in the Perry> source). I *thought* I had a complete implementation as documented Perry> in the AIX pubs but they may be incomplete. So, another possibility Perry> is maybe I just need a pointer to the complete stab string Perry> specification. Yes, GCC produces extended stabx debugging information by default. See the "Options for Debugging Your Program" in the GCC manual, specifically the -gxcoff and -gxcoff+ options. GCC generates -gxcoff+ by default when "-g" commandline optio is used. If you want the subset that works with AIX tools, explicitly use -gxcoff. David
_Pragma3.c failure on gcc 4.1 branch for darwin 8.4.0
I am seeing a new failure in the gcc testsuite for the gcc 4.1 branch built on MacOS X 10.4.4... Running /sw/src/fink.build/gcc4-4.1.0-20060114/gcc-4.1-20060114/gcc/testsuite/gcc.dg/cpp/cpp.exp ... FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors) Is this expected? None of the other architectures seem to be showing this and no one is posting test results for the 4.1 branch on MacOS X these days. Jack
Re: Command line options and pragmas
> Seems rather marginal to worry about this. Surely this is letting > best be the enemy of good. I agree. I was only noting the objections last time I suggested something like this. > And as for it being a bug, that's just a matter of clear > documentation. The problem was that you *can't* have clear documentation, because it often depends on how the optimizer mucks with the code. If was can accept docs that say "it mostly works like this, but sometimes it does other interesting things instead, and it might change from release to release", then the task becomes significantly easier.
collect2 possible enhancements
I have a number of things that I would like to see added to collect2. If there is interest in them, I'll volunteer to do the work. I am not sure of the process of making suggestions like this so if there is another format, please let me know. Changes to collect2: 1) Added the ability for collect2 to stop after the creation of the .c file which also implies an option to give the .c file a name. Maybe: --c-file-only=foo.c 2) Same as #1 but with the object file. Maybe: --o-file-only=foo.o 3) Right now collect2 looks at suffixes. It would be nice to do one or both of the following two things: 3a) An option to add suffixes used for object files. Maybe: --object-suffix=.32o to add the .32o suffix. 3b) Look at the magic number in the files to determine if they are an object file that needs to be looked at. This could be an option. The pitfall is that on AIX, an archive can have 32 bit object files and 64 bit object files and the linker pulls out the ones it needs. The way this is done usually is to have foo.c compile to foo.32o and foo.64o and then put all the object files into one archive. gcc instead has path/libxxx.a and path/ppc64/libxxx.a If the only difference is the 32/64 bitness, those could be combined. This is what old farts like me are use to. This system confuses collect2 in two places. If I do g++ foo.32o -o foo, collect2 never looks at foo.32o for constructors and destructors (or frame tables). The trick I did was to put my object files into an archive and then collect2 scans them. I am building a driver which means I need it in 32 bit form as well as 64 bit form. I assume if I had both my 32 bit object files and my 64 bit object files in the same archive, collect2 would scan all of them which is not the right thing to have happen. collect2 could look at the magic numbers and resolve both of these short comings. (collect2 knows if it is in 32 bit mode or in 64 bit mode.) 4) collect2 on AIX has two arguments that it passes to ld that can not be removed. I'm wondering if those should be added in only if - nostdlib is not specified (or some other way to accomplish the same task). There may be other flags to ld like this as well but I don't think so. Right now, to get around this problem I have a script called ld in my path before the real ld and the script strips out the two arguments that I don't want. Thank you, Perry Smith btw Thank you to David, Ian, Gabby, and others. I now have a tiny driver that loads. It has a constructor and destructor for a global object (which gets called). It throws an exception (on purpose) and the exception is caught. The malloc and frees match up. Everything looks good. I can finally move on to actually writing a device driver...!!! Yippie!!!
Re: Command line options and pragmas
DJ Delorie wrote: Seems rather marginal to worry about this. Surely this is letting best be the enemy of good. I agree. I was only noting the objections last time I suggested something like this. And as for it being a bug, that's just a matter of clear documentation. The problem was that you *can't* have clear documentation, because it often depends on how the optimizer mucks with the code. I guess I don't see this, whether the warning is issued might depend on this, but I don't see that the suppression mechanism would be accpted. If was can accept docs that say "it mostly works like this, but sometimes it does other interesting things instead, and it might change from release to release", then the task becomes significantly easier.
Re: _Pragma3.c failure on gcc 4.1 branch for darwin 8.4.0
On Sat, 14 Jan 2006, Jack Howarth wrote: > FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors) This probably means your timestamps are out of order. Run contrib/gcc_update --touch to fix them. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: svn access on RHEL 4.0
On Jan 8, 2006, at 7:19 PM, Daniel Berlin wrote: On Sun, 2006-01-08 at 18:05 -0600, Bradley Lucier wrote: OK, here are some details. Our server is a dual UltraSparc running Solaris 10 attached to the SAN. Working client situation: subversion 1.3.0 on Sparc Solaris 9, not using Berkeley DB Non-working client situation: subversion 1.3.0 on x86-64 RHEL 4.0, using Berkeley DB I think everything is running NFSv4 at this point. Unless you are running a server locally, whether you've compiled in BDB or not doesn't matter. Thank you all for your suggestions. I think we've isolated the problem enough to hand it off to someone else, since we have hardware and OS software support on all the machines involved. File server: dual ultrasparc running Solaris 10, serves the file system using either NFSv3 or NFSv4. Operation: svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc; cd gcc; contrib/ gcc_update Results: File system mounted as NFSv3 or NFSv4 on dual ultrasparc running Solaris 9: works File system mounted as NFSv3 on RHEL 4: works File system mounted as NFSv4 on RHEL 4: reports seeming file system corruption. This is reproducible, so perhaps someone can find a fix for it. Thanks again. Brad
Re: R: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
Marcin Dalecki <[EMAIL PROTECTED]> writes: | Testing the resulting compiler has already a name: | | make test That does not test the compiler on building the runtime. There are a number of times where people reported runtime buik failures after front-end changes. So, I don't think your statement is accurate. -- Gaby
AIX cross compile environment on the Mac
Now that I have (or think I have) my compiler and library problems solved, I'm toying with the idea of creating a cross compile environment on my Mac laptop for AIX (RS/6000). Does anyone see any obstacles with this? I've never done a cross compile before. Thank you, Perry Smith
Re: AIX cross compile environment on the Mac
> Perry Smith writes: Perry> Now that I have (or think I have) my compiler and library problems Perry> solved, I'm toying with the idea of creating a cross compile Perry> environment on my Mac laptop for AIX (RS/6000). Does anyone see any Perry> obstacles with this? I've never done a cross compile before. Cross-compiler will work. Cross-assembler and cross-linker and the rest of the GNU tools will not work correctly for AIX 5L. David
Re: [PATCH] Re: conversion warnings in c++
On Fri, 13 Jan 2006, Eric Christopher wrote: | | > | OK? | > | > yes. | > | > | Did you want me to add this as a testcase? | > | > yes -- so that we don't regress. | | Ok. apparently I tested in the wrong directory and we already have a | few testcases that test whether we're emitting warnings. I've cleaned | up the testsuite (and added a quick patch to cvt.c to add another | check on OPT_Wconversion), but I'll ask for approval again, because | it's quite a few changes. | | So, this ok or would you like me to leave some of the warnings there? | None of them are pedwarns so I'm assuming (based on a quick look | through the standard) that they aren't necessary and can be | conditionalized, but I wanted to double check. Hi Eric, The overall patch is OK. Please could add testcases that test -Wno-conversion? Thanks for doing this. -- Gaby
Storage for uninitialized objects (PR 24626)
I have a question about storage for uninitialized objects. I made the mistake of looking at the code being generated for testcase #2 in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626. I noticed that reload used the same register r3 for the variables "call_result" and "node" after the call to after_node_func (). This appears to occur because "node" is an uninitialized variable. It seems to me that automatic variables with similar storage duration should be allocated different storage. This would ensure that the same value of "node" is passed in the calls to after_node_func and T. With the current code, different values might be passed, and T could detect the difference in values in a way that doesn't invoke undefined behavior. Am I wrong about this? The main reason I'm concerned about this is that there have been quite a few optimization issues in GCC 4.0 that have been difficult to debug on the PA-RISC port. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: Storage for uninitialized objects (PR 24626)
"John David Anglin" <[EMAIL PROTECTED]> writes: > I have a question about storage for uninitialized objects. > > I made the mistake of looking at the code being generated for > testcase #2 in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626. > I noticed that reload used the same register r3 for the variables > "call_result" and "node" after the call to after_node_func (). > This appears to occur because "node" is an uninitialized variable. > > It seems to me that automatic variables with similar storage > duration should be allocated different storage. This would ensure > that the same value of "node" is passed in the calls to after_node_func > and T. With the current code, different values might be passed, and T > could detect the difference in values in a way that doesn't invoke > undefined behavior. > > Am I wrong about this? The main reason I'm concerned about this > is that there have been quite a few optimization issues in GCC 4.0 > that have been difficult to debug on the PA-RISC port. gcc assumes that if a variable is uninitialized, it can use any value whatsoever for any use of the variable. gcc does not assume that all uses of an uninitialized variable must have the same value. It is of course possible to write a correct program which uses an uninitialized variable. However, I believe that such a program must never examine the variable in any way whatsoever, so I don't agree that it is possible to detect the difference in values. Even comparing the uninitialized variable to itself is undefined behaviour. Given that, I think that gcc's current approach will generate the most efficient code for correct programs which have uninitialized variables. Ian
