ag, CODE_64BIT},
>
> but they only switch ASM encoding, not the output ELF file format as
> they are intended for stuff where you really mix 32bit and 64bit code,
> such as in the boot loader.
So, we would need different directives for this purpose. I like the
idea, though it woul
[Redirecting off gdb-discuss again]
On Tue, Jun 14, 2005 at 09:12:39PM -0400, Fred Fish wrote:
> On Tuesday 14 June 2005 10:55, Daniel Jacobowitz wrote:
> > better support for inline functions, which is already on the gdb
> > roadmap
>
> Where's the roadmap? I'
. Not all of us use Microsoft compilers.
> Didn't RTH objected the last time?
You can find plenty of information about this in the archives. I
recall Stan Shebs discussing it at length.
--
Daniel Jacobowitz
CodeSourcery, LLC
name.
BTW, you may get more comments if all of your text is before all of the
patches; I nearly missed three quarters of your message :-)
--
Daniel Jacobowitz
CodeSourcery, LLC
; lifetime of the statement expression?
Yes, that's correct (and the only way to do this).
--
Daniel Jacobowitz
CodeSourcery, LLC
Do you mean "do mind" or "don't mind" there?
If you want to update libtool, you get to play the all-of-src-uses-it
game. I have been updating src directories to more recent autoconf
versions in the hope of getting rid of our outdated libtool someday. I
believe the only remaining holdout is newlib, but I didn't check
everything.
--
Daniel Jacobowitz
CodeSourcery, LLC
ch over one at a time.
Somebody who cares really has to update newlib soon, though!
--
Daniel Jacobowitz
CodeSourcery, LLC
come up with a way to build the compiler and
libraries at different times.
--
Daniel Jacobowitz
CodeSourcery, LLC
someone should compare the two existing
bits of documentation first, since IIRC I've seen people add to one but
not the other.
--
Daniel Jacobowitz
CodeSourcery, LLC
te
instances. That is probably what you want for stabs: have one of the
base/complete ctors, but not both.
The effect on dwarf output might be more interesting.
GDB just ignores all but one of each set in stabs anyway.
--
Daniel Jacobowitz
CodeSourcery, LLC
t it is a useful option to have available.
Thanks for the explanation. That makes more sense. Personally, if
you're going to do this, I don't see why you're keeping debug info for
methods; either ditch all artificial methods (including defaulted
constructors but not manually specified constructors), or ditch all
methods.
--
Daniel Jacobowitz
CodeSourcery, LLC
e change of "Library" to "Lesser" in the name.
Yes - Joe, I believe you're thinking of the latest revisions of the GPL,
which do only differ in the address. LGPL 2.0 -> 2.1 predates the move
by a while.
--
Daniel Jacobowitz
CodeSourcery, LLC
toolchains. Or some third party linker may load DLLs
relative to its install path.
I'd say that using cp for mingw32 is not a huge step backwards. If
someone triggers a failure case, then we can do more work on it then.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Wed, Jul 20, 2005 at 10:10:03PM -0400, Christopher Faylor wrote:
> On Tue, Jul 19, 2005 at 04:21:04PM -0400, Daniel Jacobowitz wrote:
> >On Tue, Jul 19, 2005 at 04:14:04PM -0400, Christopher Faylor wrote:
> >>Ok. Given that 'cp' was an acceptable fallback in the
by default and avoid the need for this kind of
> system-specific behavior in the makefile?
On other systems, this makes the GCC build not relocatable at install
time. I don't know if that is true on mingw32 also, but I presume so.
--
Daniel Jacobowitz
CodeSourcery, LLC
to use this feature. GCC usually passes ld
> whatever path specifications it needs.
I build mingw cross toolchains with sysroots :-) That'll be affected
by this change. Of course, currently I cross-build them from
--build=i686-linux, so it doesn't affect me directly.
--
Daniel Jacobowitz
CodeSourcery, LLC
sfully pick up files from another
directory?
--
Daniel Jacobowitz
CodeSourcery
d out where to look for a functional version of the gcc
> cross compiler for this cpu.
If you can't build GCC for your target, I suggest you either use a
help list for that purpose (gcc-help or the crosstool or buildroot
lists), or find a pre-compiled ARM Linux toolchain.
--
Daniel Jacobowitz
CodeSourcery
" links at the above
> URLs) these appear to have genuinely originated at rt.gnu.org via the web
> interface:
Isn't this more likely the RT admins closing spam reports?
--
Daniel Jacobowitz
CodeSourcery
On Wed, Oct 07, 2009 at 04:29:29PM +0200, Basile STARYNKEVITCH wrote:
> I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c
It sounds to me like this confusion comes from "LTO plugins". Isn't
it just "LTO plugin"? That is, a specific pl
eally aimed at compiler developers. I think we would
benefit from more "what is the compiler doing to my code" options
(producing "note:"); things like which functions were inlined, which
loops unrolled. We do already have this for vectorization.
--
Daniel Jacobowitz
CodeSourcery
o put them into a separate
> file so the linker won't produce undefined references when they are not
> actually used by lto1.
Yes. Take a look at config/arm/arm-c.c, which does not go into
libbackend.a.
--
Daniel Jacobowitz
CodeSourcery
nostics are only of
> limited use without (say) #pragma unroll.
Not too limited, I'd say. I've seen a lot of developers willing to
mutilate their critical loops to accomodate the compiler.
--
Daniel Jacobowitz
CodeSourcery
other
> functions are not considered to be called once, perhaps a visibility
> issue. We also should say what limit was reached on inlining hlprog.
Maybe because of whatever did that cloning?
--
Daniel Jacobowitz
CodeSourcery
his?
>
> The color that spells -fuse-linker-plugin seems better, in line
> with other options. How it's implemented, especially regarding
> having to ignore it in middle-end is unimportant wrt. spelling,
> IMVHO.
I agree with H-P.
--
Daniel Jacobowitz
CodeSourcery
ling for other vector sizes.
> >3) Switch to the new mangling
>
> I vote for 2.
Does anyone know of another relevant compiler? What does it do?
For instance, if someone can hand me a test case, I could check how
ARM's compilers mangle it (or don't).
--
Daniel Jacobowitz
CodeSourcery
On Wed, Nov 25, 2009 at 08:31:27PM +0100, Richard Guenther wrote:
> And patch doesn't have an option to ignore whitespace changes.
Sure it does. -l (for loose, or --ignore-whitespace).
QUILT_PATCH_OPTS for quilt.
--
Daniel Jacobowitz
CodeSourcery
ntation caller and __aeabi_read_tp() must run in
> the same mode.
I don't believe that this is true. In what way is it not safe?
--
Daniel Jacobowitz
CodeSourcery
blems. Do you have a concrete problem?
> Is the implementation still incomplete?
No. It's been finished for two years or more.
--
Daniel Jacobowitz
CodeSourcery
esn't. You may have heard of a commercial testsuite built on this
principle :-)
--
Daniel Jacobowitz
CodeSourcery
tion
>
> However, the solution seems to work, except in O0, where I get this error:
This means whatever is calling gen_newrtl to create the insn is not
checking operand predicates first. That's probably code you wrote
too.
--
Daniel Jacobowitz
CodeSourcery
at and how do I handle the cost then ?
>- Just say that an unspec has a higher cost?
Are you really talking about rtx_costs? It sounds to me more like you
want to change your scheduler.
--
Daniel Jacobowitz
CodeSourcery
se EPILOGUE_USES to say that changes to the
accumulator should not be discarded. You could also use
unspec_volatile instead of unspec, but that may further inhibit
optimization.
--
Daniel Jacobowitz
CodeSourcery
For the sake of conversation I'll call them Alice and
Bob... no, I'll call them TARGET_MAVERICK and TARGET_NEON. Now you
need a minimum of three copies of the mov pattern that are
mostly the same.
It'd be nice if there was a way to compose instruction patterns :-(
--
Daniel Jacobowitz
CodeSourcery
h weird operand predicates. For instance,
in a patch I'm working on for ARM cmpdi patterns, I ended up needing
"cmpdi_lhs_operand" and "cmpdi_rhs_operand" predicates because Cirrus
and VFP targets accept different constants. Automatically generating
that would be a bit excessive though.
--
Daniel Jacobowitz
CodeSourcery
the 64-bit insns
> it still fails the openssl testsuite.
Interesting, I knew you had a lot of Cirrus patches but I didn't
realize the state of the checked-in code was so bad.
Is what's there useful or actively harmful?
--
Daniel Jacobowitz
CodeSourcery
of host systems where shell scripts aren't a viable
option for ld. Why make everyone write the wrapper script? Makes
sense to me to have gcc decide.
--
Daniel Jacobowitz
CodeSourcery
can also ignore it.
--
Daniel Jacobowitz
CodeSourcery
port for o32 entirely.
I don't think anyone's suggested that. o32 is the default ABI for
32-bit MIPS GNU/Linux targets which are still in wide use.
--
Daniel Jacobowitz
CodeSourcery
tion to select alternatives; (C) branch shortening to
determine branch alternatives.
I'm curious if anyone thinks there's a generic solution to this (that
doesn't involve a complete instruction selection rewrite :-).
--
Daniel Jacobowitz
CodeSourcery
you even know what the registers
are.
--
Daniel Jacobowitz
CodeSourcery
any support for shared libraries. It
will ignore profiling samples that lie outside the executable. And in
this case, that includes _mcount (which is in libc.so.6). That's
probably why.
--
Daniel Jacobowitz
CodeSourcery
for now at least. Too bad.
Despite all that exchange, I don't think you ever answered Andreas's
question - at least not in a way that I could understand. A size of
what? The size of the *type* on x86 is 16; the size of the *data
bits* is 10. But what cares about the size of the d
;s a prototype:
http://sourceware.org/ml/gdb-patches/2006-10/msg0.html
--
Daniel Jacobowitz
CodeSourcery
ICE
trying to emit (set (const) (reg)).
It seems to me that the problem is marking a register in the RHS of a
set as an output constraint. The reg becomes function_invariant_p and
chaos ensues.
Is this right? If so, is there somewhere that should assert if an
operand's constraint is marked as an output, but not somewhere that
the RTL allows modification of the operand?
--
Daniel Jacobowitz
CodeSourcery
On Fri, Apr 02, 2010 at 12:06:28AM +0100, Bernd Schmidt wrote:
> On 04/01/2010 10:54 PM, Daniel Jacobowitz wrote:
> > I'm debugging a Thumb-2 glibc build failure on trunk for
> > arm-none-linux-gnueabi. I believe it's from Richard Earnshaw's
> > 2010-02-01 pa
to tears if they're both outputs.
Hrm. Yeah, those really should be two pseudos. I'll fix that.
--
Daniel Jacobowitz
CodeSourcery
d are "externally visible".
Then you can think about it as "does not alias any non-device
memory", or any number of variants on that.
--
Daniel Jacobowitz
CodeSourcery
just a parser and a syntax tree).
--
Daniel Jacobowitz
CodeSourcery
without optimization. There's some unique GDB tests
that use this. It causes them to be live between statements in a
machine register instead of always stored in stack slots.
This might not be current information though.
--
Daniel Jacobowitz
CodeSourcery
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
scope
Nothing pulls in the definition of _U, _N, etc before that point.
I'm sure it's not as broken as it seems, so I must be missing
something... at one point, ./configure --target=i586-mingw32
--with-newlib was all it took.
--
Daniel Jacobowitz
CodeSourcery
insup/cygwin/include/ctype.h
/space/fsf/commit/src/winsup/mingw/include/ctype.h
That third one does not define _U. It uses _UPPER instead. Does this
mean --with-newlib does not work for mingw32? (Note, you can't build
without it either.)
--
Daniel Jacobowitz
CodeSourcery
On Mon, May 07, 2007 at 01:37:51PM -0400, Daniel Jacobowitz wrote:
> That third one does not define _U. It uses _UPPER instead. Does this
> mean --with-newlib does not work for mingw32? (Note, you can't build
> without it either.)
That does appear to be the case. With --with-
On Mon, May 07, 2007 at 07:47:01PM +0200, Paolo Carlini wrote:
> Daniel Jacobowitz wrote:
>
> > The failing command is trying to compile the PCH. This means that
> > we're including a large number of libstdc++ headers in a row. One of
> > the first ones pulls in
w32*)
AC_CHECK_HEADERS([sys/types.h locale.h float.h])
GLIBCXX_CHECK_LINKER_FEATURES
GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT
Those are the "bad" tests.
--
Daniel Jacobowitz
CodeSourcery
really silly typos (like
--with-libs=/usr/i586-mingw32msvc/include <--). So I think
crossconfig.m4 should be fixed for mingw32 to support combined tree
builds, but it's not as big a problem as I thought it was.
I'll take a stab at fixing crossconfig.m4 if I can find a chance.
--
Daniel Jacobowitz
CodeSourcery
ncy on
DW_AT_MIPS_linkage_name is actually a bug in GDB; I worked on this for
a while, but the patches had some rough spots and I never finished
them. I hope I can come back to it some day soon.
--
Daniel Jacobowitz
CodeSourcery
developer convenience, but GCC is a perfectly normal dynamically
linked program and should behave like one IMO.
--
Daniel Jacobowitz
CodeSourcery
ow to answer this question. Bootstrapping is an
unrelated problem, and the compiler is not a vital runtime component
of the system, so its dependencies do not need to be exceptionally
robust in the way that glibc's or even libstdc++'s do. If you were
talking about linking libstdc++ to MPFR I'd have a different story
to tell.
--
Daniel Jacobowitz
CodeSourcery
certainly going
to ship compilers statically linked to MPFR / GMP; we already have
machinery to build them that way. On the other hand I am positive
Debian will not ship its system compiler that way; Debian policy is
quite clear on this, dynamic libraries should always be used.
--
Daniel Jacobowitz
CodeSourcery
to trigger. REG_SAVED_VAL_OFFSET brings us here. Does anyone
see a way to fix this that doesn't involve making context->reg big
enough - and is _Unwind_Word always at least as large as _Unwind_Ptr
(i.e. mode(word) always at least as large as mode(pointer))?
--
Daniel Jacobowitz
CodeSourcery
ardware to magically appear on my door step.
No, qemu has 64-bit support but I don't think it's mature enough to
boot a Linux kernel yet. It might be; Thiemo and Aurelien were
working on it.
--
Daniel Jacobowitz
CodeSourcery
u might make a
mistake.
> Nor am I planning to use libelf: it's too straightforward to find the ELF
> sections I need and to read the ELF header. Use of libelf seems too
> top-heavy,
> although elf.h is very valuable to me.
If you write more complicated tools, you will want libelf later -
you might need to get at relocation data.
--
Daniel Jacobowitz
CodeSourcery
On Thu, Jun 14, 2007 at 02:24:19AM +0530, supriya kannery wrote:
> Is this scenario, of calling backtrace() on a stack containing invalid
> function
> pointer, a supported one?
In my opinion, no. Attach a debugger instead.
--
Daniel Jacobowitz
CodeSourcery
> That said, as none of the routines in question
> > ({eq,ge,le,unord}[sdxt]f2) are actually used by sparc32/sparc64/alpha that
> > use glibc soft-fp code,
Could anyone explain why this change was made? It seems like SItype
would be sufficient everywhere, and I can't see any
sn't make a lick of sense to me. If the type is hidden, how
on earth can it get a member function _of that type_ from another
library? That library would, by definition, have to have a type of
the same name... but it would be a "different" type.
--
Daniel Jacobowitz
CodeSourcery
t this part. The minimum I'd want to
accept this code would be a complete and useful example in the manual;
since Mark and Danny say this happens a lot on Windows, I'm sure there
must be one.
--
Daniel Jacobowitz
CodeSourcery
301 - 400 of 627 matches
Mail list logo
