On 5/23/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 5/23/06, DJ Delorie <[EMAIL PROTECTED]> wrote:
> What seems to happen is, we delete the simple jump even if we can't
> fallthru, and thus the blocks get rearranged in an incorrect order.
>
> Is there a bug here, or am I misunderstanding ho
On 5/23/06, DJ Delorie <[EMAIL PROTECTED]> wrote:
What seems to happen is, we delete the simple jump even if we can't
fallthru, and thus the blocks get rearranged in an incorrect order.
Is there a bug here, or am I misunderstanding how this code works?
You're misunderstanding how this code wor
On May 22, 2006, at 9:36 PM, H. J. Lu wrote:
on Linux/ia64. The last working revision is 113936. Linux/x86 and
Linux/x86-64 pass the same spot. Has anyone else seen it?
Yes for hppa-linux-gnu, PR 27736.
This is most likely caused by:
2006-05-22 Richard Sandiford <[EMAIL PROTECTED]>
With trunk revision 113999, I got
if [ x"-fpic" != x ]; then \
/export/build/gnu/gcc/build-ia64-linux/./prev-gcc/xgcc
-B/export/build/gnu/gcc/build-ia64-linux/./prev-gcc/
-B/usr/gcc-4.2/ia64-unknown-linux-gnu/bin/ -c -DHAVE_CONFIG_H -g -O2
-I. -I/net/gnu-13/export/gnu/src/gcc/gcc/libiberty
Bruce Korb <[EMAIL PROTECTED]> writes:
> I do that also, but I am also careful to prune repository
> directories (CVS, .svn or SCCS even). I rather doubt it is my RAM,
> BTW. Perhaps a disk sector, but I'll never know now. (Were it RAM,
> the failure would be random and not just the one file.)
I've got a case where an unconditional simple jump is being removed,
yet it doesn't jump to the next insn. The code in question seems
suspect...
Here we force CLEANUP_CFGLAYOUT true:
void
cfg_layout_initialize (unsigned int flags)
{
. . .
cleanup_cfg (CLEANUP_CFGLAYOUT | flags);
}
in clean
Andrew Pinski wrote:
>> After the LTO proposal (http://gcc.gnu.org/projects/lto/lto.pdf) was
>> posted, a fruitful discussion ensued. One of the key topics that arose
>> was the the possibility of using LLVM instead of the TREE-SSA
>> optimizers. Things have quieted down on the public lists since
Hi, all:
I used an ofdstream.h written by others:
->>>---
#ifndef _OFDSTREAM_H
#define _OFDSTREAM_H
#include
#include
#include
class ofdstream: public std::ofstream
{
private:
__gnu_cxx::stdio_filebuf< char > m_buf;
Martin Michlmayr wrote:
* Paolo Carlini <[EMAIL PROTECTED]> [2006-05-22 22:37]:
Of course, it would be nice if reporters could double check that on
those machines gcc4.1.0 behaves the same.
I can confirm that the abi_check failure has gone away now that I have
generated the de_DE local
On May 22, 2006, at 4:18 PM, Mark Mitchell wrote:
We have had some very useful discussions with Chris Lattner and other
folks at Apple. Our conclusion is that LLVM does indeed have a very
clean design and is very promising technology, but that there is
still a
lot of technical work to do before
* Paolo Carlini <[EMAIL PROTECTED]> [2006-05-22 22:37]:
> Of course, it would be nice if reporters could double check that on
> those machines gcc4.1.0 behaves the same.
I can confirm that the abi_check failure has gone away now that I have
generated the de_DE locale.
This makes me wonder, though
>
> After the LTO proposal (http://gcc.gnu.org/projects/lto/lto.pdf) was
> posted, a fruitful discussion ensued. One of the key topics that arose
> was the the possibility of using LLVM instead of the TREE-SSA
> optimizers. Things have quieted down on the public lists since then,
> but the need
After the LTO proposal (http://gcc.gnu.org/projects/lto/lto.pdf) was
posted, a fruitful discussion ensued. One of the key topics that arose
was the the possibility of using LLVM instead of the TREE-SSA
optimizers. Things have quieted down on the public lists since then,
but the need for link-time
vec.h has a lot of unprotected 'static inline' functions. With its
inclusion in many build-machine files via rtl.h, this essentially
precludes building on a machine without gcc (and a recent enough one,
at that). It also requires using optimization for build/*.o, which
complicates debugging (tha
On Mon, 22 May 2006, Joe Buck wrote:
>> How embarrassing. I'll install the patch below in a minute, since I could
>> not find a true new master site for this FAQ.
> There's a mirror of the old FAQ at
>
> http://vmlinux.org/crash/mirror/www.objsw.com/CrossGCC/
>
> However, it has a 1999 date. I
Mark Mitchell wrote:
> Richard Sandiford wrote:
>
>> Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf.
>> Mark, what do you think?
>
> I'm a bit torn. On the one hand, it doesn't look like there is any
> other reason to do a 4.1.1 RC2. So, we could declare that Fortran is
> n
Mark Mitchell wrote:
Martin Michlmayr wrote:
* Mark Mitchell <[EMAIL PROTECTED]> [2006-05-22 11:36]:
I'm a bit torn. On the one hand, it doesn't look like there is any
other reason to do a 4.1.1 RC2.
Did anyone investigate those abi_check failures I (and others) have
seen? Se
Martin Michlmayr wrote:
> * Mark Mitchell <[EMAIL PROTECTED]> [2006-05-22 11:36]:
>> I'm a bit torn. On the one hand, it doesn't look like there is any
>> other reason to do a 4.1.1 RC2.
>
> Did anyone investigate those abi_check failures I (and others) have
> seen? See http://gcc.gnu.org/ml/gcc
* Mark Mitchell <[EMAIL PROTECTED]> [2006-05-22 11:36]:
> I'm a bit torn. On the one hand, it doesn't look like there is any
> other reason to do a 4.1.1 RC2.
Did anyone investigate those abi_check failures I (and others) have
seen? See http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01058.html
> From whence will release notes be published?
>From *where* of course.
FYI m32c still doesn't build libssp due to the GCC_NO_EXECUTABLES
thing. Works OK with it disabled, though, for C and C++. From whence
will release notes be published?
Gerald Pfeifer wrote:
> Mark, since it seems we'll have to make another try for GCC 4.1.1, okay to
> install this there as well?
Yes.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Mon, May 22, 2006 at 09:11:24PM +0200, Gerald Pfeifer wrote:
> On Mon, 15 May 2006 [EMAIL PROTECTED] wrote:
> > The link crossgcc FAQ in the middle of the page:
> > "http://gcc.gnu.org/install/build.html"; doesn't seem to link to a page that
> > offers the cross-gcc faq. Instead it appears to be
On Mon, 15 May 2006 [EMAIL PROTECTED] wrote:
> The link crossgcc FAQ in the middle of the page:
> "http://gcc.gnu.org/install/build.html"; doesn't seem to link to a page that
> offers the cross-gcc faq. Instead it appears to be a site of a consultant
> trying to sell his services.
How embarrassing
Richard Sandiford wrote:
> Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf.
> Mark, what do you think?
I'm a bit torn. On the one hand, it doesn't look like there is any
other reason to do a 4.1.1 RC2. So, we could declare that Fortran is
not release-critical, and just relea
> This is probably very low priority, maybe a release note?
>
> In the dim-and-musty-systems department, using
> cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
Too old a compiler. :-)
> One gets:
>
> cc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
> -DHAVE_CONFIG_H -I. -I. -I../../.
> I hereby request that you add automatic intl/ merging to your script. :-)
Ok :-)
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Roger Sayle <[EMAIL PROTECTED]> writes:
>> On Fri, 19 May 2006, Mark Mitchell wrote:
>>> I'm evaluating the options. It would be helpful if someone has time to
>>> apply and test Richard's patch on 4.1, as that would let us know whether
>>> that opti
So basically on alpha-dec-osf4.0 with Compaq C v6.1-120, I just
had to use an older gcc to build libiberty. Everything chokes with
PTR==(char *) vs (void *) all over the place...
Marc W. Mengel wrote:
This is probably very low priority, maybe a release note?
In the dim-and-musty-systems dep
This is probably very low priority, maybe a release note?
In the dim-and-musty-systems department, using
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)
We get:
cc -c -DHAVE_CONFIG_H -g -I.
-I/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/../include
/tmp/build-gcc-v4_1_1/src/gc
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> The patch (both that on mainline and this backport) includes _floatdidf in
> both the hardcoded lib2funcs list and that generated from lists of modes.
> This means that only one of the _floatdidf entries in the list gets
> deleted if _floatdidf is
On May 22, 2006, at 8:24 AM, Marc W. Mengel wrote:
This is probably very low priority, maybe a release note?
In the dim-and-musty-systems department, using
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)
GCC 4.0.x and above only support compiling with ansi C.
-- Pinski
This is probably very low priority, maybe a release note?
In the dim-and-musty-systems department, using
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)
We get:
c -c -DHAVE_CONFIG_H -g -I.
-I/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/../include
/tmp/build-gcc-v4_1_1/src/gcc-
This is probably very low priority, maybe a release note?
In the dim-and-musty-systems department, using
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)
We get:
cc: Error:
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/alloca.c, line
162: In this declaration, the type of "C_alloca
On May 22, 2006, at 7:46 AM, Marc W. Mengel wrote:
This is probably very low priority, maybe a release note?
Or maybe report this to Sun instead?
In the dim-and-musty-systems department, using
cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
One gets:
cc -c -g -DENABLE_CHECKING -DENABLE_AS
This is probably very low priority, maybe a release note?
In the dim-and-musty-systems department, using
cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
One gets:
cc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
-DHAVE_CONFIG_H -I. -I. -I../../../gcc-4.1.1-20060517/gcc
-I../../..
On Mon, May 22, 2006 at 09:39:33AM +0200, Rainer Emrich wrote:
> H. J. Lu schrieb:
> > On Fri, May 19, 2006 at 06:00:09PM +0200, Rainer Emrich wrote:
> >> Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on
> >> missing libunwind.so.7
> >>
> >
> > It is
> >
> > http://gcc.gn
On Sun, 21 May 2006, Roger Sayle wrote:
> The patch applies cleanly, with the exception of some mklibgcc.in
> hunks, due to the fact that the _floatun* symbols were added to 4.2
> and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE
> functionality isn't on the branch. For the rec
Hi Bob,
On 5/21/06, Bob Proulx <[EMAIL PROTECTED]> wrote:
Bruce Korb wrote:
> Philip Martin wrote:
> >The capital 'I' in 'Is' looks wrong.
> ...
> That's what I wanted: a nice, simple answer that was short of re-pulling
> the entire repository. [...]
Sometimes I run commands to walk down the f
Roger Sayle <[EMAIL PROTECTED]> writes:
> On Fri, 19 May 2006, Mark Mitchell wrote:
>> I'm evaluating the options. It would be helpful if someone has time to
>> apply and test Richard's patch on 4.1, as that would let us know whether
>> that option is viable as well.
>
> I've bootstrapped and regr
H. J. Lu schrieb:
> On Fri, May 19, 2006 at 06:00:09PM +0200, Rainer Emrich wrote:
>> Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on
>> missing libunwind.so.7
>>
>
> It is
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
>
>
> H.J.
>
Is there any workaround?
I
41 matches
Mail list logo
