--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-27 08:09 ---
We ICE in
if (base DECL_P (base)
TREE_READONLY (base)
(TREE_STATIC (base) || DECL_EXTERNAL (base)))
{
tree base_type = TREE_TYPE (base);
gcc_assert
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-27 08:12 ---
(In reply to comment #1)
We ICE in
Now, it is indeed questionable to put a non-POD into ro memory. So I think
this is INVALID - but let's see what others think.
The target should have rejected progmem and not
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-27 08:17 ---
(gdb) up
#1 0x082e8034 in dwarf2out_finish (filename=0xbfb6d1ca t.c)
at /space/rguenther/src/svn/summit/gcc/dwarf2out.c:14104
14104 gcc_assert (context TREE_CODE (context) ==
FUNCTION_DECL);
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-27 08:29 ---
Confirmed. Though it looks like this is a fundamental problem of the interface
provided. Should be documented so though. Also destroying an array allocator
instance does not reset the __array_used value, so only
--- Comment #3 from dave dot korn at artimi dot com 2006-03-27 10:05
---
Added by rth's sibcall optimisations back in March 2000:
http://gcc.gnu.org/viewcvs?rev=32612view=rev
Should we give him a ping?
cheers,
DaveK
--
--- Comment #4 from bart dot vanassche at gmail dot com 2006-03-27 10:53
---
(In reply to comment #3)
Confirmed. Though it looks like this is a fundamental problem of the
interface
provided. Should be documented so though. Also destroying an array allocator
instance does not
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-27 11:10 ---
Yes, though that would be an ABI change - that it's static _is_ the interface
provided. Should definitely be fixed in v7 though.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pcarlini at suse dot de 2006-03-27 11:17 ---
Guys, yes we can try to improve a bit this small extension class, but it's
definitely not high-priority, it's just a simple extension, not used elsewhere
in the library. And, yes, as such, we can also fix it before v7, we
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-03-27 11:27
---
Here are two more reduced testcases. The first ICEs since GCC 3.4.0,
the second since at least GCC 2.95.3:
=
struct A {};
namespace N
{
templateint void foo();
}
void bar(A
For the follwoing code snippet a bogus diagnostic is emitted since
GCC 4.1.0:
int main()
{
int a[2] = { 2, 3 };
int b[2] = a;
}
bug.cc: In function 'int main()':
bug.cc:4: error: cannot convert 'int [2]' to 'int [2]' in
--- Comment #4 from pcarlini at suse dot de 2006-03-27 12:34 ---
Working on it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
Up until
2005-06-13 Mark Mitchell [EMAIL PROTECTED]
* config/i386/x86-64.h (ASM_SPEC): Explicitly pass --64 to the
assembler in 64-bit mode.
change -m64 -m32 used to work on x86_64 (I know it is quite fragile and
on many arches doesn't DTRT), but now as the asm spec has:
--- Comment #5 from malitzke at metronets dot com 2006-03-27 15:17 ---
The fairly extensive changes submitted by Mr Sebastian Pop solved the PR 26859
as originally reported by myself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26859
--- Comment #10 from dir at lanl dot gov 2006-03-27 15:24 ---
This error seems to have gone away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23201
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
Missing warning for no return statement in function returning non-void
The following code when compiled with -Wreturn-type -c
prints a warning about function test2 which is a non-void function missing a
return statement, but it does not print a warning about test1.
tmp.C: In function `int
--- Comment #7 from jakub at gcc dot gnu dot org 2006-03-27 16:12 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
The behavior of const_reverse_iterator is different from the behavior of
const_iterator, due to having no mixed const/non-const equality or inequality
operators. Consider the following code:
#include map
#include iostream
using std::map;
using std::cout;
using std::endl;
using std::string;
--- Comment #3 from jakub at gcc dot gnu dot org 2006-03-27 16:29 ---
What we perhaps could do is hack up C++ lang_decl_name etc., so that for the
artificially created .omp_fn* functions the diagnostic machinery would instead
print the name of the
original function, perhaps annotated
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-27 16:37 ---
Confirmed, -m32 -m64 is also broken too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-27 16:40 ---
This fails in 4.0.3:
t.cc: In function void test2():
t.cc:48: error: no match for operator!= in cit != std::map_Key, _Tp,
_Compare, _Alloc::rend() [with _Key = int, _Tp = std::basic_stringchar,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-27 16:42 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from law at redhat dot com 2006-03-27 17:09 ---
It seems to me that the fundamental problem is that the testcase manages
to stuff the value 3 into an object which is supposed to only have the
range [4, 5].
ie, if you put a breakpoint in C35507M.NEWCHARBRP and examine the
I'm using GMP 4.2 and MPFR 2.2.0, both built with gcc-4.0.2.
When I go to build gcc-4.0.3, I get the following error:
/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/gcc/gfortran
-B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/gcc/
-B/usr/pubsw/sparc-sun-solaris2.9/bin/
--- Comment #5 from law at redhat dot com 2006-03-27 17:22 ---
The cd2a23e test seems to have the same root cause as c35507m. No clue
about cxh1001 -- I'd rather not spend a lot of time analyzing cxh1001 without
first getting some resolution on the known issues with c35507m and
--- Comment #1 from quanah at stanford dot edu 2006-03-27 17:23 ---
change to fortran, instead of libfortran.
--
quanah at stanford dot edu changed:
What|Removed |Added
The program below produces the correct result for the first read and nothing
for the second. ifort and g95 produce the same result for each. It is my
belief that this construct is not strictly standard compliant but it is widely
used - I found this during my efforts to make iso_varying_string
--- Comment #2 from pcarlini at suse dot de 2006-03-27 17:28 ---
Will not be fixed in 4_0-branch.
*** This bug has been marked as a duplicate of 11729 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #15 from pcarlini at suse dot de 2006-03-27 17:28 ---
*** Bug 26887 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from law at redhat dot com 2006-03-27 17:53 ---
Separate issue than 26797. Not sure how to fix yet, but it's definitely a
bug in the new code.
jeff
--
law at redhat dot com changed:
What|Removed |Added
--- Comment #3 from mckinlay at redhat dot com 2006-03-27 18:28 ---
GCJ could be made to generate explicit null checks when large offsets are used.
It is probably relatively rare to have a normal object that is larger than a
page, so performance for most apps shouldn't be effected.
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-27 18:29 ---
The classpath import won't happen for the 4.1.x branch.
However, a workaround could be applied locally in Currency (or wherever)
as long as it doesn't change the ABI.
--
tromey at gcc dot gnu dot org changed:
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-27 18:36 ---
I'll handle this when I remove fastjar.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ddaney at avtrex dot com 2006-03-27 18:42 ---
Subject: Re: NullPointerException not generated for large
classes...
mckinlay at redhat dot com wrote:
--- Comment #3 from mckinlay at redhat dot com 2006-03-27 18:28 ---
GCJ could be made to generate
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-27 18:43 ---
The error appears to be intentional:
jint field_offset = field-u.boffset;
if (field_offset 0x)
throw new java::lang::VirtualMachineError;
However, I don't know what purpose this could
Both ifort and g95 produce viable executables with the following:
logical :: back =.true.
print *, myscan (The quick brown fox jumped over the lazy dog,
brown, back)
print *, myscan (The quick brown fox jumped over the lazy dog,
lazy)
contains
--- Comment #2 from quanah at stanford dot edu 2006-03-27 19:23 ---
On Solaris 8, the build fails also, except with the following error:
/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran
-B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/
--- Comment #1 from mbland at google dot com 2006-03-27 19:25 ---
I've got a working patch for 4.1.0, including a test case, reviewed by Ian
Lance Taylor. As soon as our people can work out an agreement with your
people over copyright assignment, I'll be sure to post it to this PR.
Configured and built with
env CC='gcc -mcpu=970 -m64' ../configure --enable-checking=no
--prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/ --with-mpfr=/opt/local/
--with-as=/usr/local/odcctools-20060123/bin/as
--with-ld=/usr/local/odcctools-20060123/bin/ld; make -j 8 bootstrap
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-27 20:03
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-03-27 20:05 ---
Subject: Bug 25378
Author: tkoenig
Date: Mon Mar 27 20:05:24 2006
New Revision: 112425
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112425
Log:
2006-03-27 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-03-27 20:05 ---
Subject: Bug 20935
Author: tkoenig
Date: Mon Mar 27 20:05:24 2006
New Revision: 112425
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112425
Log:
2006-03-27 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-03-27 20:15
---
Very likely a GMP/MFPR problem, try to disable TLS support in the library.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from law at redhat dot com 2006-03-27 20:31 ---
Subject: Re: [4.2 Regression] ACATS c35507m
cd2a23e cxh1001 failures
On Mon, 2006-03-27 at 20:12 +, laurent at guerby dot net wrote:
I don't know how it goes through gigi and the BE but the check
--- Comment #5 from paolo at gcc dot gnu dot org 2006-03-27 20:33 ---
Subject: Bug 26733
Author: paolo
Date: Mon Mar 27 20:33:41 2006
New Revision: 112426
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112426
Log:
2006-03-27 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #6 from pcarlini at suse dot de 2006-03-27 20:35 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from quanah at stanford dot edu 2006-03-27 20:48 ---
Disable TLS support in *which* library?
GMP, MPFR, or libfortran?
There are no options in the configure for GMP or MPFR referring to TLS/SSL.
--Quanah
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #20 from j at uriah dot heep dot sax dot de 2006-03-27 20:53
---
I suggest that this change should be accompanied by another indication in
the output that tells the ELF/DWARF-2 consumer about the changed pointer
size. Otherwise the consumer will experience funny behaviour.
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-03-27 21:00
---
Disable TLS support in *which* library?
GMP/MPFR.
There are no options in the configure for GMP or MPFR referring to TLS/SSL.
Did you build gcc-4.0.2 with Fortran support? If so, could you try building
--- Comment #7 from tromey at gcc dot gnu dot org 2006-03-27 22:03 ---
I was able to reproduce this with svn head on a ppc32 build.
A ppc64 build did not show this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
--- Comment #6 from quanah at stanford dot edu 2006-03-27 22:09 ---
I don't see a way to disable TLS support in GMP or MPFR, but I'll keep
poking.
I didn't build gcc 4.0.2 with Fortran support because I needed to build gcc to
build GMP and MPFR. ;)
Building gcc 4.0.1 also fails for
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-03-27 22:19
---
I didn't build gcc 4.0.2 with Fortran support because I needed to build gcc to
build GMP and MPFR. ;)
Of course. :-) I just rebuild 4.0.3 with 4.0.2 on SPARC/Solaris 8:
gax% CC=gcc40
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-03-27 22:22
---
/bin/sh is not supported on SPARC/Solaris. Please read the instructions at:
http://gcc.gnu.org/install/specific.html#x-x-solaris2
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from quanah at stanford dot edu 2006-03-27 22:27 ---
sorry, I meant 4.1.0, and you answered that well enough. ;)
*how* do I build gmp/mpfr without TLS? I don't see any configure options that
make sense for this...
I'll note that GMP was built with ABI=32 in my case.
--- Comment #2 from quanah at stanford dot edu 2006-03-27 22:28 ---
ah, thanks. Never hit that issue with any gcc release until now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-03-27 22:32
---
I'll note that GMP was built with ABI=32 in my case.
I'd recommend to configure it as specified in the instructions:
http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2
And you also need to make sure
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-03-27 22:33 ---
(gdb) call debug_generic_stmt (ret)
startD.1278_2 + -3B startD.1278_2 + 396B;
(gdb) call debug_generic_stmt (fold (ret))
1
I guess the reasoning of fold is: it is pointer arithmetics, so it
does not wrap. (-3B)
--- Comment #9 from mkuvyrkov at gcc dot gnu dot org 2006-03-27 23:04
---
The patch for this bug is:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01589.html
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-28 01:14 ---
One curiosity I noticed while debugging is that in layout_type,
class Two has size 128 (in bits). This value is incorrect.
Once we reach the code to compute the GC descriptor, the
size is 192.
--
Short synopsys:
---
You can not build a gcc for MCORE target on a 64-bit system. The bug is
identical for 4.0.2 and 4.1.0 versions of the gcc. The bug lies in the
actual MCORE crosscompiler; if it runs on a 64 bit system it handles
long long constants incorrectly. Minimal code to
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-03-28 01:43
---
I will look into this if you would like.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890
--- Comment #1 from bangerth at dealii dot org 2006-03-28 01:49 ---
It warns whenever foo:test1 is first compiled (i.e. on first use). If, for
example, you add this code
--
int main ()
{
foo f;
return f.test1();
}
--
then you get the warning you are
--- Comment #10 from quanah at stanford dot edu 2006-03-28 01:59 ---
I rebuilt gmp with:
--build=sparc-sun-solaris2.8
and then rebuilt MPFR, and then rebuilt gcc 4.0.3. On Solaris 8, it is still
dying, with:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Keywords||build
There seems to be a bug in the name mangling of a function inside a unnamed
namespace (using g++ 4.1.0), when the compilation unit uses a precompiled
header which contains another unnamed namespace. This is better demonstrated
with the following setup:
pch.h:
namespace { void inside_pch(){} }
--- Comment #1 from rodolfo at rodsoft dot org 2006-03-28 02:44 ---
There's an extra colon, which is a typo. The line that reads
0006 T _ZN38_GLOBAL__N_test2.cpp__D5E9623F4testEv:
Should be
0006 T _ZN38_GLOBAL__N_test2.cpp__D5E9623F4testEv
Sorry for the
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-28 03:06 ---
The summary on PR 10591 is wrong (but I am not going to change it back).
*** This bug has been marked as a duplicate of 10591 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-03-28 03:06
---
*** Bug 26895 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591
--- Comment #8 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-03-28
03:56 ---
Subject: Re: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
I don't know how it goes through gigi and the BE but the check
system__unsigned_types__unsigned!(A) in 4 .. 5
must
--- Comment #2 from paulthomas2 at wanadoo dot fr 2006-03-28 04:08 ---
Subject: Re: SIZE parameter interacts with same variable
in IO list character length specification.
jvdelisle at gcc dot gnu dot org wrote:
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-03-28
--- Comment #6 from sayle at gcc dot gnu dot org 2006-03-28 05:01 ---
Subject: Bug 22524
Author: sayle
Date: Tue Mar 28 05:01:27 2006
New Revision: 112438
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112438
Log:
PR middle-end/22524
* fold-const.c (fold_binary)
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-03-28 06:33
---
I rebuilt gmp with:
--build=sparc-sun-solaris2.8
and then rebuilt MPFR, and then rebuilt gcc 4.0.3. On Solaris 8, it is still
dying, with:
Please post the exact configure line and command line.
--- Comment #12 from quanah at stanford dot edu 2006-03-28 07:21 ---
For GMP (4.1.4 and 4.2, I've tried both versions):
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-03-28 07:24
---
And the command line for the compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #14 from quanah at stanford dot edu 2006-03-28 07:26 ---
For building GCC, I execute:
cd ../gcc-build/@sys make CFLAGS='-O' \
LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' 21 | tee
-a makeLOG
(@sys is an AFS thing, it translates to sun4x_58 or
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-03-28 07:28
---
For building GCC, I execute:
cd ../gcc-build/@sys make CFLAGS='-O' \
LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' 21 | tee
-a makeLOG
Use 'make bootstrap' instead of 'make'.
--
--- Comment #16 from quanah at stanford dot edu 2006-03-28 07:33 ---
I will try make bootstrap, but I note:
make worked fine with gcc-3.4.x, gcc-3.3.x, gcc-2.9x etc.
And for i386 and amd64 it worked just fine, too, for gcc 4.0.3 with these same
versions of GMP and MPFR to build
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-03-28 07:46
---
make worked fine with gcc-3.4.x, gcc-3.3.x, gcc-2.9x etc.
Yes, but it's wrong up to (and including) 4.1.x. We only guarantee that the
compiler correctly compiles itself (bootstraps), not that it is correctly
78 matches
Mail list logo
