On Sun, 2005-07-03 at 07:31, Martin Koegler wrote:
> * need to rewrite recursivly each element of type (which my contain
> structures,
> unions, ...) if a address space is set
> In http://gcc.gnu.org/ml/gcc/2005-04/msg01438.html, this was rated as bad
> idea.
It is possible I was wrong. Co
James Kosin wrote:
I'm having problems with building a release.
~make -C gcc gnatlib-shared
http://support.intcomgrp.com/mirror/fedora-core/beta/src/gcc-3.3.6-1.fc1.src.rpm
Neither FC1 nor gcc-3.3 are supported products anymore.
The problem seems to be that ar needs to load the rts/adaint
Stephen Torri wrote:
I am interested in reading the actual grammar files used for parsing C
and C++ programming languages inside gcc. Where are these files located?
See cp/parser.c for the C++ parser. The c-parse files are only for C
and Objective-C.
--
Jim Wilson, GNU Tools Support, http://
Andrew Pinski <[EMAIL PROTECTED]> writes:
> And it dates back to before EGCS was split from GCC (aka version
> 1.1 of linux.h:
> 1.1 (law 11-Aug-97): %{rdynamic:-export-dynamic} \
1.23 (kenner 30-Mar-95): %{rdynamic:-export-dynamic} \
> [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
On Jul 6, 2005, at 6:04 PM, Wolfgang Bangerth wrote:
Hi all,
in order for the glibc function backtrace() to return something
useful, its
documentation says one has to use the -rdynamic flag. However, as has
been
mentioned before here
It maps to the GNU binutils ld option -export-dynamic.
Hi all,
in order for the glibc function backtrace() to return something useful, its
documentation says one has to use the -rdynamic flag. However, as has been
mentioned before here
http://gcc.gnu.org/ml/gcc-help/2002-11/msg00196.html
http://gcc.gnu.org/ml/libstdc++/2002-04/msg00100.html
and
Eric writes:
> > 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
> 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
t
Joe Buck wrote:
On Wed, Jul 06, 2005 at 12:49:52PM -0700, Doug Evans wrote:
Building a cross compiler from scratch "just works" (as in all one
has to do is "configure, make all install") if all of binutils, gcc,
newlib, libgloss, libstdc++, etc. are siblings.
[At least this use to "just work".]
On Wed, Jul 06, 2005 at 12:49:52PM -0700, Doug Evans wrote:
> Building a cross compiler from scratch "just works" (as in all one
> has to do is "configure, make all install") if all of binutils, gcc,
> newlib, libgloss, libstdc++, etc. are siblings.
> [At least this use to "just work".]
>
> The nu
> I've grepped through the entire tree and can't see how the configure
> variable with_multisrctop is ever set to anything than itself.
./config-ml.in sets it as part of the multilib setup, used by
libiberty, newlib, etc.
Please read the ./etc/configure.texi documentation, which explains it.
>
Building a cross compiler from scratch "just works" (as in all one
has to do is "configure, make all install") if all of binutils, gcc,
newlib, libgloss, libstdc++, etc. are siblings.
[At least this use to "just work".]
The number of hoops one has to go through when this isn't the
case can be pain
On Tue, Jul 05, 2005 at 05:14:44PM +0200, Richard Guenther wrote:
> I'm lost in the mysteries of expansion of the indirect call, also
> ix86_value_regno gets called all over the place, so the "interesting"
> call-site is hard to find.
We'll have to change the FUNCTION_VALUE interface to handle thi
> sure, attached, this is with HJ's binutils-2.16.90.0.3-1 for linux
> tarball test release rpm built for corona.
>
> again, would you rather I backed off to a binutils-2.15.92.0.2-5?
I think it would be better to use Binutils releases when testing GCC releases,
because that's what the users are
Jakub Jelinek wrote:
>The best would be if Christian could post (bzip2ed) readelf -Ws of
>the libstdc++.so that fails the abi_check.
>
>
In fact, the excerpt from libstdc++.log that he sent privately doesn't
show the "check-abi Summary": as far as I know, abi_check can be
segfaulting (as is appa
On Wed, Jul 06, 2005 at 04:33:43PM +0200, Paolo Carlini wrote:
> Eric Botcazou wrote:
>
> >>Yes, I would definitely encourage a little more analysis. I'm rather
> >>puzzled. We have got very nice testsuites on sparc-solaris and on
> >>*-linux, in general, and those failures certainly are not expec
Date: Wed, 06 Jul 2005 12:09:32 -0400
To: [EMAIL PROTECTED]
From: Kevin Neelands <[EMAIL PROTECTED]>
Subject: GCC on linux, question on -m32 switch
I am using GCC 3.2.3 on a Linux Sparc system. The program I am
working on needs to be compiled in 32 bit mode for historical reasons. I
Joe Buck wrote:
>That's not the question I had. The question is whether the shipping 4.0.0
>had this bug (since I don't recall people screaming about the 4.0.0
>release being unusable on that platform).
>
>I don't include bug reports that only arose during development, on CVS
>or snapshots.
>
I s
On Wed, Jul 06, 2005 at 11:50:40AM +0200, Paolo Carlini wrote:
> Joe Buck wrote:
>
> >21523 [4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
> >
> >
> I can confirm that Mark fixed this problem for 4.0.1 on 2005-05-15.
That's not the question I had. The question is whether
Original Message
>From: Giovanni Bajo
>Sent: 06 July 2005 16:14
> wangxiuli wrote:
>
>> why? are those errors related to the version of gcc?
>> please help
>
> This mailing list is dedicated to the development of GCC itself. Questions
> about problems using GCC should generally be direct
On Wed, 2005-07-06 at 23:30 +0800, alert7 wrote:
> Daniel Berlin,您好！
>
> I'am gcc beginner,thank your answer .
>
> Is it the return Value of GetCallArgOperand function that u given stmt
> tree?
No.
>
> I pass return value--ops to function FOR_EACH_SSA_TREE_OPERAND
> F
Daniel Berlin,您好！
I'am gcc beginner,thank your answer .
Is it the return Value of GetCallArgOperand function that u given stmt
tree?
I pass return value--ops to function FOR_EACH_SSA_TREE_OPERAND
FOR_EACH_SSA_TREE_OPERAND (use, ops, iter, SSA_OP_ALL_USES){
wangxiuli <[EMAIL PROTECTED]> wrote:
> why? are those errors related to the version of gcc?
> please help
This mailing list is dedicated to the development of GCC itself. Questions
about problems using GCC should generally be directed to
[EMAIL PROTECTED] Anyway, this is not strictly a GCC questi
On Wed, 2005-07-06 at 10:35 -0400, Richard Kenner wrote:
> Try the attached patch.
>
> In the case where I saw this ICE, the tree generated by Ada was not valid
> (had a type mismatch on a MODIFY_EXPR). So the patch you sent may not
> necessarily be needed.
Well, it's actually still needed i
Hi
makefile is as following：
$ cat Make_Demo
#SOLARIS MAKEFILE
#C++ = /usr/local/bin/CC
C++ = /usr/local/newgcc-4/bin/g++-4.0.0
#C++=CC
#C++ = /usr/local/GNU/bin/g++
#C++FLAGS = -Wall -g -D__OLDSTYLE_CPP__
#C++FLAGS = -g -Wall
#C++FLAGS = -O -Wall
#C++FLAGS = -g -sb -DDEBUG
C++FLAGS = -g -O -DN
Paolo Carlini writes:
> Eric Botcazou wrote:
>
> >>hmm, I get a few libstdc++ testsuite failuers
> >>
> >>http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
> >>
> >>other than that, looks pretty fine.
> >>
> >>
> >Did you get them with 4.0.0 too? If no, the libstdc++ folks will
I hope to have my code checked in today.
Look in ipa-reference.c
Kenny
Daniel Berlin wrote:
Most of this can be found in the cgraph nodes. The rest requires
scanning the IL.
Ken Zadeck should have code to do this.
On Wed, 2005-07-06 at 08:32 -0400, Michael Tegtmeyer wrote:
Hello,
Is th
Try the attached patch.
In the case where I saw this ICE, the tree generated by Ada was not valid
(had a type mismatch on a MODIFY_EXPR). So the patch you sent may not
necessarily be needed.
Eric Botcazou wrote:
>>Yes, I would definitely encourage a little more analysis. I'm rather
>>puzzled. We have got very nice testsuites on sparc-solaris and on
>>*-linux, in general, and those failures certainly are not expected.
>>
>>
>Is the
>
>FAIL: abi_check
>
>failure expected? Should co
My GCC version is gcc version 4.0.1 20050630 (prerelease).
I got an error `internal consistency failure' in the backend pass 32.
This error was generated by flow.c:verify_local_live_at_start().
The RTL dump, .c.32.sched2, printed:
[begin]---
I've grepped through the entire tree and can't see how the configure
variable with_multisrctop is ever set to anything than itself.
It looks like an anchronism left over an earlier day before
multilibbing became more common. Worse there are all sorts of hoops
that every directory's configure scri
> Yes, I would definitely encourage a little more analysis. I'm rather
> puzzled. We have got very nice testsuites on sparc-solaris and on
> *-linux, in general, and those failures certainly are not expected.
Is the
FAIL: abi_check
failure expected? Should config/abi/sparc-linux-gnu/baseline_sy
Paolo Carlini wrote:
>However, missing additional details, it's very difficult to guess: can
>be almost anything, from a weirdness in the installed localedata...
>
Probably we can exclude at least this first possibility: if I understand
well, everything related to glibc has not changed on the mach
On 7/6/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Eric Botcazou wrote:
>
> >>hmm, I get a few libstdc++ testsuite failuers
> >>
> >>http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
> >>
> >>other than that, looks pretty fine.
> >>
> >>
> >Did you get them with 4.0.0 too? If no,
Eric Botcazou wrote:
>>hmm, I get a few libstdc++ testsuite failuers
>>
>>http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
>>
>>other than that, looks pretty fine.
>>
>>
>Did you get them with 4.0.0 too? If no, the libstdc++ folks will have to say
>whether they are really regr
On 7/6/05, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > hmm, I get a few libstdc++ testsuite failuers
> >
> > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
> >
> > other than that, looks pretty fine.
>
> Did you get them with 4.0.0 too? If no, the libstdc++ folks will have to sa
> hmm, I get a few libstdc++ testsuite failuers
>
> http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
>
> other than that, looks pretty fine.
Did you get them with 4.0.0 too? If no, the libstdc++ folks will have to say
whether they are really regressions (the testsuite harness has
| 4.1.0 20050706 (experimental) (x86_64-suse-linux-gnu) GCC error: |
| tree check: expected integer_cst, have cond_expr in |
|do_structure_copy, at tree-ssa-structalias.c:2410 |
I saw this when trying to get a bootstrap done. I beleieve the
On Wed, 2005-07-06 at 09:40 -0400, Michael Tegtmeyer wrote:
> Thanks-intraprocedural is all I need.
>
> Sorry, bit new to gcc internals (coming from SUIF), is anything missing
> from referenced_vars list or is it complete?
It is a complete list of variables *referenced from this function*.
> d
Avi Kivity <[EMAIL PROTECTED]> writes:
| On Wed, 2005-07-06 at 15:54 +0300, Michael Veksler wrote:
|
| > > most architectures have different bit representations for +0.0 and -0.0,
| > > yet the two values compare equal.
| > >
| >
| > Yet, their sign bit is observable through things like
| >
On Wed, Jul 06, 2005 at 09:40:08AM -0400, Michael Tegtmeyer wrote:
> Thanks-intraprocedural is all I need.
>
> Sorry, bit new to gcc internals (coming from SUIF), is anything missing
> from referenced_vars list or is it complete? docs in tree-dfa.c state
> that it doesn't look in statement opera
Thanks-intraprocedural is all I need.
Sorry, bit new to gcc internals (coming from SUIF), is anything missing
from referenced_vars list or is it complete? docs in tree-dfa.c state
that it doesn't look in statement operands. Does it just collect this from
the symbol tables?
Mike
On Wed, 6
hmm, I get a few libstdc++ testsuite failuers
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
other than that, looks pretty fine.
--
Cheers,
/ChJ
On Wed, 2005-07-06 at 08:46 -0400, Daniel Berlin wrote:
> Most of this can be found in the cgraph nodes. The rest requires
> scanning the IL.
> Ken Zadeck should have code to do this.
>
Oh, i assumed you were trying to work at an interprocedural level.
If you only ever care to see a single func
On Jul 6, 2005, at 8:40 AM, Daniel Berlin wrote:
Try the attached patch.
This fixed it for me.
-- Pinski
On Wed, 2005-07-06 at 15:54 +0300, Michael Veksler wrote:
> > most architectures have different bit representations for +0.0 and -0.0,
> > yet the two values compare equal.
> >
>
> Yet, their sign bit is observable through things like
> assert(a == 0.0);
> assert(b == 0.0);
> 1/(1/a+ 1/b)
Avi Kivity wrote on 06/07/2005 15:38:38:
> On Tue, 2005-07-05 at 20:05 +0200, Gabriel Dos Reis wrote:
> > Paolo Carlin
> > It is definitely a good thing to use the full bits of value
> > representation if we ever want to make all "interesting" bits part of
> > the hash value. For reasonable or
Avi Kivity <[EMAIL PROTECTED]> writes:
| On Tue, 2005-07-05 at 20:05 +0200, Gabriel Dos Reis wrote:
| > Paolo Carlin
| > It is definitely a good thing to use the full bits of value
| > representation if we ever want to make all "interesting" bits part of
| > the hash value. For reasonable or sane
On Wed, Jul 06, 2005 at 08:32:38AM -0400, Michael Tegtmeyer wrote:
> Is there existing functionality somewhere to sweep a function and collect
> all externally visible variables at the tree level or do I need to roll my
> own? I've looked in tree.h and grepped around as much as I could but I
>
Most of this can be found in the cgraph nodes. The rest requires
scanning the IL.
Ken Zadeck should have code to do this.
On Wed, 2005-07-06 at 08:32 -0400, Michael Tegtmeyer wrote:
> Hello,
>
> Is there existing functionality somewhere to sweep a function and collect
> all externally visible
patch for flag_wrapv fails now with a new
> >> error:
> >>
> >> +===GNAT BUG
> >> DETECTED==+
> >> | 4.1.0 20050706 (experimental) (x86_64-suse-linux-gnu) GCC
On Tue, 2005-07-05 at 20:05 +0200, Gabriel Dos Reis wrote:
> Paolo Carlin
> It is definitely a good thing to use the full bits of value
> representation if we ever want to make all "interesting" bits part of
> the hash value. For reasonable or sane representations it suffices to
> get your hand on
Hello,
Is there existing functionality somewhere to sweep a function and collect
all externally visible variables at the tree level or do I need to roll my
own? I've looked in tree.h and grepped around as much as I could but I
haven't found anything obvious.
Thanks in advance,
Mike Tegtmeyer
4.1.0 20050706 (experimental) (x86_64-suse-linux-gnu) GCC
error: |
| tree check: expected integer_cst, have cond_expr
in |
|do_structure_copy, at tree-ssa-structalias.c:
2410 |
Also on ia64 (without -fwrapv).
Andreas.
--
Andreas Schwab, SuS
Andreas Jaeger <[EMAIL PROTECTED]> writes:
> Building ada with the patch for flag_wrapv fails now with a new error:
>
> +===GNAT BUG DETECTED======+
> | 4.1.0 20050706 (experimental) (x86_64-suse-linux-gnu) GCC error:
Joe Buck wrote:
>21523 [4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
>
>
I can confirm that Mark fixed this problem for 4.0.1 on 2005-05-15.
Want to take the occasion to *thank you* for this important work!
Paolo.
LUDES_FOR_SUBDIR)" \
"exeext=$(exeext)" \
Laurent
On Wed, 2005-07-06 at 09:49 +0200, Andreas Jaeger wrote:
> Building ada with the patch for flag_wrapv fails now with a new error:
>
> +===GNAT BUG DETECTED==
Building ada with the patch for flag_wrapv fails now with a new error:
+===GNAT BUG DETECTED==+
| 4.1.0 20050706 (experimental) (x86_64-suse-linux-gnu) GCC error: |
| tree check: expected integer_cst, have cond_expr in
59 matches
Mail list logo
