Hi all,
I'am tring to understand how g++ generate vtable for c++ on ia64. Here
is what I got in the CONSTRUCTOR_ELTS in a constructor node: (with g++ 3.3.2
fe)
=== source code ===
Class A
{
Public:
Virtual void f(){}
Virtual void g(){}
};
=== result ===
VAL: 0
SYMOFF: _ZTI1A(0x1901)+0(0x0)
On 27 April 2006 20:02, Mike Stump wrote:
> On Apr 26, 2006, at 6:26 PM, Jack Howarth wrote:
>> readelf -d foo.so | grep TEXTREL
>>
>> Does anyone know if some mechanism like this is possible for Darwin
>> shared libraries?
>
> A man page is a terrible thing to waste:
Yes, but it's an even mo
On 27 April 2006 20:33, Bernard Leak wrote:
> Dear List,
> do you all remember this?
>
> Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html
> if your memory needs to be jogged.
>
> One month and a few hours on... has anything changed?
Well, at least the front page of g
Hi
We have built "h8300-elf" toolchain based on gcc-4.1 (released). This
toolchain is based on following sources,
Binutils-2.16.92
Gcc-4.1-20060407
Newlib-1.14.0
Also we have built, GDB for "h8300-elf" using gdb-6.4.50.20060425
We have found following problems for all varients of h8 target,
1.
On Sat, 8 Apr 2006, Gerald Pfeifer wrote:
>> ftp://ftp.club-internet.fr/pub/gcc/ - severly out of date (3.3 is latest)
> ftpmaster, I just confirmed this. Would you mind having a look and
> letting us know how to proceed?
>
> If this was this a technical glitch, and you plan to restart
> mirrori
Hi all.
When compiling simple example (even c file with no code in it) with
dlx-elf-gcc -c -gdwarf-2 foo.c
I get the following error message:
internal compiler error: in assemble_integer, at varasm.c:2148
I've defined debugging support in the following way:
#define DBX_DEBUGGING_INFO 1
Dear List,
Dave Korn wrote
Well, at least the front page of gcc.gnu.org is now self-contradictory:
" Previous release series: GCC 3.4.5 (released 2005-11-30)
Branch status: GCC 3.4.6 is the last release from the 3.4 series; the
branch has been closed after the release. "
Not unless "
On Apr 27, 2006, at 7:05 PM, Qiuker wrote:
Is there much difference from different PIC implement?
They all do exactly the same thing, allow code to be run at different
addresses, so they are all identical, or, yeah, they can be totally
different from just doing normal codegen and saving the
On 28 April 2006 17:45, Bernard Leak wrote:
> Dear List,
>
> Dave Korn wrote
>> Well, at least the front page of gcc.gnu.org is now self-contradictory:
>>
>> " Previous release series: GCC 3.4.5 (released 2005-11-30)
>> Branch status: GCC 3.4.6 is the last release from the 3.4 series; the
On Apr 28, 2006, at 3:18 AM, Dave Korn wrote:
Yes, but it's an even more terrible thing to wrap:
Welcome to format=flowed. :-( Apparently some companies think that
everyone uses an intelligent mail reader. I believe that if you read
it with just the right software, you'd see it as inte
It is my pleasure to announce that the steering committee has
appointed Richard Guenther libgcc-math maintainer.
Please adjust the MAINTAINERS file accordingly, Richard, and
Happy Hacking!
Gerald
Hello,
Consider the following test case:
struct A { bool g(int*, int*) __attribute__((nonnull (2))); };
bool A::g(int* a, int* b) {
if (a)
return 0;
return this;
}
G++ produces the following code for this snippet:
;; Function bool A::g(int*, int*) (_ZN1A1gEPiS0_)
bool A::g(int*, int*)
Steven Bosscher wrote:
> The documentation of the nonnull attribute says:
>
> `nonnull (ARG-INDEX, ...)'
> The `nonnull' attribute specifies that some function parameters
> should be non-null pointers. For instance, the declaration:
>
> extern void *
> my_memcpy (v
On 4/28/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote:
> The documentation of the nonnull attribute says:
>
> `nonnull (ARG-INDEX, ...)'
> The `nonnull' attribute specifies that some function parameters
> should be non-null pointers. For instance, the declaration:
Steven Bosscher wrote:
> That is why I was looking at this. We have http://gcc.gnu.org/PR27336,
> and part of the fix could be to make the 'this' pointer always
> non-NULL. So far I haven't found anyone who can think of a situation
> where 'this' can be NULL...
It can't be NULL. (There are ways
DJ Delorie wrote:
> Another one like libssp.
>
> In libstdc++-v3's configure.ac, we see this:
>
> # This depends on GLIBCXX CHECK_LINKER_FEATURES, but without it assumes no.
> GLIBCXX_ENABLE_SYMVERS([yes])
>
> The comment lies. If we haven't yet checked the linker features, it
> will check them
The SC would like to ensure that before we accept any major
contribution, like a new runtime library or back end we have a
maintainer lined up for that component. The purpose of this policy is
to avoid taking code for which, for whatever reason, we cannot find an
available maintainer, or which the
> The key problem is that we have two ways
And then he lists *three* ;-)
> * Hard-coded information about the target
I seem to recall a long time ago, talk of a global target capabilities
database. It proved too unwieldy to implement. However, a toplevel
configury snippet (aka config.gcc) mig
Snapshot gcc-4.1-20060428 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060428/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
DJ Delorie wrote:
>> The key problem is that we have two ways
>
> And then he lists *three* ;-)
:-)
>> To accomplish that, we need to avoid autoconf tests for features that
>> require running target programs;
>
> The problem I'm running into is that I can't even *link* a target
> program at tha
> Right, I understand. Assuming that they exist at this point, you
> could theoretically pass enough options to make it work -- although,
> as you say, it's hard to know what those options ought to be. If
> everything is set up right, it's -I options (for libc headers), -L
> options (for libc an
DJ Delorie wrote:
>> Right, I understand. Assuming that they exist at this point, you
>> could theoretically pass enough options to make it work -- although,
>> as you say, it's hard to know what those options ought to be. If
>> everything is set up right, it's -I options (for libc headers), -L
>
> Well, that sounds like an autoconf bug. If it refuses to work when
> presented with a pile of compiler options, that just sounds bad.
No, I think it's our bug - we do this:
GCC_NO_EXECUTABLES
GLIBCXX_ENABLE_SYMVERS([yes])
You can't logically expect that to work, no matter how many compiler
o
DJ Delorie wrote:
>> Well, that sounds like an autoconf bug. If it refuses to work when
>> presented with a pile of compiler options, that just sounds bad.
>
> No, I think it's our bug - we do this:
>
> GCC_NO_EXECUTABLES
> GLIBCXX_ENABLE_SYMVERS([yes])
>
> You can't logically expect that to wo
> I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that
> when we've failed to link things?
No, it's explicit:
if test "$build" != "$host"; then
# We are being configured with some form of cross compiler.
GLIBCXX_IS_NATIVE=false
case "$host","$target" in
*-*-darwin*,
DJ Delorie wrote:
>> I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that
>> when we've failed to link things?
>
> No, it's explicit:
I apologize; I didn't realize that. In that case, you're right; the
current approach is just busted. It should become an --enable option,
or a
On Fri, 28 Apr 2006, DJ Delorie wrote:
> > I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that
> > when we've failed to link things?
>
> No, it's explicit:
>
> if test "$build" != "$host"; then
> # We are being configured with some form of cross compiler.
> GLIBCXX_IS_NATI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
Its my first message to the list.
I am happy for this year found the FSF, and more especially, the gcc
project, in the Google Summer of Code[1].
Let me introduce myself, I'm 23 years old Brazilian student of
Management, but I also did a c
On Fri, Apr 28, 2006 at 08:36:50PM -0400, DJ Delorie wrote:
>
> > Well, that sounds like an autoconf bug. If it refuses to work when
> > presented with a pile of compiler options, that just sounds bad.
>
> No, I think it's our bug - we do this:
>
> GCC_NO_EXECUTABLES
> GLIBCXX_ENABLE_SYMVERS([y
> What are you building here? A combined tree including newlib? If
> so, I bet you aren't specifying --with-newlib; that turns off a
> bunch
The toplevel configure automatically adds that in a combined tree (or
at least it should), if newlib is being built.
The two targets I'm currently workin
I apologize; I didn't realize that. In that case, you're right; the
current approach is just busted. It should become an --enable option,
or a hard-coded case statement, or an autoconf test that doesn't require
linking stuff.
Really? Like --enable-symvers[=style]?
http://gcc.gnu.org/onlinedoc
Eder wrote:
Partial Transitions[http://gcc.gnu.org/wiki/Partial%20Transitions]
called my attention.
I am very interested in submitting a project for the SoC in this category.
I read the general ideas and have a project in my mind to execute the
task listed in the wiki.
You might want to start
On Fri, Apr 28, 2006 at 11:21:18PM -0400, DJ Delorie wrote:
>
> > What are you building here? A combined tree including newlib? If
> > so, I bet you aren't specifying --with-newlib; that turns off a
> > bunch
>
> The toplevel configure automatically adds that in a combined tree (or
> at least i
33 matches
Mail list logo
