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
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==
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.
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:
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
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
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
patch for flag_wrapv fails now with a new
> >> error:
> >>
> >> +===GNAT BUG
> >> DETECTED==+
> >> | 4.1.0 20050706 (experimental) (x86_64-suse-linux-gnu) GCC
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
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
>
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
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
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)
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 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
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
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
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
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, 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
| 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
> 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
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
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, 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,
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
> 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
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
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]---
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
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.
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
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
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
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
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
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){
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
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, 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
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
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
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
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
> 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
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
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
> 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.
>
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
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".]
> 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
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
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
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.
> [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
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} \
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://
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
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
59 matches
Mail list logo
