Hi.
This morning's build on my x86 Solaris build failed in stage2 like so:
/home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c: In function 'lto_type_for_mode':
/home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c:928:1: internal compiler error: in
dwarf2out_frame_debug_adjust_cfa, at dwarf2out.c:1881
Please submi
Hi.
This mornings bootstrap fails with the following error:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-
> I opened a bug
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
Thanks!
--
Eric Botcazou
On Sun, Nov 18, 2007 at 06:59:03PM +0100, Eric Botcazou wrote:
> > No, that's not correct. Configuring with --disable-checking is
> > perfectly reasonable in some circumstances. For instance, when testing
> > the effect of a patch without the assertion noise.
>
> Not sure what you call the "asse
> No, that's not correct. Configuring with --disable-checking is
> perfectly reasonable in some circumstances. For instance, when testing
> the effect of a patch without the assertion noise.
Not sure what you call the "assertion noise", (reasonable) assertions in a
compiler are a feature, --dis
On 11/17/07 09:16, Eric Botcazou wrote:
I'm still seeing the same failure on x86_64-unknown-linux-gnu, is this
going to get fixed?
You're not supposed to configure the compiler with --disable-checking as this
disables the internal assertions, use --enable-checking=release instead.
No, that's
On Sat, 17 Nov 2007, Jonathan Wakely wrote:
> On 17/11/2007, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > I'm still seeing the same failure on x86_64-unknown-linux-gnu, is this
> > > going to get fixed?
> >
> > You're not supposed to configure the compiler with --disable-checking as
> > this
> >
On 17/11/2007, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > I'm still seeing the same failure on x86_64-unknown-linux-gnu, is this
> > going to get fixed?
>
> You're not supposed to configure the compiler with --disable-checking as this
> disables the internal assertions, use --enable-checking=rele
> I'm still seeing the same failure on x86_64-unknown-linux-gnu, is this
> going to get fixed?
You're not supposed to configure the compiler with --disable-checking as this
disables the internal assertions, use --enable-checking=release instead.
--
Eric Botcazou
On 09/11/2007, Andreas Tobler <[EMAIL PROTECTED]> wrote:
> >
> > Builds today fail during stage2 when compiling 'reg-stack.c'
> >
> > $ make bootstrap-lean ...
> > { ... lots of stuff snipped ... }
> > cc1: warnings being treated as errors
> > /export/home/arth/gnu/gcc.git/gcc/reg-stack.c: In funct
Art Haas wrote:
Hi.
My builds have been failing since about last night on my i386-pc-solaris2.10
system. I was able to build successfully yesterday - the compiler configuration
info is below:
$ gcc -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: /export/home/arth/gnu/gcc.g
Hi.
My builds have been failing since about last night on my i386-pc-solaris2.10
system. I was able to build successfully yesterday - the compiler configuration
info is below:
$ gcc -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: /export/home/arth/gnu/gcc.git/configure
--en
Hi
My builds on i386-pc-solaris2.10 have failed again once the SCCVN patch
was re-applied:
$ make bootstrap-lean ...
[ ... snip ... ]
make[2]: Entering directory `/export/home/arth/gnu/gcc-0907'
make[3]: Entering directory `/export/home/arth/gnu/gcc-0907'
rm -f stage_current
make[3]: Leaving dire
Hi.
I've had no luck with my builds since yesterday. The applied-then-reverted
patches regarding the tree_ssa_operands.c files caused build errors
yesterday. I was hopeful that the reversion would resolve my build errors,
but I'm sorry to report that my builds are still failing now with
a bootstra
14 matches
Mail list logo
