Re: Adding support for demangling MSVC symbols to libiberty
Has this been considered in the past, but rejected for some reason? Don't see why it would. Could be useful. Should I have posted this to a different GCC list? :P This is fine. -eric
stability of libgomp and libssp
We're thinking of including these libraries in the next version of OS X on the system so that 4.2 will work out of the box when either a) it is released, or b) leopard is released, whichever happens last. Since we need to keep abis stable, I was wondering if anyone planned on changing abi or if we can depend on all changes not breaking the abi of these libraries? Thoughts? Comments? Plans? Assurances? -eric
Re: stability of libgomp and libssp
On Oct 19, 2006, at 2:50 PM, Diego Novillo wrote: Eric Christopher wrote on 10/19/06 17:33: I was wondering if anyone planned on changing abi or if we can depend on all changes not breaking the abi of these libraries? There is nothing planned in that area, but I wouldn't want to guarantee ABI stability. Mostly as a result of bug fixing. Since this will be the first official release, I expect several bugs that may introduce ABI problems. OK. Unless you can use some kind of versioning, I don't see a good way to address this. And as discussed on irc symbol versioning won't quite solve the problem anyhow. :) thanks. -eric
Re: GMP test
On Oct 23, 2006, at 4:15 PM, Paolo Bonzini wrote:
if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi
but I think that the whole test now belongs in the GCC
subdirectory, not in the toplevel (it was anyway a hack for the
sake of disabling Fortran).
Moving it is not really a good thing anyways as you are able to
configure
and then do a "make -j3" and it is hard to figure out why the build
fail
because you don't have the correct version of GMP/MPRF.
Maintainability first. If something fails with parallel make, and
is reproducible with plain "make" (i.e. doesn't screw up the build
directory), I don't see a reason not to move it. You'd do "make"
anyway to check if a dependency is missing, wouldn't you?
Really, all I care about is having it depend on the languages enabled.
It's driving me crazy at the moment on a non-fortran build.
-eric
Re: GMP test
Maintainability first. If something fails with parallel make, and is reproducible with plain "make" (i.e. doesn't screw up the build directory), I don't see a reason not to move it. You'd do "make" anyway to check if a dependency is missing, wouldn't you? Really, all I care about is having it depend on the languages enabled. It's driving me crazy at the moment on a non-fortran build. As was pointed out, gmp/mpfr are now used in the default code path. This is causing systems with multiple sets of libraries installed, or optional libraries installed in odd paths (/opt/local) to start overriding others. Right now, for example there are two sets of libiconv found on my system. Configure finds one set in /usr/lib, but the -L added for gmp when I set it to /opt/local finds gnu libiconv off in /opt/local which really isn't the desired result. Of course, I can work around this using --with-libiconv-prefix, but my configure line is starting to look a bit long... At some point the configury should agree on how to find optional libraries. I don't mind picking either the system or the ones in .../ some-prefix, but it should be consistent in how it looks for libraries and headers. Thoughts? -eric
Re: build failure, GMP not available
I ended up including both your preference and mine. Hopefully one or other other (or both) end up being useful to users. Thanks, this will help with some of the questions I received internally today. -eric
Re: Problem with listing i686-apple-darwin as a Primary Platform
Right now after patches by the Apple folks causes you to need a newer dwarfutils which don't exist outside of Apple so the community of Free Source and GCC is not helped by making Darwin a primary platform. Maybe we should list a specific version of darwin which changes the confusion of which darwin (Mac OS X) version is supposed to be able to compile right out of the box. Right now on the PowerPC side, Darwin before 8 (so Panther and before) are broken bootstrapping the mainline and is also broken on the 4.2 branch. We're in stage1, breakages happen - see the current fun with gmp/mpfr as well as c99 inlining. File a bug or bring a problem up for discussion. As far as 4.2 this is the first I've heard of it. What's the problem? -eric
Re: Problem with listing i686-apple-darwin as a Primary Platform
On Nov 6, 2006, at 8:59 PM, Andrew Pinski wrote: On Mon, 2006-11-06 at 20:57 -0800, Eric Christopher wrote: As far as 4.2 this is the first I've heard of it. What's the problem? Well you need a new cctools which does not exist for 10.2. While I'm sure you could be less specific, would you be more specific in this case? And, no offense, but 10.2 is quite old, I'm not sure that Apple is even supporting it these days, but I'll leave that to the people that know better. Perhaps odcctools would work for you? -eric
Re: Problem with listing i686-apple-darwin as a Primary Platform
Except this is a different issue as the patch is for Darwin. http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00168.html Geoff appears to have given a workaround for the problem and has promised to inquire further about more up to date solutions. Another solution, of course, is to revert the default back to stabs. Or use Shantonu's workaround. Personally I agree with Daniel's complaint on the issue and we may need to temporarily revert that single patch until a newer dwarf-utilities can be distributed. This is also one reason why I suggested a specific version of Darwin that is required. That may not be a bad idea. Oh and 10.0, 10.1, 10.2 compiling with GCC are all broken (so is 10.3). I'd probably suggest at least 10.3.9 myself. I'm not sure since 10.3.x predates my employment at apple, or what the current policy is regarding it. -eric
Re: Problem with listing i686-apple-darwin as a Primary Platform
On Nov 7, 2006, at 5:24 AM, David Edelsohn wrote: Eric Christopher writes: Eric> We're in stage1, breakages happen - see the current fun with gmp/mpfr as Eric> well as c99 inlining. File a bug or bring a problem up for discussion. Yes, breakage happens in Stage 1, but the goal should be no breakage. Breakage is by no means inevitable. As a consideration to other developers, breakage should be fixed or reverted as soon as possible to allow other work to proceed. Other developers and other breakage is not a valid excuse, IMHO -- problems cause by others is not a free pass. Well, yes, did you see anything in what I wrote that argued differently? -eric
Re: Problem with listing i686-apple-darwin as a Primary Platform
Eric> Well, yes, did you see anything in what I wrote that argued differently? Yes, what I quoted, the comparison with gmp/mpfr and c99 inlining. Those other problems are irrelevant. I disagree, they were other examples of breakages. -eric
Re: bootstrap on powerpc fails
On Nov 7, 2006, at 4:40 PM, David Edelsohn wrote: Kaveh R GHAZI writes: Kaveh> I tried many years ago and Mark objected: Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html Kaveh> Perhaps we could take a second look at this decision? The average system Kaveh> has increased in speed many times since then. (Although sometimes I feel Kaveh> like bootstrapping time has increased at an even greater pace than chip Kaveh> improvements over the years. :-) I object. Any reason other than the obvious "bootstrap already takes too long"? Andrew's suggestion seemed reasonable too. -eric
Re: bootstrap on powerpc fails
On Nov 7, 2006, at 4:40 PM, David Edelsohn wrote: Kaveh R GHAZI writes: Kaveh> I tried many years ago and Mark objected: Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html Kaveh> Perhaps we could take a second look at this decision? The average system Kaveh> has increased in speed many times since then. (Although sometimes I feel Kaveh> like bootstrapping time has increased at an even greater pace than chip Kaveh> improvements over the years. :-) I object. Any reason other than the obvious "I don't want bootstrap time to increase"? -eric
Re: Do not use autoconf 2.60 yet
You appear to have regenerated configure, on both mainline and 4.2 branch, with autoconf 2.60. Could you please regenerate it with 2.59 in both places? Sure, I'll have to dig it up somewhere. It appears to be the default on FC6, I'll use that. -eric
Re: Do not use autoconf 2.60 yet
On Nov 14, 2006, at 11:32 AM, Eric Christopher wrote: You appear to have regenerated configure, on both mainline and 4.2 branch, with autoconf 2.60. Could you please regenerate it with 2.59 in both places? Sure, I'll have to dig it up somewhere. It appears to be the default on FC6, I'll use that. Done, sorry about that. -eric
Re: libffi on Macintel?
On Nov 15, 2006, at 8:59 PM, Jack Howarth wrote: Mike, The problem is that the Geoff rejected the configure.in patch that removes libgcj from noconfigdirs... http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00642.html ...as being too invasive for gcc 4.2. If you manually apply that, it should build java fine with --disable-multilib on Intel Darwin. Why don't you try to get that patch into gcc trunk now that gcc 4.2 has branched? Yup. You should just be able to commit it now. -eric
Re: AVR byte swap optimization
It isn't only on the AVR that bswap_32() is nontrivial to get right. These two versions would rule on the i386 if GCC would be just a little bit smarter: I prefer the single instruction bswap that we now generate for __builtin_bswap[32,64] myself... -eric
Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0
to see if that eliminates the problems. Also I assume Bradley remembered to install the build before running make check. I see lots of libgomp failures I believe those could be due to that. Also, Bradley, did you remember to patch the prune.exp scripts in the testsuite? You will get a huge number of false failures due to linker warnings at -m64 with -g if you don't. Actually FWIW I agree, the fortran exp (and therefore libgomp) files don't handle DYLD_LIBRARY_PATH at all, unlike the way that the C and C++ files do. FWIW I'm running the tests right now, and I agree with Jack, other than the failures with isfinite for long double and a couple of other things darwin is remarkably clean in this situation. -eric
Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0
make -k -j 8 check >& check.log ; make mail-report-with-warnings.log I got results that appear not much different from the powerpc-apple- darwin8.8.0 (i.e., 32-bit) results: http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00267.html i.e., these results don't show a particular fortran problem. Oh good. I'd realized I'd used an older checkout earlier and was having to rerun them. Glad everything seems ok. -eric
Re: building gcc4-4.3.0-20061223 on OSX 10.3 failed
On Dec 23, 2006, at 10:28 AM, Dominique Dhumieres wrote: Building gcc4-4.3.0-20061223 on OSX 10.3 failed with: ... gcc -g -fkeep-inline-functions -no-cpp-precomp - DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/ genconstants \ build/genconstants.o build/rtl.o build/read-rtl.o build/ggc- none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/ print-rtl.o build/errors.o ../build-powerpc-apple-darwin7/libiberty/ libiberty.a ld: warning prebinding disabled because of undefined symbols ld: Undefined symbols: _integer_nonzerop _integer_zerop This was seen on a few platforms. I think it's due to zdenek's patch. -eric
Re: fat binaries for FSF gcc on Darwin?
On Jan 13, 2007, at 6:13 AM, Jack Howarth wrote: I noticed that Apple's gcc compiler in MacOS X 10.4 creates fat binaries in /usr/lib rather than using a ppc64 or x86_64 subdirectory like FSF gcc. Do the Darwin gcc developers ever intend to replicate the use of fat binaries for FSF gcc (in gcc 4.3 perhaps) or will we always use separate subdirectories for 32-bit and 64-bit shared libraries? All of that is done by a script that calls configure and post-processes the resultant builds with the exception of libgcc which is built fat in either place. -eric
Re: fat binaries for FSF gcc on Darwin?
On Jan 13, 2007, at 8:28 AM, Jack Howarth wrote: Eric, So will FSF gcc on Darwin maintain the current 64-bit subdirectory or will it eventually migrate to using fat binaries as Apple gcc does? Current is likely. -eric
Re: incorrect symlink on Darwin
On Jan 17, 2007, at 5:19 PM, Jack Howarth wrote: I noticed today that gcc 4.2 branch seems to create a bogus symlink on Darwin PPC. A symlink for libgcc_s_x86_64.1.dylib is created that points at libgcc_s.1.dylib. However libgcc_s.1.dylib is not a quad binary... file libgcc_s.1.dylib libgcc_s.1.dylib: Mach-O fat file with 2 architectures libgcc_s.1.dylib (for architecture ppc):Mach-O dynamically linked shared library ppc libgcc_s.1.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64 Is anyone else seeing this? Yes, this is expected. If you somehow manage to build enough trees so that you can then lipo and get all four architectures together (ok, this only takes 2 trees), then the symlink will be correct. -eric
Re: How to get rid of attribute(mode(word))?
One target is to identify more places where we can get rid of _Unwind_Word. Other places exist where we definitely need a data type like _Unwind_Word representing a general purpose register. So we have to find a way to define _Unwind_Word without using the mode(word) attribute. So, I might be missing something but I'm uncertain as to why you'd want to do this. -eric
Re: How to get rid of attribute(mode(word))?
There was a long discussion about this a couple of months ago. The summary was that __attribute__ ((mode (word))) was considered harmful. It's safe enough when you use it within a program, but when you start to use in a data structure shared by different codes you run into ABI problems. A typical example is the eh_return_filter_mode target hook, which was introduced (without documentation!) because Darwin needs to access the same exception handling information with two different values of word_mode. I'm not sure I want to know why it seemed like a good idea for darwin to do this, but it seems to be used for all of rs6000 as well. Whee. Anyhow, I can see how it would be bad. Not sure how to handle it without breaking how abi stuff is handled for darwin. -eric
Re: Apple's Objective-C 2.0 extensions
Hi Michael, Two questions about Apple's Objective-C 2.0 work: 1) Does anyone know when the syntax extensions will be available & working in the gcc compiler? 2) Will their garbage collection & accelerated message dispatch mechanisms also be supported? Fairborz is working on them, I imagine that it won't be until they're done in Leopard, but I'll let him give more information. -eric
Re: core changes for mep port
This and the register changes come close to multi-arch gcc. Is that a direction we want to go? Historically we have not tried to support Personally I'd love to see us go this way if it doesn't inconvenience us too much. From what I remember of the MeP port it was pretty clean and wouldn't be an inconvenience. -eric
Re: What is the value of TARGET_C99_FUNCTIONS on Darwin?
Thanks for the answer, but I understand very little of it. The above can be read as: If TARGET_64BIT is true, then TARGET_C99_FUNCTIONS is true, otherwise if we're targeting 10.3 or later, then TARGET_C99_FUNCTIONS is true, otherwise, TARGET_C99_FUNCTIONS is false. So far so good. we are targeting means that flag: -mmacosx-version-min=version The earliest version of MacOS X that this executable will run on is version. Typical values of version include 10.1, 10.2, and 10.3.9. The default for this option is to make choices that seem to be most useful. Is this under the user control and how? Yup. You can set it on the command line. A lot of people I've noticed set it to 10.3.9 for the latest panther update. 10.4 would mean tiger and above, and 10.5 will be leopard and above. though, the exact default for this flag is changing (has change, is going to change). I noticed that! The idea, I believe, is that the default will be the system that you are currently on. For example, if you tell it, How could I? I would be interested by 10.3.9 (possibly 10.4.9). gcc -mmacosx-version-min=10.3.9 ... This is a part I cannot decipher. Don't worry about that :) Basically it's depending things based on other command line options by default. If, however, you always set it then you should be fine there. I wouldn't set it for developing gcc, just using gcc to develop some other application. -eric
Re: What is the value of TARGET_C99_FUNCTIONS on Darwin?
On Mar 17, 2007, at 4:15 PM, Dominique Dhumieres wrote: Eric, Thanks for the explanations. The idea, I believe, is that the default will be the system that you are currently on. It would be nice, but it is not the way it seems to work (at least for gcc, for g++ and gfortran it may, but I am not sure). For instance I have a version of 4.3.0 on 10.4. Without -mmacosx-version-min=10.4 The new method will be that the default will be the system that you are currently on. It's not the default now. -eric
Re: What is the value of TARGET_C99_FUNCTIONS on Darwin?
On Mar 17, 2007, at 4:31 PM, Dominique Dhumieres wrote: The new method will be that the default will be the system that you are currently on. It's not the default now. How new is new? As far as I can tell, it did not work for the 20070309 snapshot. Form the regtests gcc.dg/builtins-59.c and friends which do not pass for the 20070316 snapshot, it is far from obvious that it is working. Is there a direct way to check it? It's not yet checked in :) -eric
Re: gcc 4.2.0 RC1 darwin warnings...
../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:7597: warning: string length '575' is greater than the length '509' ISO C89 compilers are required to support Are these expected? Yup. -eric
Re: libstdc++.dylib linking problem on Darwin
That said, though, there's something weird going on in your build that should probably be tracked down. It didn't happen to me last time I built... Here's a patch that fixes it though it doesn't fix the testsuite results yet and is likely not quite what Daniel will want... Dan? The basic idea is that the darwin code uses slibdir to set the install name of the library - including full path. Yes, this is dumb, but it's the way that darwin does things at the moment. :( We're getting slibdir set to null which makes the install name believe that it's rooted at / instead of $(slibdir)/. -eric Index: Makefile.in === --- Makefile.in (revision 123700) +++ Makefile.in (working copy) @@ -99,7 +99,7 @@ all: all-multi # in-tree libraries, and DejaGNU) know about the layout # of the build tree, for now. $(MAKE) install DESTDIR=$(gcc_objdir) \ - slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR) + slibdir=$(slibdir) libsubdir= MULTIOSDIR=$(MULTIDIR) .PHONY: all-multi all-multi: @@ -820,4 +820,3 @@ include $(srcdir)/empty.mk $(wildcard *. # # Remove use of $(gcc_srcdir). Source files referenced using $(gcc_srcdir) # should move into the libgcc directory. -
Re: libstdc++.dylib linking problem on Darwin
I didn't just pull this out of a hat, you know :-) Where do you think it's going to install the library if you do that? Yeah, I know. I said it wasn't a good patch, but I was on my way out of the office for the evening and wanted to get Doug something and have you look at the code too :) -eric
Re: libstdc++.dylib linking problem on Darwin
On Apr 12, 2007, at 10:17 PM, Daniel Berlin wrote: On 12 Apr 2007 15:14:01 -0700, Geoffrey Keating <[EMAIL PROTECTED]> wrote: I would recommend using the system libstdc++ and system libgcc_s rather than one you build yourself from FSF sources, unless you're actually developing libstdc++. The FSF libstdc++ is, I believe, binary incompatible with the system one, and since system libraries use the system one there is no way to guarantee that you're using the right one for your code. Okay, so uh, how do you propose to do a full bootstrap and test if you can't test the built libstdc++? In particular, since the testsuite sets the dyld library path, won't this cause the system libs to try to use the libstdc++ you just built, which is incompatible? (This is mildly rhetorical, since this is indeed what happens, at least as of 9A377a). Yeah, it was less of a problem until we shipped a linker that uses libstdc++. I'm looking into it when I get a chance. -eric
Re: GCC -On optimization passes: flag and doc issues
increase code size? I feel I must be missing something really obvious... is it just that the other optimisations that become possible on inline code usually compensate? That or the savings from not having to save/restore registers, set up the frame, etc as well. -eric
Re: arm,gcc and dsp instructions
On Apr 20, 2007, at 1:24 AM, Victor Librado wrote: Hello all, I`m working with an arm core 9260EJ-S under Linux (Linux kernel 2.6.15; armv5l-linux toolchain with compiler gnu gcc 3.4.2). I would like to take advantage of the asm DSP like functions the core provides. I compile this way: arm-linux-gnu -msoft-float -mtune=arm926ejs -S mul.c Code generated uses these assembly dsp instructions sometimes (I think critical parts should be assembly written), but it exists any kind of patch or derivative to "tell" gcc to improve the code generated using these kind of 1 cycle instructions more offently? You'll want to probably use -march= so that it will generate the instructions. Tuning is otherwise just costs, and some universal features of the core that would also run on more generic arm chips. -eric
Re: Merging calls to `abort'
> > Now, I wouldn't object to hacking GCC to avoid cross-jumping calls to > > abort. It's just that I don't think that the common GNU use of abort > > serves the users. > Agreed. And as someone suggested, rather than treating abort > specially within GCC, I think we'd be better off with a function > attribute which prevented cross jumping to any function with > the attribute set. I think it makes sense to just not crossjump noreturn attribute functions if we're going to do this. -eric
Re: Merging calls to `abort'
> What we might want to do is provide an option to disable all such > optimizations. > We have had enough requests for -Odebug or something like that. Probably could be just dce, ccp, and a couple of other optimizations... -eric
Re: Question regarding MIPS_GPREL_16 relocation
On Tue, 2005-03-22 at 13:21 +0100, Mile Davidovic wrote: > Hello all > I am using gcc for MIPS ( 3.3.x, target mips-elf). > I had problem during linking, (MIPS_GPREL_16 relocation truncated to fit > error occurs). > I set value of gp registers to appropriate value and used -mlong-calls and > -G0 switch to > prevent this problem. > > However problem arise again depending on section size (bss, sbss, data, > sdata). Every time > that heppends I have to move gp again. I believe that this reloation is used > in gcc > libraries (libgcc, stdc++, ...). Is that any chance these libraries to be > build without > mention relocation? You could also try upgrading your gcc and binutils. Without a testcase I'm not certain what's happening, but we've fixed a number of problems with such over the years. -eric
RE: Question regarding MIPS_GPREL_16 relocation
> If my conclusion is correct, is it possible to rebuild this libraries with > -mlong-calls and -G0 option? Yes. You'll need to modify the multilib options. -eric
RE: Question regarding MIPS_GPREL_16 relocation
On Wed, 2005-03-23 at 18:17 +0100, Mile Davidovic wrote: > Hello > > I will try to modify multilib options. > I have question regarding how to add my changes in gcc (see thread Mips > question) > I already sent FSF copyright agreement and I receive confirmation. So I > would like > to introduce switch for forbidding generating unaligned load and store > instruction. > How I can proceed? If you've received confirmation then you need to submit a patch against mainline sources to the [EMAIL PROTECTED] list. You'll want to follow the patch submission guidelines on: http://gcc.gnu.org/contribute.html -eric
RE: Question regarding MIPS_GPREL_16 relocation
On Tue, 2005-03-29 at 11:08 +0200, Mile Davidovic wrote: > Hell all > But where I have to look? > I could easily change libstdc++v3 -> Makefile.am (AM_MAKEFLAGS) and > regenerate all but I am not shure is it good way to do it. For mips-elf you'll want to look in gcc/config/mips/t-elf. gcc/config.gcc has the multilib makefile fragment used for each target. -eric
Re: Using inline assembly with specific register indices
On Tue, 2005-04-05 at 22:25 +0100, Richard Sandiford wrote:
> [EMAIL PROTECTED] writes:
> > asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j)));
>
> In addition to Daniel's reply: you wouldn't want to use "r" here.
> That's for general registers only.
>
> The MIPS port does in theory support coprocessors, but the functionality
> isn't tested much (if at all). The constraint for coprocessor 2 registers
> is "C".
Definitely not tested much. There were good arguments over adding the
work into gas and so it wasn't added. The tests are still in gcc:
./gcc.c-torture/compile/mipscop-4.c
./gcc.c-torture/compile/mipscop-3.c
./gcc.c-torture/compile/mipscop-2.c
./gcc.c-torture/compile/mipscop-1.c
At some point it might be good to collate all of the mips specific tests
into the gcc.target directory. I doubt that cvs history is particularly
important for tests.
-eric
Re: Using inline assembly with specific register indices
> > Ok about the "r" convention I wrongfully used, it is assumed for the integer > register-file. > Correct. > I am currently using MIPS + soft-float + some other functionalities in > Coprocessor #2 with success (somewhat tested in a functional simulator). About > 10-12 special-purpose instructions are implemented in COP2 plus the > ctc2,cfc2,... etc instructions that are detailed in the MIPS ISA documents. > All > added instructions are faithful to the COP2 convention (6-bit opcode + 26 > implementation specific bits). > OK. > I have used Matt Hiller's patch on binutils, for supporting coprocessor > register > names, which was uploaded at gcc-patch ml circa June 2002. It works, at least > for the things I have used it. Actually the patch doesn't correspond exactly > to > either versions 2.13,2.14 or 2.15 but to some CVS snapshot (I suppose). > Correct. CVS as of the day it was submitted. > My question on the usage of inline assembly regards omitting writing long jump > tables (e.g. with nested switches). This is not usually necessary but it is > when dealing with dynamic code generation. > I'm not sure what the question is here. > Plus: can gcc co-operate with dynamic code generation tools e.g. the GNU > lightning? I have also heard of another tool, dcg (if i spell it correctly). I've not done any of this. -eric
Re: apply_result_size vs FUNCTION_VALUE_REGNO_P
On Thu, 2005-04-07 at 16:48 +0200, Eric Botcazou wrote: > > That was my thoughts too. You could take a look at how I fixed it on > > ARM. > > Thanks. So basically you bypass the apply_result_mode array entirely, which > is still wrong as it is on SPARC? > Personally, I think that builtin_apply_args should go away, but what are your thoughts on the rest of the thread. Richard didn't respond to my last mail in the thread here: http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02184.html >From my re-reading (it's been over a year here), I think the FUNCTION_VALUE_REGNO_P "suggestion" is wrong as it's lying to the rest of the compiler. At any rate, what entry are you getting for sparc? How is the comment in regclass.c for reg_raw_mode's initialization not working? -eric
Re: apply_result_size vs FUNCTION_VALUE_REGNO_P
> You mean this? > > /* For each hard register, the widest mode object that it can contain. >This will be a MODE_INT mode if the register can hold integers. Otherwise >it will be a MODE_FLOAT or a MODE_CC mode, whichever is valid for the >register. */ > > But take a look at the head comment for init_reg_modes_once: > > /* Compute the table of register modes. >These values are used to record death information for individual registers >(as opposed to a multi-register mode). */ > > So clearly reg_raw_mode describes the widest mode of a *single* hard > register. > Now, before your change, apply_result_size computed the widest mode of > *multi* hard registers, that's not the same thing. > Actually I meant this one: /* If we couldn't find a valid mode, just use the previous mode. ??? One situation in which we need to do this is on the mips where HARD_REGNO_NREGS (fpreg, [SD]Fmode) returns 2. Ideally we'd like to use DF mode for the even registers and VOIDmode for the odd (for the cpu models where the odd ones are inaccessible). */ if (reg_raw_mode[i] == VOIDmode) reg_raw_mode[i] = i == 0 ? word_mode : reg_raw_mode[i-1]; but... I see that's not the problem. AFAICT from the code that deals with builtin_apply and builtin_return it looks like untyped_call and untyped_return should be doing what you expect for the code to save the values (a quick glance at sparc.md didn't show any problems, but...). Or is something else clobbering later? -eric
Re: GCC 4.0 Freeze
On Sun, 2005-04-10 at 21:13 +0200, Thomas Koenig wrote: > Toon Moene wrote: > > > I'm still thinking about the text to warn gfortran users for the fact > > that this compiler at present doesn't cover all of Fortran 77 - and that > > we assume distributors to provide access to g77 as long as that's useful. > > What about > > "This compiler at present doesn't cover all of Fortran 77. We assume > distributors to provide access to g77 as long as that's useful." Slightly corrected for grammar: "We assume that distributors will provide access to g77 as long until gfortran is compliant with Fortran 77." -eric
Re: GCC 4.0 Freeze
On Sun, 2005-04-10 at 12:23 -0700, Zack Weinberg wrote: > Eric Christopher <[EMAIL PROTECTED]> writes: > > >> "This compiler at present doesn't cover all of Fortran 77. We assume > >> distributors to provide access to g77 as long as that's useful." > > > > Slightly corrected for grammar: > > > > "We assume that distributors will provide access to g77 as long until > > gfortran is compliant with Fortran 77." > > "as long until" is not grammatical English. Also, 'assuming' is odd > in this context; in release notes, one makes recommendations. I would > write: bwahahaha. I suck. That'll teach me to start editing the one thing I wanted (the first part of the sentence) and then keep going. > > "This compiler does not support all of Fortran 77 yet. We recommend > distributors continue to provide packages of g77 from GCC 3.4 for > the time being. When gfortran is considered a complete replacement > for g77 we will announce it." Much better. -eric
Re: Problems with MIPS cross compiling for GCC-4.1.0...
> the patch just for the sake of discussion. Does anyone have some > insight on this? I am using binutils-2.15, glibc-2.3.4, 2.6.12-rc2 > kernel headers and gcc-4.1.0-20050418. Thanks. > I'd use 2.16 binutils, especially if using mainline gcc, but that's not as relevant here... > /home/sjhill/mips-nptl/crosstool-0.31-nptl/build/mips-unknown-linux-gnu/gcc-4.1.0-20050418-glibc-2.3.4/build-glibc/posix/pread.o > ../sysdeps/unix/sysv/linux/mips/pread.c: In function '__libc_pread': > ../sysdeps/unix/sysv/linux/mips/pread.c:69: error: memory input 6 is not > directly addressable > ../sysdeps/unix/sysv/linux/mips/pread.c:86: error: memory input 6 is not > directly addressable Probably a problem with the INLINE_SYSCALL macro? Can you post a smaller preprocessed testcase? (or at the outside the preprocessed file) -eric
Re: [RFC] warning: initialization discards qualifiers from pointer target type
> > > > Though of course, this doesn't mean that we can't have an option to > > control it. -Wno-cast-qual doesn't seem like the right choice, as > > there is no user cast here. Maybe something like -Wno-discard- > > qual, where -Wdiscard-qual is the default. > > > > I notice that these are pedwarns, > > In that case, we can enable it only when -pedantic is used (like many > pedwarns) ? You could, but in this case it's probably best to fix the code... -eric
Re: [RFA] Which is better? More and simplier patterns? Fewer patterns with more embedded code?
> > I like the more and simplier patterns approach but I'm wondering what > the general recommendation is? Mostly what I go for in individual insns,though I try to make sure that the lengths are equal and it's something generated by the named patterns. I.e. make sure that the patterns you do have don't have a lot of multiple insns to accomplish a single task, but also make sure that you're generating the insns in the first place :) -eric
Re: Stage1 ?
On Fri, 2005-05-06 at 07:06 +0200, Stephane Wirtel wrote: > Hi all, > > I would like to know how many stages are there ? > What's the first stage ? > http://gcc.gnu.org/develop.html -eric
Re: __builtin_isless, __builtin_islessequal on mips targets
On Thu, 2005-05-05 at 15:58 +0400, Nadezhda IvanĂvna Vyukova wrote: > The __builtin_isless, __builtin_islessequal functions are provided as > implementations of standard C99 functions 'isless', 'isgreater'. Please, > explain why gcc for mips implements them via instructions > > c.lt.FMT and > c.le.FMT > > instead of > > c.olt.FMT and > c.ole.FMT. No reason in particular. The only difference is that the first will signal an exception on QNaN and the second won't, thereby simplifying the programming model. Do you have a good reason for doing it the other way? -eric
Re: [rfc] mainline slush
> We'd unslush when the primary platforms have clean test results. > > Thoughts? Aye :) -eric
Re: [rfc] mainline slush
> > http://gcc.gnu.org/wiki/GCC%204.1%20Slush > > Just to let folks know that mips-elf fails to build newlib. > There's a segfault in is_gimple_reg_type(), which is being > passed a null type. I'm not sure if I'll have time to look > at it tonight. I took a look and it seemed to work for me, I'll double check with a clean tree and all multilibs in a bit. -eric
Re: [rfc] mainline slush
> Eric (and anyone else who wasn't aware): there's been a lot of > discussion about this on gcc-patches since I posted that message: > > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html > > It's also PR21638: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638 > > It looks like Andrew, Jeff and Daniel have got things in hand > but no patch has been committed yet. Interesting. I'll look. Thanks. -eric
Re: [rfc] mainline slush
On Mon, 2005-05-23 at 19:35 +0200, Steven Bosscher wrote: > On Monday 23 May 2005 18:20, Jeffrey A Law wrote: > > I'd much rather take the time to fix all these problems, install the > > fixes along with the checking bits to ensure they never come back > > rather than to iterate on each one separately. > > And int the mean time, things stay broken? Probably for the best I agree. If things are broken I can wander my sources back a few days and continue to get some work done. -eric
Re: Can't bootstrap trunk on hppa
> main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a > ../ > libiberty/libiberty.a > libbackend.a(modulo-sched.o): In function `doloop_register_get': > ../../gcc/gcc/modulo-sched.c:284: undefined reference to > `doloop_condition_get' > > doloop_end isn't defined on the PA. 2005-06-02 Steven Bosscher <[EMAIL PROTECTED]> Mostafa Hagog <[EMAIL PROTECTED]> * cfgloop.h (doloop_condition_get): Make external. * loop-doloop.c (doloop_condition_get): Generalize to make it usable in modulo-sched.c. * modulo-sched.c (doloop_register_get): Use doloop_condition_get instead of duplicating it. This patch. I've emailed Steven. -eric
Re: Follow up on simulators, documentation, etc.
On Mon, 2005-06-06 at 11:05 +0100, Richard Sandiford wrote: > Thanks for the summary. It sounds from your message, and particularly > the quote from RMS, that we should be accepting the patches unless we > have a particular reason not to trust MIPS to do what they said they'd > do. I certainly have no reason not to trust MIPS, so I guess that > means the patches can go in once ready. Eric, do you agree? Provided we get a commitment for sim support and binutils support for the instructions exists I'm OK with them going when they're ready. -eric
Re: MIPS Tri-arch Question
On Tue, 2005-06-14 at 01:04 -0700, Jim Gifford wrote: > I just wanted to ask a question about the tri-arch setup for MIPS under > IRIX. > > Is this planned for libraries other than IRIX based shared libraries, > will this capability be extended to the linux shared libraries? > Short answer: it already has been. Long answer: Look at gcc/config/mips/linux64.h. -eric
Re: Error building 4.0.1-RC2
On Mon, 2005-06-20 at 15:02 +0930, Mark Williams (MWP) wrote: > Thought i should report this... > > Building 4.0.1 RC2, i get this error: > > make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl' > make[1]: Entering directory > `/data/backup/linux/gcc/gcc-4.0.1-20050616/build-i686-pc-linux-gnu/libiberty' > make[1]: *** No rule to make target `../include/ansidecl.h', needed by > `regex.o'. Stop. > make[1]: Leaving directory > `/data/backup/linux/gcc/gcc-4.0.1-20050616/build-i686-pc-linux-gnu/libiberty' > make: *** [all-build-libiberty] Error 2 > > Anything else you guys need to know? Configure command? I'll assume the host was i686-pc-linux-gnu. In this case I'll bet you built in the source directory? -eric
Re: Error building 4.0.1-RC2
> > Yes i did... i always do and have never had a problem doing so before. > I will try building in a different directory though and report back. http://gcc.gnu.org/install/configure.html To be honest I'm always surprised when it works at all. -eric
Re: Error building 4.0.1-RC2
>
> If someone wishes to submit a patch for that bug for 4.0 branch, I expect
> it could be considered for 4.0.2 but might be too risky for 4.0.1 now.
>
Like so? Tested by building outside the source directory and attempting
to build in the source directory. Did we want something like this for
mainline too?
-eric
2005-06-21 Eric Christopher <[EMAIL PROTECTED]>
* configure.in: Reject building in the source directory.
Index: configure.in
===
RCS file: /cvs/gcc/gcc/configure.in,v
retrieving revision 1.341.2.4
diff -u -p -w -r1.341.2.4 configure.in
--- configure.in6 Jun 2005 06:59:11 - 1.341.2.4
+++ configure.in21 Jun 2005 22:15:20 -
@@ -70,6 +70,11 @@ progname=$0
# if PWD already has a value, it is probably wrong.
if test -n "$PWD" ; then PWD=`${PWDCMD-pwd}`; fi
+# If we're building in the source directory, error.
+if test "${srcdir}" = "." ; then
+ AC_MSG_ERROR([Building in the source directory is not supported. See
http://gcc.gnu.org/install/configure.html for more details.])
+fi
+
# Export original configure arguments for use by sub-configures. These
# will be expanded by make, so quote '$'.
tmp="$progname $@"
Re: Error building 4.0.1-RC2
On Tue, 2005-06-21 at 18:24 -0400, DJ Delorie wrote: > > Like so? Tested by building outside the source directory and > > attempting to build in the source directory. Did we want something > > like this for mainline too? > > We've historically put a lot of effort into making "./configure" work, > so I'd hate to snub anyone willing to work on it. Perhaps an "at the > moment" in the message might be good. Apparently it works in mainline right now. Maybe adjusting the release notes for 4.0 to say that building in the source directory doesn't work for the release at the moment? -eric
Re: Error building 4.0.1-RC2
On Tue, 2005-06-21 at 15:31 -0700, Eric Christopher wrote: > On Tue, 2005-06-21 at 18:24 -0400, DJ Delorie wrote: > > > Like so? Tested by building outside the source directory and > > > attempting to build in the source directory. Did we want something > > > like this for mainline too? > > > > We've historically put a lot of effort into making "./configure" work, > > so I'd hate to snub anyone willing to work on it. Perhaps an "at the > > moment" in the message might be good. I also changed the error message to read: "... is not supported in this release" Which might work and we can, of course, remove the error message if that ever changes :) OK? -eric
Re: Error building 4.0.1-RC2
On Wed, 2005-06-22 at 07:06 -0700, Mark Mitchell wrote: > Eric Christopher wrote: > >> > >>If someone wishes to submit a patch for that bug for 4.0 branch, I expect > >>it could be considered for 4.0.2 but might be too risky for 4.0.1 now. > >> > > > > > > Like so? Tested by building outside the source directory and attempting > > to build in the source directory. Did we want something like this for > > mainline too? > > This is OK, even for 4.0.1. It's also OK for mainline, and for 4.0.2, > if you don't get it checked in before 4.0.1. Checked it in today. Apparently mainline does this correctly right now, though unless we plan on supporting it in the future an AC_MSG_WARN might be good. "This may not work" -eric
Re: Building cross-compilers with sibling package trees
> So your target audience is "people who use newlib, use the uberbaum > build, and who work on multiple gcc trees", right? Seems > like such a small audience it's not likely to be widely used, > but that's just my impression. I agree unfortunately. Really if you're not wanting to have a single tree it's more effort than it's worth - either that or split it up into build and install binutils and then build and install gcc (using --with-newlib=...). Easily script-able, but I'm pretty sure that's not what doug wants. -eric
Re: Building cross-compilers with sibling package trees
> [It's not a real scenario of course, but it does have the right flavor > of the problem I wish to solve.] > It's the day-to-day development of a fresh port that I want to speed up. > If I've gone through a run of "make check-gcc" and fixed some random > bugs, with fixes in any or all of libgloss, bfd, or gcc, for example, > I'd prefer it if I could just type make and then make check-gcc again. Right, what I do is this: mkdir tmp cd tmp mkdir gcc cd gcc cvs co gcc-full cd .. mkdir binutils cd binutils cvs co binutils newlib gdb cd .. ./make-combined.sh mkdir build cd build ../combined/configure ... make make check-gcc where make-combined.sh has: #!/bin/sh rm -rf combined mkdir combined cd combined ln -s ../gcc/gcc/* . ln -s ../binutils/src/* . > /dev/null 2>&1 rm include mkdir include cd include ln -s ../../gcc/gcc/include/* . ln -s ../../binutils/src/include/* . > /dev/null 2>&1 and this works for my day to day development for a full combined tree. It basically constructs it on the fly out of the two checkouts. I think from talking to you at the summit though that you don't want to script this bit of it, but that it could magically find all of the relevant pieces or at least be able to specify it on the command line. I'm not against additional configury hacks to specify the location of each of the various source directories, i just think it's more effort than it's worth when a combined tree is guaranteed to work.. at least for day to day development - i wouldn't suggest taking an ancient release of one thing and merging with a new one without paying attention to which one overwrites the other. -eric
Re: MIPS-X
On Fri, 2005-07-08 at 20:43 +0800, IM.Nobody wrote: > I can hardly believe there is no port of GCC to MIPS-X. Any clue would > be helpful and greatly appreciated. The question has been asked numerous times on the list. There's no port because no one has done the work. Patches to support this will be reviewed if you write them, I'm not interested enough to do it. -eric
Re: Reducing debug info for C++ ctors/dtors
> What do others think about this patch? If people think, it is OK > to have one additional knob for users then I'll test and submit > formal patch. > > I'll treat silence as, this idea is not OK for FSF GCC. I'd like to > give Jason and our customers compiler with such fix ASAP. And if > it is considered good idea for FSF GCC then I'd like to iron out > small details (e.g. name of switch, stabs specific or general for > all dbg format etc..), in the beginning. I think it's useful, probably in the same vein as the -feliminate-dwarf-dup etc switches. Probably should use the same type of naming convention too. -eric
Re: Reducing debug info for C++ ctors/dtors
> Would be nice if someone could approve it. > It's not in a state that could be approved yet, but hopefully after some cleanup it will be. -eric
Re: Reducing debug info for C++ ctors/dtors
On Wed, 2005-07-13 at 14:05 -0700, Mike Stump wrote: > On Jul 13, 2005, at 12:39 PM, Eric Christopher wrote: > >> Would be nice if someone could approve it. > > > > It's not in a state that could be approved yet, but hopefully after > > some > > cleanup it will be. > > Remove the APPLE LOCAL markers, which, is obvious. Anything else? > If not, Ok with that change? I can't approve it for sure. Comments would be useful, as well as standardizing on an option name to turn it on. The -feliminate-stabs- was what I suggested. -eric
Re: does -fstack-protector work for gcc 4.1 on Darwin 8?
On Aug 3, 2005, at 5:48 PM, Jack Howarth wrote: Does anyone know if the -fstack-protector option in gcc 4.1 branch works on Darwin 8 (Tiger)? I can compile binaries with it but I'm not sure how to test its functionality. Also, this is based on IBM's ProPolice code, right? I'm surprised you could compile code until today - it wouldn't link the ssp libraries in... Anyhow, it seems to work in my limited testing after I checked in a couple of patches. -eric
Re: ICE hunting in gcc-4.1
Would that be useful, or is it overkill? Very useful. Though if you can occasionally go back through them to verify they're still bugs it'd be appreciated. -eric
Re: Gcc and a Garbage Collector.
On Aug 19, 2005, at 5:07 PM, Andrew Pinski wrote: Hi, With this page from Wikipedia, http://en.wikipedia.org/wiki/ GNU_Compiler_Collection, in the "See also" section, there is a sentence about a Garbage collected included in GCC. There's also boehm-gc: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ which is shipped with gcc for java's use. Mostly depends on what you're looking at the gc for - whether it's for your language, for hacking on gcc, or something else. -eric
Re: help on compile error (4.0.1)
I have met the same question. My solution to this is just to remove ./config.cache in every sub-directories and try again. This solution is effective although I am not sure about it. Anyone could confirm or deny this. I think "make distclean" should be done before ./configure if the option of configure is changed. rm -rf also works. -eric
Re: Cross Compiler Unix - Windows
On Aug 25, 2005, at 5:53 PM, Ivan Novick wrote: Yes understood, but thats the whole point, cygwin runs on a windows machine... I would like to use a UNIX machine to compile the Windows DLL. You can cross compile to cygwin using gcc. An old link from google with "cross compiler cygwin" is available here: http://www.delorie.com/howto/cygwin/cygwin-cross-howto.html -eric
Re: -fprofile-generate and -fprofile-use
On Aug 31, 2005, at 3:40 PM, girish vaitheeswaran wrote: I do not see this flag in gcc3.4.4. Am I missing something? you may try adding -fmove-loop-invariants flag, which enables new invariant motion pass. The "new invariant motion pass". -eric
Re: glibc or newlib for mips-elf?
Exactly to say, the target is neither mips-elf nor mips-linux-gnu. I just use mips-elf as the start. It's a new target with little endian and own ISA. We need to port binutils and gcc and also library. For a port then yes *-elf is easier to start, especially if you're planning on going for an elf based operating system. What about the mips port made you decide that you wanted to use that as a guideline? -eric
Re: Question regarding compiling a toolchain for a Broadcom SB1
I would prefer a recipe to build the toolchain myself from source, but if you happen to know of a site with binaries for the SB1 under Linux, I wouldn't be horribly opposed. For the latter I'd try broadcom, they've been pretty good about shipping tools that are known to work on the board. That said, for building from source I'd try Dan Kegel's crosstool script. That's what most people use. If you're still having problems let me know - perhaps it's something obvious. -eric
Re: Language Changes in Bug-fix Releases?
On Sep 6, 2005, at 6:44 PM, Mike Stump wrote: On Sep 6, 2005, at 6:16 PM, Gabriel Dos Reis wrote: wrong-code generation that was fixed. Customers validate their app and are `happy' with the code generation, so this appears to not be a real an issue. Failure to compile their app to them feels slightly more real. Yes, but someone else was silently failing, I'd rather know my code was crap up front. -eric
Re: question about linker
On Sep 9, 2005, at 10:28 AM, sean yang wrote: Hi I am looking for the source code related to linking stage--coz I am trying to modify (very slightly) the linker. I understand that 'ld' is the linker in Linux. My question is: Is 'ld' a part of gcc toolchain? --If it is, I should be able to find source file producing 'ld'. But I haven't found the source file to be compiled to 'ld'. --If it's not, main() of gcc.c should invoke ld if it found the '- o' option. But I didn't find the invocation either(maybe it's not a straightforward invocation). The linker is ld, and is in the binutils package. http:// sourceware.org/binutils/. To see what's really going on try adding -v and -Wl,-v to your gcc command line. -eric
Re: Question regarding compiling a toolchain for a Broadcom SB1
= Both binutils and glibc's configure scripts will see it as a mips32, because it does not start off with mips64 in the name. Should probably fix the configury to recognize mipsisa64 as a 64-bit target. binutils should already do this for mipsisa64-linux-gnu, but I don't know about current glibc. -eric
Re: Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
On Sep 12, 2005, at 7:17 PM, Steven J. Hill wrote: Greetings. I attempted to search through Bugzilla, but I did not find anything that matched my query. When using the options '-O0' and '-g' together with GCC-4.1.0, I get an executable that will segfault. If I use all the other optimizations of -O1, -O2 or -Os I do not have this problem. I am using binutils-2.16.1, a checkout of gcc-4.1 from 20050604 and uClibc. Has anyone else seen something like this? My compile and link lines look like the following: /build/buildroot-nptl-debug/build_mips/staging_dir/bin/mips-linux- uclibc-gcc -Wall -Wstrict-prototypes -O0 -mno-split-addresses -g - c clone.c -o clone.o /build/buildroot-nptl-debug/build_mips/staging_dir/bin/mips-linux- uclibc-gcc -g -Wl,-warn-common -static clone.o -o clone I've not seen it, but do you see it with, say, those options and the simulator testsuite? (I don't have one built at the moment or I'd check myself.) Otherwise, what's the code look like where they segfault? -eric
Re: Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
I assume you mean using the gdb simulator, or what? Sorry for my ignorance. Yup. Otherwise, what's the code look like where they segfault? Let me quantify that and I will post a tarball tomorrow. Thanks. OK. I don't have any mips hardware at the moment, but I should be able to help you anyhow :) -eric
Re: proposed Opengroup action for c99 command (XCU ERN 76)
I am the opposite of an expert on this topic. But in fact gcc does appear to have code related to (A), (B), and (C). I repeat those choices here from Paul's original e-mail: A. Convert everything to UCNs in basic source characters as soon as possible, that is, in translation phase 1. (This is what C++ requires, apparently.) B. Use native encodings where possible, UCNs otherwise. C. Convert everything to wide characters as soon as possible using an internal encoding that encompasses the entire source character set and all UCNs. Now, see libcpp/charset.c. See the -finput-charset= option. To me that looks like code which does something related to (A), (B), or (C). It does. I think the best bet would be (A) for the code that we have in libcpp at the moment. Right now we translate upon getting characters into an intermediate format that does encompass as much as possible (IIRC). That, and it'd make sure that we handle what c++ requires. I'm also not as much of an expert as I'd have liked to be when dealing with this in the first place. -eric
Re: RFC: dbxout_type rewrite
The only issue I can see is that someone who uses an older versions of Mac OS X but don't have access to the newer GDB because building Apple's version of GDB is a little harder than building than gcc. If you provide a gdb version which is runnable on All of Mac OS X, this becomes a little mute, like the new cctools and stuff. I think you mean "moot", and it isn't because anyone else that wants stabs debugging would still need to change their debugger. Now, most people use dwarf, but the problem is still there. If people think it wouldn't be that much of a problem then I'm all about getting this patch in. -eric
Re: Should -msse3 enable fisttp
Actually it enables more than the builtins. It enables the use sse3 instructions. This is just like -maltivec on PowerPC and -msse and -msse on x86, etc. Right, so the manual disagrees and should probably be fixed. And then RTH agreed: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01432.html So from the sound of it fisttp is not a SSE3 instruction. Richard's response was that it shouldn't be turned off by -mno-sse3, not that it shouldn't be turned on for -msse3. I think it probably should be turned on there. -eric
Re: adding a MIPS instruction with operands to GCC
On Oct 12, 2005, at 4:40 PM, guru venky wrote: I am trying to add a mips instruction with operands to gcc. Basically I want an instruction that acts as marker for a future instruction. as an example, if i want a marker for addi R1,constant (add immediate) instruction, i would do something like marker constant to be emitted by gcc. can anyone help me achieve this, You'll want to edit mips.md and add the pattern for the instruction that you want to emit. If it duplicates existing functionality you'll need to modify the existing pattern that has that functionality to not match anymore. -eric
Re: backslash whitespace newline
On Oct 24, 2005, at 3:52 PM, Neil Booth wrote: Howard Hinnant wrote:- I've been reviewing the age-old issue of interpreting * as the end-of-line indicator as is the current practice with gcc. FWIW I support abandoning this behaviour too. I filed bugzilla 24531 about this. Haven't heard Joseph weigh in on this issue, but here are the options that I see: a) We enable the conditional warning for line continuation in a comment at all times (just as we do for normal lines) b) Change the preprocessor to remove the behavior and disable the continuation if we have a \ followed by a space c) Do nothing. Option c will leave us with the current behavior that I don't believe I've heard anyone want to keep (other than it's the current documented behavior). I'll work up a patch for b since that's what Apple would like the most. I believe that option a is needed at least. This is, as Mr. Buck has noted, a regression from 2.95. -eric
Re: backslash whitespace newline
Oh, one more thing. This seems like the normal problem of not reading the docs if something does not work the way you want it to work. So? The only thing we can do is point it out that it is documented behavior and then move on to the next issue. Also why are we discussing this when there are more important bugs to fix currently as this behavior has been documented for a long time, at least 4 years. Your important and my important are two different things. -eric
Re: backslash whitespace newline
This is not a regression really. It is a regression against 2.95. -eric
Re: backslash whitespace newline
As I said, no it is not. A behavior change is only a regression when the first behavior is correct and the second is not. Fair enough. :) -eric
Re: backslash whitespace newline
I don't see either is true here. Actually, I agree. While I'd like the change to the compiler, I don't want it to be a switch. Either we do it, or we don't. -eric
Re: backslash whitespace newline
Don't you think it is reasonable to fix horrible coding errors like this, you are just asking for maintenance problems. In the short term, kludging may make sense, in the long term it sounds a bad idea to keep such non-portable code around. The problem is that it's portable to every other compiler we've tested. I am curious what icc and xlc do, but those are the only two not tested. -eric
Re: backslash whitespace newline
On Oct 26, 2005, at 5:55 PM, Joe Buck wrote: On Thu, Oct 27, 2005 at 01:48:57AM +0200, Vincent Lefevre wrote: On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote: But in a way you are defending it as you want GCC to change. If there was any other reason besides ASCII art, some people would be more willing to change but there is a simple fix person's code to get around this issue. And that is by not using C++ style comments and just use C style ones. Adding a line // just after the ASCII art would be even easier. Eureka! Yup. I've mentioned it. Boy have I mentioned it. :) However, the "this is a small implementation defined issue that's easy to change for users that are migrating from other compilers" issue remains. -eric
Re: resolving backslash newline whisky tango foxtrot: a proposal
I'm good with this proposal. I was against the flag in the first place for a desire to pick something and let's do that, but it seems like with so much furor over it we should probably just have a flag. :) -eric
Re: apps built w/ -fstack-protector-all segfault
apps built w/ -fstack-protector-all segfault You will have to give us more info. Most gcc developers probably don't have a copy of UClibc, and plus it sounds like you have made gcc changes that weren't included in your message. So there isn't much we can do here except ask for more details. Try debugging the problem. If you can identify a specific problem here, and give us details about it, we can probably help. Also since __builtin_trap is used in the fail mechanism the comment above the trap instruction in i386.md might be useful: ;; We used to use "int $5", in honor of #BR which maps to interrupt vector 5. ;; That, however, is usually mapped by the OS to SIGSEGV, which is often ;; caught for use by garbage collectors and the like. Using an insn that ;; maps to SIGILL makes it more likely the program will rightfully die. ;; Keeping with tradition, "6" is in honor of #UD. So you may be seeing something mapped odd, or... -eric
Re: apps built w/ -fstack-protector-all segfault
this should also influence the -fstack-protector behaviour, but that seems to be OK. __builtin_trap is used as I can see only if a vulnerability is found, this happens though on a simple hello world. Aaah. You'll probably need to step through the program in a debugger then and find out where and why it segfaults. -eric
Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082 Unfortunately, even with my Apple Developer account I can't seem to figure out how to look up radar reports that I haven't submitted. I took a look at the radar. Says, effectively, that the bug has been fixed in ld64 and will be in the next release. -eric
