First, please note that having gfortran testresults for one platform
only means that some version of the compiler was able to correctly
compile GMP MPFR, not that GCC trunk is able to correctly compile
GMP MPFR. Nevertheless:
* i386-unknown-freebsd (alpha-unknown-freebsd5.4)
Can anyone tell me where i can find the definition of tree.
Take a look in tree.h.
Ben
Hello Michael,
thanks for description. I wasn't aware, that the upper 32 bits are zeroed.
Does this means that even the stack has to be in the first 4 Gb, too. Or
does this mov instruction does a sign-extention.
Best regards,
i.A. Kai Tietz
In particular, I was just wondering how do compile GCC with debug. Not
how to debug it. I tried CFLAGS=-g ./configure ..., but it still
compiled with gcc -O2 -g. Anyways, if anyone knows a helpful configure
trick that will help get me ready to debug gcc, please let me know.
By default, GCC
Hi,
Regarding the PR:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
Is below patch adequate to fix the problem?
Works fine with me, but haven't done any regression test.
Thanks in Advance
(Hiroki Kaminaga)
t
--
Index: gcc/gcc/config/mips/mips.h
Hi,
I must get the informations (position in the file,
file where #pragma was found, text that follow the
#pragma in the line) of pragma's line code in C/C++
code.
For do that I think that it's a good idea using the
C/C++ gcc preprocessor.
How can I patch the gcc so it can execute a my
function
Currently, and it's been there for a while, I get the following error
on gcc trunk:
/usr/local/src/trunk/objdir/./gcc/xgcc -shared-libgcc
-B/usr/local/src/trunk/objdir/./gcc -nostdinc++
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src
Christian Joensson writes:
Currently, and it's been there for a while, I get the following error
on gcc trunk:
../../../gcc/libjava/java/lang/natClass.cc:904: error: thread-local
storage not supported for this target
make[3]: *** [java/lang/natClass.lo] Error 1
make[3]: Leaving
Andrew Haley wrote:
That __thread variable is surrounded by HAVE_TLS. There is a
configure test which simply compiles this line:
__thread int foo;
and that configure test must succeed for HAVE_TLS to be set. So, to
fix this we need to find out if that program did compile, and if so,
On Thu, Oct 12, 2006 at 09:48:13AM +0200, Paolo Bonzini wrote:
In particular, I was just wondering how do compile GCC with debug. Not
how to debug it. I tried CFLAGS=-g ./configure ..., but it still
compiled with gcc -O2 -g. Anyways, if anyone knows a helpful configure
trick that will help
Currently we permit implicit conversions between vectors whose total
bitsizes are equal but which are divided into differing numbers of subparts.
It seems that in some circumstances this rule is overly lax. For example
the following code, using vector types (whose definitions I have provided
Hi,
On Thu, 12 Oct 2006, Kai Tietz wrote:
thanks for description. I wasn't aware, that the upper 32 bits are
zeroed. Does this means that even the stack has to be in the first 4 Gb,
too.
Why should it? I.e. no, it doesn't have to.
Or does this mov instruction does a sign-extention.
Bob Rossi [EMAIL PROTECTED] writes:
Hopefully I'll be able to debug gcc nicely after this is built. Two
more questions that could save me a lot of time. Do you know where the
abstract syntax tree is stored in GCC after a file is parsed?
I'm not sure what kind of answer you are looking for.
Mark Shinwell [EMAIL PROTECTED] writes:
Here, the compiler is not complaining about an attempt to implicitly
convert a vector of four 16-bit quantities to a vector of eight
8-bit quantities.
This lack of type safety is unsettling, and I wonder if it should be fixed
with a patch along the
Ian Lance Taylor wrote:
I believe that the problem with changing this unconditionally is that
the Altivec programming guidelines specify the rules which gcc
currently follows: you are permitted to assign one vector variable to
another, without an explicit cast, when the vectors are the same
On Thu, 2006-10-12 at 08:02 -0700, Ian Lance Taylor wrote:
It's been this way at least since 4.0.
But it was rejected in 3.4.0.
I believe that the problem with changing this unconditionally is that
the Altivec programming guidelines specify the rules which gcc
currently follows: you are
On Thu, Oct 12, 2006 at 06:56:58AM -0400, Bob Rossi wrote:
On Thu, Oct 12, 2006 at 09:48:13AM +0200, Paolo Bonzini wrote:
In particular, I was just wondering how do compile GCC with debug. Not
how to debug it. I tried CFLAGS=-g ./configure ..., but it still
compiled with gcc -O2 -g.
On Thu, Oct 12, 2006 at 12:22:57PM -0400, Bob Rossi wrote:
and the gcc that is put into prefixdir is compiled with -O2 and -g,
which makes it hard to follow in the debugger. Anyone have a clue on how
to compile gcc so only -g is used, and not -O2? Typically, I use the
CFLAGS trick, but it
On Thu, 12 Oct 2006, [ISO-8859-1] François-Xavier Coudert wrote:
First, please note that having gfortran testresults for one platform
only means that some version of the compiler was able to correctly
compile GMP MPFR,
True.
not that GCC trunk is able to correctly compile GMP MPFR.
I'm
On Thu, Oct 12, 2006 at 12:25:04PM -0400, Daniel Jacobowitz wrote:
On Thu, Oct 12, 2006 at 12:22:57PM -0400, Bob Rossi wrote:
and the gcc that is put into prefixdir is compiled with -O2 and -g,
which makes it hard to follow in the debugger. Anyone have a clue on how
to compile gcc so only
On Wed, 11 Oct 2006, Steve Kargl wrote:
Kaveh,
It should be straight forward to modify the current configure tests
in toplevel for the versions of gmp and mpfr you need. I would
recommend at least mpfr 2.2.0 (which would allow me to kill the ugly
hacks in gfortran). For gmp, you may be
On Thu, Oct 12, 2006 at 02:14:53PM -0400, Kaveh R. GHAZI wrote:
On Wed, 11 Oct 2006, Steve Kargl wrote:
It should be straight forward to modify the current configure tests
in toplevel for the versions of gmp and mpfr you need. I would
recommend at least mpfr 2.2.0 (which would allow me
Okay for stage1?
Ok, assuming everyone agrees to those versions ;-)
2006-10-12 Kaveh R. Ghazi [EMAIL PROTECTED]
* configure.in: Require GMP-4.1+ and MPFR-2.2+.
* configure: Regenerate.
Snapshot gcc-4.0-20061012 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20061012/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Oct 11, 2006, Ian Lance Taylor [EMAIL PROTECTED] wrote:
int x; int f() { x = 0;
while(1); }
We get line number notes for code only up to x = 0;.
I assume this is only a problem when not optimizing.
The opposite, actually. It's optimization that breaks it.
Of course
Hi all,
If I have a FUNCTION_DECL node that returns non-null for
DECL_TEMPLATE_INFO() then it is a template or template instantiation.
How can I tell if it is a full instantiation (I.e. not general
template or partial specialisation)?
Does this also apply to nodes that represent template types
From: Andrew Pinski [EMAIL PROTECTED]
As I mentioned in the bug report, the problem is that CC1_SPEC
is the wrong one.
(snip)
The attached patch is the more correct way to solve this.
Thanks alot!
(Hiroki Kaminaga)
t
--
Sorry about the separate email.
In addition to the previous questions I want to ask if there is a
better way of achieving finding the type nodes for a functions
exception specification list.
For each FUNCTION_DECL node I find, I want to determine what its
exception specification list is. I.e.
From: Andrew Pinski [EMAIL PROTECTED]
On Thu, 2006-10-12 at 17:06 +0900, Hiroki Kaminaga wrote:
Hi,
Regarding the PR:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
Is below patch adequate to fix the problem?
Works fine with me, but haven't done any regression test.
As I
On Fri, 2006-10-13 at 14:32 +0900, Hiroki Kaminaga wrote:
The attached patch is the more correct way to solve this.
Your patch would cause `-profile' option not to set `-p' to cc1. Is this OK?
Not really, the following patch on top of the previous fixes the above
problem:
Index:
On Fri, 2006-10-13 at 14:45 +0900, Hiroki Kaminaga wrote:
How about appending to CC1_SPEC?
-#ifndef CC1_SPEC
+#undef CC1_SPEC
#define CC1_SPEC \
%{gline:%{!g:%{!g0:%{!g1:%{!g2: -g1} \
%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
%{save-temps: } \
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 06:58 ---
if (TARGET_BIG_ENDIAN)\
{ \
builtin_define_std (MIPSEB);\
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-12 07:05 ---
[EMAIL PROTECTED] gcc]$ ./xgcc -B. -EL -dM -E -C -x c /dev/null | grep MIPSE
#define __MIPSEL__ 1
#define MIPSEL 1
#define _MIPSEL 1
#define __MIPSEL 1
[EMAIL PROTECTED] gcc]$ ./xgcc -B. -EB -dM -E -C -x c /dev/null
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-12 07:08 ---
Yep that is what is happening:
mips64*-*-linux*)
tm_file=dbxelf.h elfos.h svr4.h linux.h ${tm_file} mips/linux.h
mips/linux64.h
.
;;
mips*-*-linux*) # Linux MIPS,
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-12 07:27 ---
Actually it was only caused recently for mips-linux (non64bit):
2002-08-02 Eric Christopher [EMAIL PROTECTED]
* config.gcc (mips*-*-linux*): Fix ordering of tm_file.
* config/mips/mips.h
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-12 07:33 ---
*** Bug 23824 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 07:33 ---
The problem is that -EB and -EL are not recognized by the compiler because of a
bug. you can work around this issue by using -meb or -mel.
Anyways this is a dup of bug 29413 which shows the problem and shows what
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-12 08:13 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-12 08:20 ---
Execution times (seconds)
garbage collection: 0.88 ( 1%) usr 0.00 ( 0%) sys 0.87 ( 1%) wall
0 kB ( 0%) ggc
preprocessing : 0.10 ( 0%) usr 0.04 ( 1%) sys 0.22 ( 0%) wall
796 kB (
--- Comment #2 from jakub at gcc dot gnu dot org 2006-10-12 09:26 ---
Subject: Bug 28709
Author: jakub
Date: Thu Oct 12 09:25:59 2006
New Revision: 117664
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117664
Log:
PR preprocessor/28709
* macro.c (paste_tokens): Do
--- Comment #7 from grayyoga at gmail dot com 2006-10-12 09:51 ---
Created an attachment (id=12415)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12415action=view)
preprocessed source file (version 2)
The previous test case had common C++ error in it, which prevents it from being
--- Comment #2 from geraldine-n dot bert at edfgdf dot fr 2006-10-12 09:57
---
(In reply to comment #1)
This
../configure --with-mpfr=/logiciels/public/gmp-4.1.4/lib --enable-shared
--with-gnu-as=/logiciels/public/binutils-2.9/bin/as
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-12 11:15
---
Created an attachment (id=12416)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12416action=view)
Patch for LBOUND/UBOUND
This patch fixes this bug completely. It builds fine, regtest and works fine
with a
--- Comment #3 from razya at il dot ibm dot com 2006-10-12 11:44 ---
(In reply to comment #0)
gcc -O3 test.c --ipa-cp -m64
test.c:
#include stdio.h
int
bar (int b, int c)
{
printf (%d %d\n, b, c);
}
int
foo (int a)
--- Comment #4 from joseph dot rajesh at gmail dot com 2006-10-12 12:10
---
(In reply to comment #3)
Forget this, the type of the rhs is of course an rvalue of type Base,
there is no need to copy the entire Derived object.
W.
Hi,
I was pointing to the same error. But I think I
--- Comment #6 from pault at gcc dot gnu dot org 2006-10-12 12:18 ---
(In reply to comment #5)
I try as soon as possible.
Thanks for your help.
This subroutine is one of an open-source project which contains about
1.000.000
lines of fortran : http://www.code-aster.org.
Mathieu,
Hi. Today, while working on libstdc++/28277 I encountered this problem, which
currently prevents me from extending the fix to ext/vstring. The below is a
rather small self-contained testcase, which current mainline does not compile
because of ambiguous overloading, whereas compilers based on the
--- Comment #9 from pault at gcc dot gnu dot org 2006-10-12 12:31 ---
(In reply to comment #8)
Paul, Jakub,
Is the patch in comment #7 considered to be the right approach?
I tried applying to my local tree, but a few chunks were rejected.
Jakub? What about it?
Paul
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-12 12:39 ---
EDG chooses to reject the code with
t.C(7): error: a variable-length array type is not allowed
const std::type_info info(typeid(va));
^
though I cannot find anything in
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|rejects-valid |
--- Comment #10 from jakub at gcc dot gnu dot org 2006-10-12 12:46 ---
No, that sounds wrong. Not all dummy arguments have such type, so such a
change
just leads to strict aliasing violations and there are also dummy arguments
that
are larger than long.
--
--- Comment #8 from cvs-commit at developer dot classpath dot org
2006-10-12 12:52 ---
Subject: Bug 2873
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Roman Kennke rabbit78 06/10/12 12:50:44
Modified files:
javax/swing/plaf/basic:
-include -c -O2
-fwrapv -march=x86-64 -gdwarf-2 -g2 -fPIC -W -Wall -gnatpg a-stwifi.adb
-o a-stwifi.o
+===GNAT BUG DETECTED==+
| 4.2.0 20061012 (experimental) (PLD-Linux) (x86_64-pld-linux-gnu) GCC error:|
| tree check: expected integer_cst
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-12 13:09 ---
No success yet:
test_basic_metafunctions.hpp:176: instantiated from here
../src/sd/../static_component.hpp:57: error: 'process_outputs' is not a member
of 'mpl_::void_'
and other errors.
--
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-10-12 13:15
---
Created an attachment (id=12417)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12417action=view)
New patch
This updated patch is the result of re-reading the Standard about assumed-size
arrays.
--
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-12 13:19
---
[Paul changed this bug into enhancement]
I'm changing this back (again) into a bug, not an enhancement, because it was
supported by g77, and we're trying to make a drop-in replacement for g77 in
most cases.
--
--- Comment #6 from ralf at linux-mips dot org 2006-10-12 13:33 ---
%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
Shouldn't the combination of both -EB and -EL be legal that is later options
override preceeding ones just like with other -ffoo / -fno-foo
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-12 14:11 ---
(In reply to comment #6)
%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
Shouldn't the combination of both -EB and -EL be legal that is later options
override preceeding ones just like
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2006-10-12 14:13 ---
Subject: Re: Internal Error: gfc_resolve_expr(): Bad expression type
On Thu, Oct 12, 2006 at 12:18:30PM -, pault at gcc dot gnu dot org wrote:
--- Comment #6 from pault at gcc dot
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 14:18 ---
This looks very closely related to PR 29236.
Confirmed, a regression from 2.95.3. I still want to say this is just another
example of PR 29236 but the testcases are semi different. Though the use of
templates with
--- Comment #2 from pcarlini at suse dot de 2006-10-12 14:21 ---
Indeed, I was about to add to the audit trail that the template template
parameter is essential.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29438
4.2 misscompiles libavcodec/h264.o from FFmpeg project.
The likely cause of this problem is lies in the file cabac.h (in attachment)
gcc-4.0 and 4.1.0 compile this file correctly.
Here's the commandline:
/home/guillaume/Prgm/gcc/bin/gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64
--- Comment #3 from pcarlini at suse dot de 2006-10-12 14:24 ---
... and I also agree that the issue seems *very* similar to 29236.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29438
--- Comment #1 from poirierg at gmail dot com 2006-10-12 14:25 ---
Created an attachment (id=12418)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12418action=view)
the offending file (results in a grey picture)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
--- Comment #2 from poirierg at gmail dot com 2006-10-12 14:28 ---
Created an attachment (id=12419)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12419action=view)
The header that seems to hold the code that's misscompiled
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-12 14:30 ---
I had ada included in the set of languages for the bootstrap regtest for
PR28230. So you need to find another one ;)
Or are you complaining about the next failure with a -fwrapv bootstrap?
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-12 14:34 ---
Does it work when compiled with -O0 instead of -O4? How about -O1?
Besies above, I noticed that the asm in get_cabac looks to be clobbering memory
but is not marked as such.
--
--- Comment #2 from pluto at agmk dot net 2006-10-12 14:38 ---
(In reply to comment #1)
I had ada included in the set of languages for the bootstrap regtest for
PR28230. So you need to find another one ;)
try to bootstrap C+ADA with CFLAGS='-O2 -fwrapv' ;)
Or are you complaining
--- Comment #4 from pluto at agmk dot net 2006-10-12 14:40 ---
(In reply to comment #3)
Does it work when compiled with -O0 instead of -O4? How about -O1?
Besies above, I noticed that the asm in get_cabac looks to be clobbering
memory
but is not marked as such.
Andrew, this
--- Comment #5 from poirierg at gmail dot com 2006-10-12 14:53 ---
Hello,
(In reply to comment #3)
Does it work when compiled with -O0 instead of -O4? How about -O1?
The code compiles and produces the expected result with -O1, O2, but can't be
compiled with -O0:
In file included
Hi
conside the following code
$cat const_math_func.f90
program printpi
! This program is not standard complaint
real, parameter :: pi = 4.0*atan(1.0)
write(*,*) pi
end program
This code is not Fortran 95 standard compliant (
--- Comment #6 from poirierg at gmail dot com 2006-10-12 15:03 ---
(In reply to comment #4)
(In reply to comment #3)
Does it work when compiled with -O0 instead of -O4? How about -O1?
Besies above, I noticed that the asm in get_cabac looks to be clobbering
memory
but is
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 15:10 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-12 15:12 ---
Actually adding -pedantic, and this is rejected:
In file t.f90:3
real, parameter :: pi = 4.0*atan(1.0)
1
Error: Extension: Evaluation of nonstandard initialization expression at
--- Comment #11 from paulthomas2 at wanadoo dot fr 2006-10-12 15:57 ---
Subject: Re: LBOUND(TRANSPOSE(I)) doesn't work
FX
! if (upper)
! {
! cond1 = fold_build2 (GE_EXPR, boolean_type_node, ubound, lbound);
! cond2 = fold_build2 (LE_EXPR, boolean_type_node,
When compiling gcc-4.1.1, there is at least a serious slowdown, and on many
machines a failure, when insn-attrtab is compiled. There are several threads on
the Gentoo forums about this, some involving machines with 512M of memory. This
file seems to be automatically generated, and has become so
--- Comment #2 from ghazi at gcc dot gnu dot org 2006-10-12 16:28 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00662.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from grayyoga at gmail dot com 2006-10-12 16:50 ---
Created an attachment (id=12420)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12420action=view)
preprocessed source file (version 3)
Compiles without errors on my laptop, but still eats a LOT of memory.
--
--- Comment #4 from sje at gcc dot gnu dot org 2006-10-12 16:52 ---
Subject: Bug 29093
Author: sje
Date: Thu Oct 12 16:52:33 2006
New Revision: 117667
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117667
Log:
PR testsuite/29093
*
--- Comment #4 from dje at gcc dot gnu dot org 2006-10-12 16:58 ---
You should be using
--with-gmp=/usr/local
Are you sure that /usr/local/lib/libgmp.a exists and was built correct? Use
static libraries and make sure that you are building 32-bit libgmp and libmpfr.
--
dje at gcc
--- Comment #6 from oschmidt at gmx dot net 2006-10-12 17:03 ---
You therefore initialize a variable with itself. This is
a documented way to generate uninitialized variables and
Here's the right combination of flags that warns (for f3() only):
Thank you for your answer, this is
--- Comment #7 from oschmidt at gmx dot net 2006-10-12 17:10 ---
So a compiler warning for this makes really sense
not only for f3() but also for f4().
So I think it would be a good idea to reopen this bug report. It is then not a
bug report about inproper compiler behaviour but a bug
--- Comment #4 from dje at gcc dot gnu dot org 2006-10-12 17:20 ---
How is expand even generating this? This is completely invalid RTL for PPC.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from janis at gcc dot gnu dot org 2006-10-12 17:23 ---
Subject: Bug 28690
Author: janis
Date: Thu Oct 12 17:23:10 2006
New Revision: 117668
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117668
Log:
PR middle-end/28690
* explow.c (force_reg): Set
--- Comment #5 from sje at cup dot hp dot com 2006-10-12 17:36 ---
Fixed with a testsuite change to check for File Entry: or .file. Platforms
that set DWARF2_ASM_LINE_DEBUG_INFO will output a .file line but not a File
Entry: line and the test now checks for either.
--
sje at cup
--- Comment #5 from pogonyshev at gmx dot net 2006-10-12 18:58 ---
OK, thanks for the help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24056
--- Comment #5 from dje at gcc dot gnu dot org 2006-10-12 19:15 ---
The expander is producing invalid RTL. If the index variable offs is changed
from long long to long, the code compiles correctly and the memory loads
are placed in temporary pseudos. Only with long long does GCC punt
--- Comment #3 from pluto at agmk dot net 2006-10-12 19:45 ---
cwd: ada/rts:
$ ../../gnat1 -quiet -dumpbase a-stwifi.adb -O1 -fwrapv -ftree-vrp \
-gnatpg a-stwifi.adb -o a-stwifi.s
(gdb) bt
#0 int_const_binop (code=PLUS_EXPR, arg1=0x2b8302f027b0, arg2=0x2b8302f02810,
--- Comment #8 from bangerth at dealii dot org 2006-10-12 19:55 ---
(In reply to comment #6)
Thank you for your answer, this is very interesting (but where is it
documented?).
In the gcc manual.
But still *very* dangerous, because the destructor of this unitialized object
is
--- Comment #10 from grayyoga at gmail dot com 2006-10-12 19:56 ---
Subject: Re: using boost::MPL requires lots of memory
Try preprocessed source file v3. It compiles without error on my
laptop, but still takes a LOT of memory and time to compile.
On 12 Oct 2006 13:09:02 -,
I get the following ICE with -gstabs with gcc 4.1.2 20060901 (Debian 4.1.1-13)
but not with 4.0 and 4.2.
(sid)1186:[EMAIL PROTECTED]: ~] g++-4.1 -O -fPIC -gstabs libapt-front-state.cpp
libapt-front-state.cpp: In member function std::string
aptFront::cache::component::State::sizeString(double):
--- Comment #1 from tbm at cyrius dot com 2006-10-12 19:58 ---
Created an attachment (id=12421)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12421action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-10-12 20:03
---
Subject: Bug 27961
Author: lmillward
Date: Thu Oct 12 20:02:53 2006
New Revision: 117671
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117671
Log:
PR c++/27961
* decl.c (start_decl): Return
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-10-12 20:06
---
Subject: Bug 27961
Author: lmillward
Date: Thu Oct 12 20:06:36 2006
New Revision: 117672
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117672
Log:
PR c++/27961
* g++.dg/template/crash60.C:
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-10-12 20:06
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from steve at telxio dot com 2006-10-12 20:27 ---
Subject: RE: Hello world c++ prog core dumps
I have found the cause of the problem. It isn't a problem with gcc.
I use the binutils shipped with Solaris10 to strip the binaries and create
separate debug symbol files.
The following code:
int main( int argc, char** argv )
{
switch ( 1 )
{
case 1:
int bug = 0;
break;
}
return 0;
}
is valid C syntax and should compile, but gcc gives the error:
bug.c: In function
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-10-12 20:31
---
I have found the cause of the problem. It isn't a problem with gcc.
I use the binutils shipped with Solaris10 to strip the binaries and create
separate debug symbol files. If I do not strip g++/libstdc++,
1 - 100 of 130 matches
Mail list logo
