--- Comment #3 from falk at debian dot org 2006-03-31 08:40 ---
Confirmed, also present in 4.2.0 20060218
Test case:
struct LongDouble {
char ld[16];
};
struct DynAny {
virtual void insert_longdouble(LongDouble value) = 0;
};
struct TAO_DynCommon : public virtual DynAny {
--- Comment #39 from ebotcazou at gcc dot gnu dot org 2006-03-31 09:53
---
> I've also been poking at MPFR. There are apparently 10 or more patches now
> for
> 2.2.0, that may resolve the issues, too. I'll look at that. I've rebuilt it,
> and ran the "check" area for mpfr, and 115/1
Won't build on Mingw. You are probably aware of it. I started the build with
GCC 4.0.2 on Mingw.
[EMAIL PROTECTED] /mingw/gcc-4.1.0
$ make
make[1]: Entering directory `/mingw/gcc-4.1.0'
make[2]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/zlib'
true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
--- Comment #40 from ebotcazou at gcc dot gnu dot org 2006-03-31 10:54
---
This is the build with GMP 4.1.3 and MPFR 2.2.0:
gax% gcc/xgcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /home/eric/svn/gcc-4_0-branch/configure
--prefix=/opt/build/eric/local/gcc-4_
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-03-31
11:24 ---
Could you retry this with gfortran 4.1 (now that it is out) ?
Thanks.
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
-
--- Comment #6 from aph at gcc dot gnu dot org 2006-03-31 11:43 ---
Subject: Bug 26858
Author: aph
Date: Fri Mar 31 11:43:43 2006
New Revision: 112574
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112574
Log:
2006-03-30 Andrew Haley <[EMAIL PROTECTED]>
PR java/26858
--- Comment #7 from aph at gcc dot gnu dot org 2006-03-31 13:05 ---
Subject: Bug 26858
Author: aph
Date: Fri Mar 31 13:05:32 2006
New Revision: 112575
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112575
Log:
2006-03-30 Andrew Haley <[EMAIL PROTECTED]>
PR java/26858
--- Comment #19 from ghazi at gcc dot gnu dot org 2006-03-31 13:51 ---
Of the 3 workarounds in comment #17, bootstrap with Sun cc doesn't work because
of PR 18058 (although there is a patch posted for that PR). Also bootstrap
with GCC 2.x or 3.x isn't quite right since I tried 3.4.x and
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-31 13:55
---
The original testcase does not crash anymore, but changing the
inline bool f1(char* p, char* q, int) { return p ? p : q; }
to
inline bool f1(char* p, char* q, const int&) { return p ? p : q; }
makes the compile
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-03-31 13:57
---
Created an attachment (id=11173)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11173&action=view)
testcase
Testcase according to comment #3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26771
--- Comment #2 from dir at lanl dot gov 2006-03-31 13:59 ---
There was a discussion of how to do it on some websites. I thought that they
just configured gfortran and gcc a liitle different, but I guess that I will
have to go back and look at the details.
--
http://gcc.gnu.org/bugzi
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:05
---
> Confirmed on Solaris 7, 8 and 9, everything is fine on Solaris 10.
Three functions are missing:
conftest.cc:75: error: '::wcstold' has not been declared
conftest.cc:76: error: '::wcstoll' has not been declare
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:09
---
> Of the 3 workarounds in comment #17, bootstrap with Sun cc doesn't work
> because of PR 18058 (although there is a patch posted for that PR). Also
> bootstrap with GCC 2.x or 3.x isn't quite right since I tri
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-03-31 14:24
---
Probably a duplicate of PR26197.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from ghazi at gcc dot gnu dot org 2006-03-31 14:29 ---
(In reply to comment #20)
> It's the wrong PR, this one is for pre-4.2, the 3 workarounds work.
> The problem is minor for pre-4.2. The blocker PR for 4.2 is PR other/26507.
Huh? The third comment in 26507 (by you
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:36
---
> Huh? The third comment in 26507 (by you I might add) agrees that PR 26507 and
> this one are the same problem. We should close one as a dup of the other.
I precisely chose not to close either because of thei
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:44
---
> My hope is that this PR will get more attention. We can't IMHO release 4.2
> with this problem still there, and it was filed in October.
Oh, and feel free to take a stab at it. :-) Part of the problem is tha
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-03-31 15:01
---
I'm about to post a fix.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from danglin at gcc dot gnu dot org 2006-03-31 15:04 ---
Breakpoint 1, make_decl_rtl (decl=0x40148880) at ../../gcc/gcc/varasm.c:968
968 gcc_assert (TREE_CODE (decl) != TYPE_DECL
(gdb) list
963 || TREE_PUBLIC (decl)
964 || DECL_EXT
compile trivial program with
g++ -c -O1 ice.cxx
I'll append a machince-readable copy of the test case...
==
typedef unsigned long long U64;
typedef unsigned short U16;
typedef unsigned char U8;
U16 m_rh;
U8 m_gN_eQ;
void f()
{
--- Comment #1 from apl at alum dot mit dot edu 2006-03-31 15:32 ---
Created an attachment (id=11174)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11174&action=view)
test case causing ICE
g++ -c -O1 ice.cxx
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26961
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-31
15:34 ---
Subject: Re: [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
> --- Comment #4 from danglin at gcc dot gnu dot org 2006-03-31 15:04
> ---
> Breakpoint 1, make_decl_rtl (decl=0x40148
The following c++ program compiles without error even though it crosses an
initialization. I only noticed this problem on g++ 3.4.4, 3.4.5. Versions
before and after 3.4 appear to be okay.
int g()
{
return 0;
}
int main()
{
goto L1;
int i=g();
L1:;
}
--
Summary: progr
--- Comment #1 from gary dot lazer at yahoo dot com 2006-03-31 16:10
---
more info: i686, intel dual xeon 2 GHz processors, dell precision 530
g++ output:
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
The following testcase crashes the compiler when compiled with -fipa-pta:
==
struct A
{
int i, j;
};
A foo(A);
template A bar(A a) { return foo(a); }
void baz()
{
bar<0>(A());
}
==
bug.cc: In function 'void baz(B<0
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #7 from hjl at gcc dot gnu dot org 2006-03-31 17:36 ---
Subject: Bug 25741
Author: hjl
Date: Fri Mar 31 17:36:00 2006
New Revision: 112583
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112583
Log:
contrib/regression/
2006-03-31 H.J. Lu <[EMAIL PROTECTED]>
--- Comment #8 from hjl at gcc dot gnu dot org 2006-03-31 17:42 ---
Subject: Bug 25741
Author: hjl
Date: Fri Mar 31 17:42:06 2006
New Revision: 112584
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112584
Log:
2006-03-31 H.J. Lu <[EMAIL PROTECTED]>
PR testsuite/25741
gcc currently generates duplicate debug information for enums declared in
namespaces.
Compile this C++ code with -g:
namespace { enum x { i = 1 }; }
x y;
In the .s file, I see this:
.uleb128 0x3
.string "x"
.byte 0x4
.byte 0x1
.byte 0x1
.byt
--- Comment #12 from zerocool at modemsoft dot it 2006-03-31 18:14 ---
Finally i produce the information that you ask me with the your precious
indication and that is :
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public Lic
Compile this C++ code with -g
enum x { i = 1 };
class c {
static const x beg = i;
};
void bar () { }
Looking at the .s output and the readelf --debug-dump output will show that
there is no debug info for x or beg. This is as expected: they are not used by
any actual code, so there is no need t
--- Comment #4 from pault at gcc dot gnu dot org 2006-03-31 18:58 ---
The patch to 4.1 will be committed tomorrow.
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-31 19:11 ---
Confirmed, a litte more reduced testcase:
typedef unsigned long long U64;
typedef unsigned short U16;
typedef unsigned char U8;
U16 m_rh;
U8 m_gN_eQ;
void f()
{
U16 m_;
m_gN_eQ = ((m_rh) ? 0x1ULL
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-31 19:13 ---
*** This bug has been marked as a duplicate of 20721 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-31 19:13
---
*** Bug 26962 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-03-31 19:59 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 20:05 ---
This looks very related to PR 14167.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26847
Hello,
I've compiled 4.2.0 GCC on OpenBSD 3.9-current. I've configured it with:
/home/karel/svn/gcc/trunk/configure
--prefix=/home/karel/usr/local/gcc-trunk-20060331 --enable-shared
--enable-threads --enable-languages=c++ --disable-checking --disable-nls
the problem is that r
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-31 21:12 ---
I believe c-common.c:pointer_int_sum is wrong in relying on pointer overflow
during conversion of the integer offset to an unsigned pointer. I'm sending
a patch that fixes this for comments.
--
http://gcc.gnu.o
--- Comment #23 from tkoenig at gcc dot gnu dot org 2006-03-31 21:13
---
Subject: Bug 19303
Author: tkoenig
Date: Fri Mar 31 21:13:46 2006
New Revision: 112590
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112590
Log:
PR fortran/19303
Backport from mainline
--- Comment #24 from tkoenig at gcc dot gnu dot org 2006-03-31 21:24
---
Fixed on 4.1. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 21:38 ---
Hmm, these functions should be weak and should not be visible.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.1.1 4.0.4 4.2.0
Target Milestone|4.2.0 |4.0
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26936
> Compare pretmp.28_49 with pretmp.32_11, why are the arguments in a different
> order? Is there something unstable in the PRE algorithm?
>
No, we just call fold on the expressions we build, and whatever it gives
us, we use :)
--- Comment #3 from dberlin at gcc dot gnu dot org 2006-03-31 22:41 ---
Subject: Re: [4.1/4.2 Regression] -ftree-ch
generates worse code
> Compare pretmp.28_49 with pretmp.32_11, why are the arguments in a different
> order? Is there something unstable in the PRE algorithm?
>
Still trying to get more info, but here is what I have.
Trying to build HDF5 1.7.52 on Fedora Core 5 i386 with gcc-4.1.0-3 (also seem
to see it with gcc-4.1.0-4 from rawhide).
The Dataspaces (h5s) test segfaults.
I've tracked it down to the following code in H5Dio.c:2263-2270 (in
H5D_create_chun
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 23:14 ---
Can you try first without -fstack-protector. If that does not work, try with
-fno-strict-aliasing added to see if maybe there is an aliasing issue.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-31 23:26 ---
I wrote a little script to print the amount of time taken for each
line of 'make' output.
This tends to confirm that installing the headers is very slow.
One other difference from 'make install-exec' is that the ord
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-31 23:30 ---
Is there a reasonable way to detect good failures versus bad failures here?
We definitely want to ignore cases where gcj-dbtool fails due to things
like not having mmap available.
Perhaps the thing to do is let it fa
--- Comment #2 from orion at cora dot nwra dot com 2006-03-31 23:32 ---
Compiled using 4.1.0 with the old 4.0.2 (FC4) flags (no -fstack-protector and
--param=ssp-buffer-size=4) with no effect.
Added -fno-strict-aliasing with no effect (at least for this, I've got a type
conversion issue
--- Comment #3 from orion at cora dot nwra dot com 2006-03-31 23:34 ---
Sorry, my browser seems to have changed components...
--
orion at cora dot nwra dot com changed:
What|Removed |Added
---
--- Comment #5 from kargl at gcc dot gnu dot org 2006-04-01 00:04 ---
Subject: Bug 25358
Author: kargl
Date: Sat Apr 1 00:04:46 2006
New Revision: 112594
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112594
Log:
2006-03-31 Asher Langton <[EMAIL PROTECTED]>
PR fortra
{
if (j != '\n' || (options & (((1L) << 1) << 1)))
fastmap[j] = 1;
}
}
}
}
gcc version 4.2.0 20060331 (experimental)
gcc -O3 -ftree-vectorize ruby.c -c
ruby.x.i: In function ruby_re_compile_fastmap:
ruby.x.i:9: internal compiler error: Se
This short section of code when compiled with:
g++ -g -O3 -Wformat=2 bug.cpp
complains
{{{
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/c++locale.h:
In function `int std::__convert_from_v(char*, int, const char*, _Tv,
__locale_struct* const&, int) [wit
--- Comment #6 from kargl at gcc dot gnu dot org 2006-04-01 00:07 ---
Subject: Bug 25358
Author: kargl
Date: Sat Apr 1 00:07:03 2006
New Revision: 112595
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112595
Log:
2006-03-31 Asher Langton <[EMAIL PROTECTED]>
PR fortra
--- Comment #7 from kargl at gcc dot gnu dot org 2006-04-01 00:12 ---
Fixed on 4.1 and trunk.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #1 from myles at peakstreaminc dot com 2006-04-01 00:14 ---
Created an attachment (id=11177)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11177&action=view)
code to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
--- Comment #2 from myles at peakstreaminc dot com 2006-04-01 00:19 ---
g++ -O2 -Wformat=2 works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
--- Comment #8 from kargl at gcc dot gnu dot org 2006-04-01 00:26 ---
Forgot to add the target milestone.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
T
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-01 00:40 ---
The warning is a true warning in that libstdc++ code contains:
const int __ret = std::snprintf(__out, __size, __fmt, __prec, __v);
But I don't know if there is a way of fixing this unless making
__convert_fro
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-01 00:40 ---
(In reply to comment #3)
> __convert_from_v out of line (which could slow down the compiler anyways).
s/compiler/program/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
--- Comment #3 from lucier at math dot purdue dot edu 2006-04-01 00:45
---
Subject: Re: Can't compile a 64-bit gcc
OK, I'll try to give a bit more data and make a more intelligent
comment.
I tried to configure and build mainline with this command:
/bin/rm -rf *; env CC='gcc -mcpu=
--- Comment #4 from lucier at math dot purdue dot edu 2006-04-01 00:48
---
Subject: Re: Can't compile a 64-bit gcc
On Mar 31, 2006, at 6:45 PM, lucier at math dot purdue dot edu wrote:
> So it appears that configure in 4.1.0 realizes that the libiconv on
> powerpc-darwin-8.5.0 is no
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-01 00:52 ---
Confirmed, reduced testcase:
void
ruby_re_compile_fastmap (char *fastmap, int options)
{
int j;
for (j = 0; j < (1 << 8); j++)
{
if (j != '\n' || (options & 4))
fastmap[j] = 1;
}
}
-
you c
--- Comment #13 from rmathew at gcc dot gnu dot org 2006-04-01 07:57
---
As you can see from the backtrace, the problem is in "gcc/java/jcf-io.c" at
line number 394 where we make a call to scandir(). I'm not an alpha-linux
hacker, but I see that there's scandir64 and dirent64 and it cou
68 matches
Mail list logo
