rick, but it doesn't seem to work for gcc.
Use CFLAGS="-g" ../gcc-src/configure. The top level file is still
autoconf 2.13.
--
Daniel Jacobowitz
CodeSourcery
we're far enough on yet to know the answer to this or
your other question, but I may be wrong. There's a reason we're
focusing on C right now :-) I don't think the design precludes this
sort of thing, but we won't know how it all fits together until more's
been done.
--
Daniel Jacobowitz
CodeSourcery
ne" without "extern" when in C99
> mode.
Isn't the whole point that the current extern inline isn't
__always_inline__, but leaves it to the compiler's judgement?
--
Daniel Jacobowitz
CodeSourcery
ult causes all kinds of problems.
--
Daniel Jacobowitz
CodeSourcery
ply
> to xgcc, since it's only used in the build (right?).
No, xgcc is installed as gcc. If you have a dynamic libgmp, it will be
used.
--
Daniel Jacobowitz
CodeSourcery
rs on global readonly, but in typical compilation
most of the memory allocated is definitely global. Past a certain
point much of that is probably readonly. However, it would take some
clever interfaces and discipline to _guarantee_ that any particular
global bit was shareable.
--
Daniel Jacobowitz
CodeSourcery
up. We ought
to be able to emit (somewhat smaller) unwind information which doesn't
reference the personality routine if it's going to have nothing to do,
shouldn't we?
--
Daniel Jacobowitz
CodeSourcery
't amenable to
_Unwind_Backtrace / _Unwind_ForcedUnwind, et cetera. For .eh_frame,
though, the personality routine is only necessary to run cleanups
and check exception specs.
--
Daniel Jacobowitz
CodeSourcery
On Sun, Nov 12, 2006 at 05:11:39PM -0800, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
>
> > If you try what Michael's been saying, you'll notice that trivial
> > C++ files get the personality routine reference even if they don't
> > have anything with a
e move of toplevel to
> 2.59; I'm not sure what's holding that up now all subdirectories of gcc
> and src have been moved.)
At this point I believe there are no more blockers. Steve Ellcey would
be the person to ask.
--
Daniel Jacobowitz
CodeSourcery
esn't quite at present; powerpc64-gnu does not include
t-ppccomm. powerpc-gnu does.
--
Daniel Jacobowitz
CodeSourcery
inite loop in configure for this
case?
--
Daniel Jacobowitz
CodeSourcery
iners first, but haven't heard back
from any of them...)
--
Daniel Jacobowitz
CodeSourcery
On Thu, Dec 14, 2006 at 10:19:12AM +0100, Basile STARYNKEVITCH wrote:
> In other words, should I make all my configurable flag visible by the
> toplevel configure and propagated (thru Makefile.tpl) to gcc/ or not?
No, you shouldn't. Only add them to subdirs that need them.
--
Daniel
ween _stext and _etext are recorded.
--
Daniel Jacobowitz
CodeSourcery
nt on the list, please ask the Steering Committee.
This is a textbook example of what they're for.
--
Daniel Jacobowitz
CodeSourcery
e been saying that since
the first top level bootstrap rules went in, every time the subject
came up - this really shouldn't be a surprise.
Libgcc will no longer be configured by the gcc subdirectory's makefile.
Therefore there will be no startfiles or libgcc for the new compiler to
use.
--
Daniel Jacobowitz
CodeSourcery
compiler is not functional. It can't use libgcc
or crtbegin from the system; they might not even exist, depending on
your bootstrap compiler.
Do you mean something different by "bootstrapping just the compiler"?
--
Daniel Jacobowitz
CodeSourcery
would even be possible to not bootstrap those host libraries
- but unwise for the reasons we wanted them bootstrapped originally,
and they're very quick to build.
In a combined tree we bootstrap binutils too. That's less obviously
useful. But in a GCC-only tree we bootstrap intl, gcc, libcpp,
libdecnumber, libiberty, and zlib: all things linked directly into
the compiler.
--
Daniel Jacobowitz
CodeSourcery
e configure-time decision - if there's
a convincing reason to do so.
--
Daniel Jacobowitz
CodeSourcery
LES error message really ought to (A) get logged in
config.log, and (B) tell you why it decided link tests were forbidden.
(And it's my fault originally IIRC.)
I'm not at all sure how the nm failure ends up leading to this problem,
but I'll take your word for that part.
--
Daniel Jacobowitz
CodeSourcery
e problem is usually obvious.
--
Daniel Jacobowitz
CodeSourcery
urposes, but the next one is the GCC_NO_EXECUTABLES test, and that one
> should have worked.
Unfortunately, when it fails, the error does not get logged properly.
--
Daniel Jacobowitz
CodeSourcery
e.ac), we'll
be untangling them. Eventually, it should be possible to build
gcc and the target libraries separately.
--
Daniel Jacobowitz
CodeSourcery
On Thu, Jan 04, 2007 at 04:19:17PM +1100, Ben Elliston wrote:
> On Wed, 2007-01-03 at 23:28 -0500, Daniel Jacobowitz wrote:
>
> > Right now the libgcc configuration is completely tied up with
> > gcc/Makefile. As parts of the configuration process move from
> > gcc/confi
0/
> but rather into /lib/gcc/i686-pc-linux-gnu/.
> Is this related to the recent libgcc changes?
Yes, it's my fault. The last time I tested make install, they went to
the right place. I'm building right now to find out what's gone wrong.
--
Daniel Jacobowitz
CodeSourcery
On Thu, Jan 04, 2007 at 08:59:51AM -0500, Daniel Jacobowitz wrote:
> On Thu, Jan 04, 2007 at 02:32:19PM +0100, Martin Reinecke wrote:
> > /usr/bin/ld: crtbegin.o: No such file: No such file or directory
> > collect2: ld returned 1 exit status
> >
> > This probably happe
ed, removed.
The latter; feel free to remove them :-)
--
Daniel Jacobowitz
CodeSourcery
as rather
> reasonable, but you and other build machinery wizards convinced us that this
> would be a pain to support with toplevel bootstrap. So what has changed?
Not much. I'm convinced it would be feasible, but definitely not easy,
so I wanted to see how much interest there was - seems like some, but
not a lot.
--
Daniel Jacobowitz
CodeSourcery
ister usage but still have no idea.
>
> I would *really* appreciate any help I can get on this issue!
Take a look at -ffixed-REG.
--
Daniel Jacobowitz
CodeSourcery
e support into the 4.2 branch?
I have no intention of touching the build system for the release
branch, in any case.
--
Daniel Jacobowitz
CodeSourcery
he functionality otherwise lost.
>
> Or do I misunderstand?
We're not talking about that at all. I was only talking about whether
the decision was made at configure or make time.
--
Daniel Jacobowitz
CodeSourcery
ought to get it working.
And I certainly don't have time to do it before 4.2.0.
--
Daniel Jacobowitz
CodeSourcery
ebian packaged one; Debian's compilers
default to generating code for a 486 or later.
--
Daniel Jacobowitz
CodeSourcery
me config-ml.in to enable multilibs that libiberty
does. You're going to have to figure out why that's decided that we
shouldn't build multilibs. It starts by checking xgcc
-print-multi-lib; that works, right? Could it have picked up
a bad setting for $CC?
--
Daniel Jacobowitz
CodeSourcery
And honestly, I have no idea how that happened. Does it happen
with a current GDB? I suspect from the error message that this
one is not too recent.
--
Daniel Jacobowitz
CodeSourcery
6.5, so reasonably recent.
Please try a current snapshot. Thanks.
--
Daniel Jacobowitz
CodeSourcery
> You must be new around here:
>
> http://gcc.gnu.org/ml/gcc-announce/1997-1998/msg0.html
>
> :-) Which is the I feel lucky google("site:gcc.gnu.org how to run
> installed GCC_UNDER_TEST") result.
For the less old-school inclined, try contrib/test_installed.
--
Daniel Jacobowitz
CodeSourcery
ivdi3. It there a way
> of making use of this facility in a more elegant way than putting the whole
> gcc command line in a target makefile fragment?
I'm not sure I understand what you want to do. Could you give me a
bigger example? Those bits are only used for fix/float conversions.
-
xt),$(siintfuncs))
ifeq ($(enable_shared),yes)
libgcc-s-objects += $(patsubst %,%_s$(objext),$(siintfuncs))
endif
If you think it would be useful for enough targets, you could add some
code to automatically extract the bits before and after the colon and
give this a standard name that tdep files could s
I've put up some information on the wiki about moving configuration
information from gcc to libgcc. Please, feel free to add to it!
http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration
--
Daniel Jacobowitz
CodeSourcery
reading this know what the right thing to do is? Is there
anything in the autoconf documentation about not using some macros
inside conditional statements?
--
Daniel Jacobowitz
CodeSourcery
e are in a Canadian setting, we can set
> all the variables that Autoconf sets, in the `then' branch. So we'd set
> ac_objext=.o in the `then' branch.
This seems horribly wrong somehow. Aren't we intested in the ${build}
-> ${host} compiler at this point anyway? So shouldn't we be testing
it? I think the whole block can go.
--
Daniel Jacobowitz
CodeSourcery
t; Hmm, it says indeed "this is going to change when we autoconfiscate".
> Something like this?
Yes, pretty much (though I don't see the point in the CFLAGS -g
assignment either).
--
Daniel Jacobowitz
CodeSourcery
e something in
/usr/local/bin/x86_64-pc-mingw32-gcc.exe also; do you?
The one in /usr/local/x86_64-pc-mingw32/bin is different, and may not
work - I think the way that normally happens involves symbolic links,
or something similar. Anyway, you don't need to use it.
--
Daniel Jacobowitz
CodeSourcery
e my statement. And if that holds, I continue to stand by it.
On the other hand, I consider this a fairly serious bug in 4.1 (and
I've seen customers encounter it at least twice off the top of my
head). It depends what your tolerance for wrong-code bugs is.
--
Daniel Jacobowitz
CodeSourcery
fully reproduce the testcase. This stuff is not easy to
trigger. But if you do, it's quite unpleasant - both for the user,
and for the poor compiler developer who has to figure out what
happened.
--
Daniel Jacobowitz
CodeSourcery
aybe don't ship 4.2.0 at all.
>
> so, I don't see backporting more patches or even re-branching as
> a real option.
I've been convinced of the same. If we (GCC developers) shipped it
with the aliasing fixes reverted, I'm not sure quite what we
(CodeSourcery) would do
the lines of the bugmasters.
Good luck keeping people. It's a crappy job.
--
Daniel Jacobowitz
CodeSourcery
ix $SYSROOT to it.
Did you try it? This should already happen if you configured binutils
with a sysroot.
--
Daniel Jacobowitz
CodeSourcery
On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote:
> I have used "strace -f" to check where linker looked for -lqt-mt. From
> what I have observed, it seems that ld didn't use
> $SYSROOT/etc/ld.so.conf.
Well, it's supposed to, so I suggest you check what&
orks just fine
> natively and with cross compilations. I'd file a bug report. If it
> is an OS bug, it can be fixed by fixincludes.
He's talking about finding the target's int_fast8_t in the frontend.
That's another issue entirely.
--
Daniel Jacobowitz
CodeSourcery
#x27;t know where your acres and acres are,
but they aren't in most GNU software. This is, unsurprisingly, how
emacs behaves.
Personally I think that regardless of your indentation preferences,
using anything besides eight column tab stops for \t is silly; that's
what "cat" is going to use.
--
Daniel Jacobowitz
CodeSourcery
t; being possibly undefined). I think I want the -I options though.
Yes, you always want to match ACLOCAL_AMFLAGS from Makefile.am.
--
Daniel Jacobowitz
CodeSourcery
time your patch was first written, we decided to
fix this in the driver instead and leave make_relative_prefix
unchanged:
2006-04-28 Joseph S. Myers <[EMAIL PROTECTED]>
* gcc.c (process_command): Add program name to GCC_EXEC_PREFIX
value before passing to make_relative_prefix.
--
Daniel Jacobowitz
CodeSourcery
On Mon, Mar 19, 2007 at 05:25:37AM -0700, Karthikeyan M wrote:
> Thanks for the information.
> So, if I want to debug a bug in the cc1 code that causes target
> library build to fail -
> should I just use the cc1 that is generated in /gcc/ ?
Yes.
--
Daniel Jacobowitz
CodeSourcery
On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote:
> Perhaps this ought to be looked at again with some seriousness.
I think this is an idea whose time has either come, or will shortly.
GCC's -O0 is much more extreme than that of other compilers I've used.
--
Dani
se
'make install' into a system location, but that's about it. And
usually one shouldn't do that anyway.
There's /lib64 -> lib and /usr/lib64 -> lib symlinks, which help out.
--
Daniel Jacobowitz
CodeSourcery
rictly necessary if you've got nothing but a type
code in it. Have a couple of constant TYPE_LANG_SPECIFIC instances
in rodata :-)
Which is less useful if you want to move things out of the common
tree, of course.
--
Daniel Jacobowitz
CodeSourcery
But at least the patch shows the
> problem and a possible solution, so maybe you (or someone who
> understsands the build scripts) can fully test it.
libgcc should not use AC_CANONICAL_TARGET; --target doesn't mean
anything to a target library. I'm not sure about libdecnumber - it
ode above like this:
> gcc test.c -o test.so -shared -fPIC [-s]
> The problem is that i'd expect gcc/ld to abort with an error,
> but it just 'successfully' links something.
> Am i missing something? How can ld link against a
> definitely unknown function?
See
On Tue, Mar 27, 2007 at 03:01:04PM -0400, DJ Delorie wrote:
> - CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
> + CROSS_SYSTEM_HEADER_DIR='$(shell echo $(gcc_tooldir)/sys-include)'
Don't you need more quotes than that?
--
Daniel Jacobowitz
CodeSourcery
lude)'
> >
> > Don't you need more quotes than that?
>
> I think if we quoted it more, we'd end up passing the backticks along
> instead of processing them, and we'd end up right where we started.
I only meant:
CROSS_SYSTEM_HEADER_DIR='$(shell echo "$(gcc_tooldir)/sys-include")'
--
Daniel Jacobowitz
CodeSourcery
s quoting?
$(gcc_tooldir) starts with $(libsubdir) starts with $(libdir) which
will come from $(prefix), so there's an unquoted $(prefix) there.
../gcc/configure --prefix=/usr/local/"where * am * i" will thus lead
to $(shell echo /usr/local/where * am * i/sys-include), which will
wildcard.
--
Daniel Jacobowitz
CodeSourcery
adding locations on more things is a
workable solution to the problem. I wish someone had sufficient
incentive to sit down and design a proper solution to our degenerating
debug info.
--
Daniel Jacobowitz
CodeSourcery
se where the current approach would even
require locations on constants. And that's obviously infeasible, so...
--
Daniel Jacobowitz
CodeSourcery
uld not make a significant difference.
--
Daniel Jacobowitz
CodeSourcery
last month I discovered that
there is a use of operator new[] with a subscript of INT_MAX - 1
(INT_MAX is handled specially). In general this still works out
to be more memory than can be allocated and the test tests what it
wanted to (bad_alloc).
--
Daniel Jacobowitz
CodeSourcery
read in, we
> might even see some cache friendly accesses for a change.
FYI, I did this with PCH once... I never followed it through well
enough to get consistent results from it, but I did get some
remarkable jumps during testing.
--
Daniel Jacobowitz
CodeSourcery
o install the library if you do that?
SHLIB_INSTALL = \
$(mkinstalldirs) $(DESTDIR)$(slibdir); \
$(INSTALL_DATA) $(SHLIB_SONAME) \
$(DESTDIR)$(slibdir)/$(SHLIB_SONAME)
--
Daniel Jacobowitz
CodeSourcery
which you didn't show the type of - but there's probably nothing in
the C builtin decl that says it modifies its arguments. If the RTL
says that it clobbers its first input, then the RTL register allocator
is responsible for handling that.
--
Daniel Jacobowitz
CodeSourcery
mentation fault.
>
> I wonder where my wrong assumption is. Any suggestions?
What do you mean, it's built in? It comes from a source file, so
almost by definition it isn't.
--
Daniel Jacobowitz
CodeSourcery
On Mon, Apr 16, 2007 at 05:51:17PM +0100, Dave Korn wrote:
> Perhaps Paulo wants to know if the definition originated in a system header
> file?
Yes, this is more likely to be useful.
--
Daniel Jacobowitz
CodeSourcery
will go in during Stage
1 without any coordination.
Could you explain what benefits from waiting? None of the other large,
scheduled changes from 4.1 benefit from pushing this back. The only
thing that it saves is one possible cause of broken bootstraps; you may
as well ask no one to
On Sun, Feb 27, 2005 at 03:56:26PM -0800, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
> >On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote:
>
> >Nathanael said it did not interfere with any of the other _projects_,
> >not that it would be disjoint fr
; for talking to myself here.)
I don't think that's the concern here - it's more a matter of whether
the target, and DejaGNU, support this. Lots of embedded targets seem
to have trouble with it. Take a look at "noargs" in the DejaGNU board
files for a couple of examples, IIRC. GDB jumps through some hoops to
test this, and gets it wrong in a bunch of places too.
--
Daniel Jacobowitz
CodeSourcery, LLC
reliable. The dg-program-options directive could warn when it's used
> in an environment for which it's not supported.
Sounds good to me, at least in theory.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Fri, Mar 04, 2005 at 04:33:47PM -0800, Janis Johnson wrote:
> On Tue, Mar 01, 2005 at 04:35:54PM -0500, Daniel Jacobowitz wrote:
> > On Tue, Mar 01, 2005 at 10:29:45AM -0800, Janis Johnson wrote:
> > > Is command line processing relevant for embedded targets? (I have no
&
uspect we could get a lot of mileage out of something like libiberty
uses, and declaring the things it can't handle to be bugs...
--
Daniel Jacobowitz
CodeSourcery, LLC
ld be a JUMP_INSN.
Your backend is probably using emit_insn when it should be using
emit_jump_insn.
--
Daniel Jacobowitz
CodeSourcery, LLC
t; in C? I believe they are used by Ada.
Nested functions in other languages, presumably.
> - Many backends do not support trampolines. Are trampolines
> something that is ultimately being added to the backends?
> - Do (theoretical?) alternatives to trampolines exist? I.e. something
>
is often
useful. So perhaps we do need an attribute, but I'm not sure which way
the default should go.
--
Daniel Jacobowitz
CodeSourcery, LLC
objections, or better ideas?
It would be nice if we could preserve the ability to run them - when
your build directory is mounted on the target system at the same path,
the tests will pass. Perhaps a compiler option, as Gabriel
suggested...
--
Daniel Jacobowitz
CodeSourcery, LLC
but now I'm a little less confident
> that this will work. Has anyone else tried it?
I would guess that they're just debugging information. The PCH
shouldn't care.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Thu, Mar 31, 2005 at 07:33:53PM +0100, Dave Korn wrote:
> Is the manual wording just slightly vague here, and both .data and .bss
> are regarded as covered by the phrase "the data section of the object file"?
Yes.
--
Daniel Jacobowitz
CodeSourcery, LLC
hat Geoff said. There are two relevant properties of
GCed memory here:
- Anything in GCed memory will be saved to the PCH
- Anything in GCed memory will be overwritten by loading the PCH.
There will be no references left after the PCH is loaded, unless they
were living outside of GC.
--
Daniel Jacobowitz
CodeSourcery, LLC
ing creating a
generational collector using our existing accurate GC. I've been
working on this on-and-off (mostly off at the moment, though).
--
Daniel Jacobowitz
CodeSourcery, LLC
t of requiring some extra preprocesssing?
They don't have the same design constraints or goals. For instance,
the GTY machinery can determine the type of an object during tree
walking; it does not need to store the type in memory. We also reuse
the GTY machinery for precompiled header
on the coprocessor, then you can use
local register variables for this:
long c2r0 asm ("c2r0");
If it doesn't, then you should probably not be telling GCC about them.
Assuming i is constant:
asm volatile ("cop2a c2r" STRINGIFY(i) ", c2r" STRINGIFY(j) );
--
Daniel Jacobowitz
CodeSourcery, LLC
t;=r" (var1) : "r" (var2));
>
> I assume printf-like formating.
Because it's unnecessary. See my previous message; you can find many
examples on the Web of how to use CPP to stringify numbers.
--
Daniel Jacobowitz
CodeSourcery, LLC
failing #1 at least.
If you want these restrictions fixed, presumably you have some interest
in some port that cares about them. Contribute that port, and maybe a
usable simulator for them, and then people can fix what breaks - and
test it.
--
Daniel Jacobowitz
CodeSourcery, LLC
so I copied the SRCDIR install.sh
> in and that made the top level installs work, but the sub-sub directories
> were still looking for ../install-sh - so I copied it down another level
FYI, this is already fixed in HEAD and the 3.4 branch.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Fri, Apr 08, 2005 at 10:13:38AM -0700, Joe Buck wrote:
> On Fri, Apr 08, 2005 at 09:20:47AM -0400, Daniel Jacobowitz wrote:
> > On Fri, Apr 08, 2005 at 09:05:17AM -0400, Ray Holme wrote:
> > > Many thanks to all for the lessons on how NOT to make things you don't
> &g
y you don't
> keep times of libstdc++v3 build times. Not sure how to check
> this, except maybe rolling back libstdc++ to March 30...
Except that would have shown up in Jim's test...
--
Daniel Jacobowitz
CodeSourcery, LLC
; is it available?
Nope. Your best bet would be to turn up ulimit -c and look at a core
dump.
--
Daniel Jacobowitz
CodeSourcery, LLC
> config.h is not HAVE_DECL_XXX, but HAVE_XXX. Therefore, it appears
> that libiberty would be misdetecting declarations -- it thinks
> something is missing, whereas in fact it is not.
>
> Am I missing something here?
Try adding an AC_CHECK_DECLS call for basename. That will d
On Sun, Apr 10, 2005 at 05:52:01PM +0200, Gabriel Dos Reis wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> | On Sun, Apr 10, 2005 at 05:02:36PM +0200, Gabriel Dos Reis wrote:
> | >
> | > Hi,
> | >
> | > The following is from libibtery.h
> | &
On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> or so... I still lean on that crutch.
A user! Can you explain why?
--
Daniel Jacobowitz
CodeSourcery, LLC
On Tue, Apr 12, 2005 at 06:34:29PM +0200, Andi Kleen wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> > On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> >> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> >
-*
> > for fpgnulib.c.
>
> So it seems adding coldfire-linux is the only way
> to address this...
Why? Adding support (if it isn't already there) for something like
--with-arch=coldfire should work just as well.
--
Daniel Jacobowitz
CodeSourcery, LLC
1 - 100 of 627 matches
Mail list logo
