There's an obvious bug in libfortran/io/write.c which causes a failure
to print "1.0" in exp. format - here's the fix:
diff -U3 -r gcc-4.0.0-old/libgfortran/io/write.c
gcc-4.0.0/libgfortran/io/write.c
--- gcc-4.0.0-old/libgfortran/io/write.c2005-04-05 15:24:36.0
+0100
+++ gcc-4.0
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04
07:24 ---
Subject: Bug 21297
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-04 07:24:34
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04
07:30 ---
Subject: Bug 21239
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-04 07:29:29
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04
07:36 ---
Subject: Bug 21265
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-04 07:35:32
Modified files:
gcc: Change
--- Additional Comments From giovannibajo at libero dot it 2005-05-04
08:14 ---
Fixed, thanks Kaveh and Jakub!
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From giovannibajo at libero dot it 2005-05-04
08:15 ---
Fixed, thanks Kurt for the report and Jakub for fixing it!
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-05-04
08:16 ---
Fixed!
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
While bootstrapping gcc-4.0.1 (20050503 pre) for sh-rtems4.7 using a native
vanilla GCC-4.0.0 on FC3:
../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg a-stmaco.ads -o a-stmaco.o
a-stmaco.ads: In function 'Ada.Strings.Maps.Constants._Elabs':
a-stmaco.ads:40: error: unrecognizable insn:
(insn:H
--
What|Removed |Added
Known to fail||4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-04 09:14
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> >|> Secondly, it is clear that your bug report is hypothetical. The
|> >|> library maintainers do not typically deal in hypothetica
--- Additional Comments From gtolstolytkin at ru dot mvista dot com
2005-05-04 10:11 ---
The bug is also exists in gcc-3.4-20050429 (gcc.3.4.4-preleleise).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081
--- Additional Comments From moudekotte at khaeon dot nl 2005-05-04 10:27
---
I noticed the PCC_BITFIELD_TYPE_MATTERS setting (hint:
http://www.astro.cf.ac.uk/cgi-bin/info2www?(gcc)Storage%20Layout ). I guess
packing settings overrule this PCC_BITFIELD_TYPE_MATTERS setting? If it was
mea
--- Additional Comments From giovannibajo at libero dot it 2005-05-04
12:12 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00257.html
Mark, is it OK to backport this patch to 3.4.4, with a proper ChangeLog?
--
What|Removed |Added
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-04 12:12 ---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
"jkanze at cheuvreux dot com" <[EMAIL PROTECTED]> writes:
[...]
| This bug report came about because of a discussion in a new
--- Additional Comments From mustafa at il dot ibm dot com 2005-05-04
12:31 ---
Is seems like this is not an SMS bug, sixtrack is failing for me with -m64 -O2
without -fmodulo-sched.
Jania, have you checked that and have a different results?
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-04 12:46
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> [...]
|> | This bug report came about because of a discussion in a news
|> | group. Basically, I said to watch out for std::string
When compiling a source file, GCC 4.0.0 exit with an "Internal compiler error".
This is the output of the `gcc -v` command:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --enable-shared --with-gnu-as
--with-gnu-ld --enable-threads=posix --enable-cpp --enab
When compiling a source file, GCC 4.0.0 exit with an "Internal compiler error".
This is the output of the `gcc -v` command:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --enable-shared --with-gnu-as
--with-gnu-ld --enable-threads=posix --enable-cpp --enab
--- Additional Comments From rperini at email dot it 2005-05-04 13:40
---
Created an attachment (id=8817)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8817&action=view)
This is the preprocessed source file that triggers the bug
This is the output generated with -v -save-temps fla
--
What|Removed |Added
Component|ada |target
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug
--- Additional Comments From overholt at redhat dot com 2005-05-04 14:28
---
Any news here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20504
When compiling the program below, gcc 4.0.0 dies with an ICE.
This also happens with gcc version 4.0.1 20050430 (prerelease)
gcc400 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/opt/gcc400
Thread model: posix
gcc version 4.0.0
command line:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
14:31 ---
Could you attach the preprocessed source as requested by the web site?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
14:32 ---
*** Bug 21378 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21379
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
14:32 ---
*** This bug has been marked as a duplicate of 21379 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
14:53 ---
Confirmed, reduced testcase:
typedef struct IpoKey {
struct IpoKey *next, *prev;
short flag, rt;
float val;
struct BezTriple **data;
} IpoKey;
IpoKey *first;
static int float_to_frame (float frame)
{
in
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
14:55 ---
Confirmed, backtrace:
#0 0x00112d98 in thread_block (bb=0x41485570) at
/Users/pinskia/src/gcc-4.0/gcc/gcc/tree-ssa-
threadupdate.c:503
#1 0x00112eb8 in thread_through_all_blocks () at
/Users/pinskia/src/
--- Additional Comments From ziga dot mahkovec at klika dot si 2005-05-04
15:01 ---
My copyright papers were resent and arrived successfully this time. This was
about a week ago (and I returned them immediately) so I expect the confirmation
Real Soon Now.
--
http://gcc.gnu.org/bugzi
Compiling this code (AMD64 under SuSE Linux Professional 9.1):
SUBROUTINE OPTBUG(N,A,LDA,B,LDB)
C .. Scalar Arguments ..
INTEGER LDA, LDB, N
C .. Array Arguments ..
REALA(LDA,N), B(LDB,N)
C .. Local Scalars ..
REAL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
15:05 ---
*** This bug has been marked as a duplicate of 21030 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
15:05 ---
*** Bug 21381 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
on both archs shared objects are build with:
-O2 -ggdb -fvisibility-inlines-hidden -fPIC -DPIC
linking fails with an error:
/usr/bin/ld: .libs/IexBaseExc.o: relocation R_X86_64_PC32 against
`_ZNSsD1Ev@@GLIBCXX_3.4' can not be used when making a shared object;
recompile with -fPIC
/usr/bin/ld: fin
--- Additional Comments From pluto at pld-linux dot org 2005-05-04 15:08
---
Created an attachment (id=8818)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8818&action=view)
build log.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21382
--- Additional Comments From pluto at pld-linux dot org 2005-05-04 15:08
---
Created an attachment (id=8819)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8819&action=view)
build log.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21382
--- Additional Comments From law at redhat dot com 2005-05-04 15:10 ---
Subject: Re: [4.0 Regression] ICE compiling
with -O
On Wed, 2005-05-04 at 14:56 +, pinskia at gcc dot gnu dot org wrote:
If you want, go ahead and assign this to me...
Jeff
--
http://gcc.gnu.org/
--
What|Removed |Added
CC||mmazur at kernel dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21382
--- Additional Comments From rperini at email dot it 2005-05-04 15:13
---
(In reply to comment #2)
> *** Bug 21378 has been marked as a duplicate of this bug. ***
Sorry for double posting. I have some problems on my Internet connection.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
Crash when finding &a_templated_func<>. I realize that that's not valid
code, so I expected I diagnostic, but I got an ICE instead.
Here's the command line:
panacea> g++ -v -save-temps /tmp/gccbug.cc
Reading specs from /usr/local/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: .
--- Additional Comments From mahall at ncsa dot uiuc dot edu 2005-05-04
16:11 ---
Oh - the address_of operator is not necessary - the crash occurs if we use just
anyfunc(dummy<>);
-matt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21383
--- Additional Comments From mark at codesourcery dot com 2005-05-04 16:33
---
Subject: Re: [3.4 regression] Infinite memory
allocation on -O3
giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot it 2005-05-04
> 12:12 ---
> Patch pos
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-04
16:41 ---
I'm interested: you do have a testcase that produces this failure on
i686-pc-linux-gnu? If so, I will make a testcase out of it and propose your
patch for review...
--
http://gcc.gnu.org/bugzilla/show_
--- Additional Comments From rspencer at x10sys dot com 2005-05-04 16:55
---
One other note. Shouldn't the segfault in _Jv_Linker be fixed anyway?
Dereferencing a point of value 0x01 isn't likely to be valid in any
circumstances?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21326
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
17:02 ---
Confirmed, here is the backtrace:
#0 arg_assoc_args (k=0xbff447d4, args=0xb7c68f30) at
/home/peshtigo/pinskia/src/gnu/gcc/src/
gcc/cp/name-lookup.c:4434
#1 0x08151dfa in lookup_arg_dependent (name=0xb7c8b
--- Additional Comments From hjl at lucon dot org 2005-05-04 17:15 ---
Known gcc bug. Check out my patch in bug 19664:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html
You may need to fix libstdc++ header files also.
*** This bug has been marked as a duplicate of 19664 ***
--
--- Additional Comments From hjl at lucon dot org 2005-05-04 17:15 ---
*** Bug 21382 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |law at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From giovannibajo at libero dot it 2005-05-04
17:19 ---
Greg, mind testing this also with a bootstrap on x86-linux?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04
17:20 ---
Subject: Bug 21112
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-04 17:20:44
Modified files:
gcc: ChangeLog gcc.c
Log message:
--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk
2005-05-04 17:28 ---
The problem occurred in a large finite element analysis code I developed.
The toplevel logic was written in C++, and this was linked to a venerable
public domain numerical analysis library in Fortra
--- Additional Comments From bkonrath at redhat dot com 2005-05-04 17:45
---
Daniel, could you post the actual source for those classes? Thanks, Ben
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
Unaligned COMMON blocks generate bus erros. One of the most basic test used by
configure to test the alignement of the Fortran types fail to compile. Even
worst it generate a bus error on an Apple computer.
program falign
external ALIGN
LOGICAL w,x,y,z
CHARACTER a,b,c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
18:00 ---
I thought this was fixed.
on i686-pc-linux-gnu we get the following warnings:
In file t.f:7
common /foo/a,w,b,x,y,c,z
1
Warning: Padding of 3
Target: x86_64-suse-linux
Configured with: ../gcc-4.0.0/configure --prefix=/ita3 --enable-languages=c,c++
--with-system-
zlib --enable-__cxa_atexit x86_64-suse-linux : (reconfigured)
../gcc-4.0.0/configure --prefix=/ita3
--enable-languages=c,c++ --with-system-zlib --enable-__cxa_atexit
--disabl
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
18:10 ---
Confirmed, not a regression.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
18:15 ---
f2 is now fixed.
--
What|Removed |Added
GCC build triplet|alphaev68-unknown-linux-gnu |
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
18:19 ---
I think this is fixed on the mainline, for x86, in 4.0.0 we get:
movl4(%esp), %edx
testl %edx, %edx
je .L2
leal-1(%edx), %eax
xorl%ecx, %ecx
g++ reports an error where a program attempts to take the address of an rvalue
of built-in type, but merely warns where it takes the address of an rvalue of
user-defined type:
$ cat test.cc
int i() { return 0; }
class A {};
A a() { return A(); }
int main()
{
int * pi = &i();
A * pa = &a();
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
18:34 ---
(In reply to comment #0)
> The first error message is also odd; "non-lvalue" is C terminology that is
> rarely used in relation to C++.
That is wrong because the standard actually uses lvalue and rvalue all
--- Additional Comments From wilson at gcc dot gnu dot org 2005-05-04
18:42 ---
Mine.
Andrew Pinski claims Xpreprocessor was in gcc-3.3.3 and works, but I can find no
evidence to support that. It does not show up in a grep of FSF gcc-3.3.x
sources. Also, the original patch that added
--- Additional Comments From wilson at gcc dot gnu dot org 2005-05-04
18:51 ---
Fixed on mainline.
I do not believe that there is any regression here, and hence I do not believe
that the patch needs to be applied to the gcc-3.4 or gcc-4.0 branches. I'll
leave this open for now in case
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
18:51 ---
(In reply to comment #3)
> Mine.
Woops I was wrong, I was looking at it wrongly. I must have missed the warning:
gcc: unrecognized option `-Xpreprocessor'
--
What|Removed
See code below. After type-casting, the compiler incorrectly assumes that
'a.unaligned_int' is aligned on a word boundary. On a MIPSEL system (here a
Cobalt RaQ 2) a 'sw' assembler instruction is generated to store the value in
memory, resulting in a 'Segmentation fault'. Changing the 'sw' instruct
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
19:10 ---
I think this is invalid because the standard talks about alignment and types.
--
What|Removed |Added
-
This patch
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01484.html
causes
./xgcc -B./ -B/usr/gcc-3.4/x86_64-unknown-linux-gnu/bin/ -isystem /usr/gcc-3.4/x
86_64-unknown-linux-gnu/include -isystem /usr/gcc-3.4/x86_64-unknown-linux-gnu/s
ys-include -L/export/build/gnu/gcc-3.4/build-x86_64-linux/gc
--- Additional Comments From gbosilca at utk dot edu 2005-05-04 19:24
---
I get the latest version from CVS. And the bug seems to be fixed on this
version.
fortran compiler version:
applebasket:/tmp root# gfortran --version
GNU Fortran 95 (GCC 4.1.0 20050504 (experimental))
Copyright
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
19:30 ---
Lets reopen it and ...
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
19:31 ---
*** Bug 21384 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
19:31 ---
Close it as a dup of bug 20059.
*** This bug has been marked as a duplicate of 20059 ***
--
What|Removed |Added
-
When -O3 or higher is used, the optimizer utilizes the lddf sparc instruction
to load doubles into registers. This can generate a bus-error/seg-fault at
runtime if the source address of the load is not mod8. The optimizer does not
check this, even with -munaligned-doubles set.
--
--- Additional Comments From drew dot johnson at andrew dot com 2005-05-04
19:38 ---
Created an attachment (id=8820)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8820&action=view)
compile with -O3 or higher, and execution generates seg-fault
The included file compiles with just -
--- Additional Comments From wilson at gcc dot gnu dot org 2005-05-04
19:39 ---
Since everyone agrees there is no regression, I am closing.
--
What|Removed |Added
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-04 19:40
---
Appears to have started passing again (on hppa2.0w-hpux, hppa64-hpux,
i686-linux, ia64-hpux at least) between 20050503 and 20050504.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21006
--- Additional Comments From rspencer at x10sys dot com 2005-05-04 19:48
---
Okay, after fixing some makefile bugs, the workaround suggested by Tom worked.
Feel free to close this now unless you want to track down the SIGSEGV.
Reid
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=213
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21389
/*
alphaev68-dec-osf5.1b long double optimization bug with gcc-4.0.0
regression from gcc-3.4.3
% config.guess
alphaev68-dec-osf5.1b
% gcc -v
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
20:07 ---
Fixed by:
2005-05-03 Richard Henderson <[EMAIL PROTECTED]>
* cfg.c (dump_flow_info): Use max_reg_num, not max_regno.
--
What|Removed |Added
---
--
What|Removed |Added
Component|regression |target
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
20:31 ---
We get:
i_3 = i_6 + 1;
bar (i_3);
D.1284_20 = (unsigned int) i_3;
i.0_25 = D.1284_20 + 0;
D.1241_5 = i.0_25 >> 5;
D.1242_10 = D.1241_5 * 4;
D.1243_11 = (int *) D.1242_10;
D.1244_12 =
Test program:
struct foo
{
int i;
};
int bar (void)
{
return ((struct foo *)0x1234)->i;
}
Compile with -g; readelf does NOT show a definition of "struct foo" in the debug
data.
If I compile with -fno-eliminate-unused-debug-types, the definition does
appear, but in the example program,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
20:36 ---
Confirmed, a regression from 3.3.3.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-04
20:53 ---
Ben --
As I recall the original test case was written in 'nice', not in java.
The sources may be of limited usefulness here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
--- Additional Comments From wilson at gcc dot gnu dot org 2005-05-04
21:18 ---
See
http://gcc.gnu.org/simtest-howto.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21365
Test code:
typedef enum { false, true } bool __attribute__((mode (byte)));
bool foo[16];
bool test (int i)
{
return foo[i];
}
This works with v3.3.3. With V4.0.0, the generated code is wrong -- it
references the array element as a word (4 bytes) yet indexes it as bytes. In
this particular
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04
21:38 ---
Subject: Bug 21354
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-04 21:38:23
Modified files:
libgfortran: ChangeLog
gcc/testsuite : C
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-04
21:45 ---
Note that the patch from the trunk can't be applied to the 4.0
branch, as it would break compatibility for the C++ ABI.
My current leaning is to simply disable the caching in 4.0.1.
--
http://gcc.gnu.org
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-04
21:51 ---
Subject: Bug 20371
CVSROOT:/cvs/gcc
Module name:gcc
Branch: sh-elf-4_1-branch
Changes by: [EMAIL PROTECTED] 2005-05-04 21:51:35
Modified files:
gcc: Cha
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-05-04
21:54 ---
I have found more problems with the ms bitfield code. An
amended patch is here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00339.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20371
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-04
23:03 ---
I can't trigger this problem anymore with the test case from my
original report. I will try to come up with a new test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
Here is what happens, the program ola2.cpp and ola2.ii are
available from http://www.idi.ntnu.no/~petrovic/ola2.zip
--
furu$ g++ -v -save-temps -o ola2 ola2.cpp -O3 -Wall
Reading specs from /store/lib/gcc/sparc-sun-solaris2.9/
--- Additional Comments From pavel dot petrovic at gmail dot com
2005-05-04 23:25 ---
Created an attachment (id=8821)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8821&action=view)
the refered file that contains ola2.cpp and ola2.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
00:00 ---
This works for me with the mainline, 3.4.0, and 3.3.3 on i686-pc-linux-gnu, it
might be just a stack
size limit problem.
--
What|Removed |Added
--
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21392
--
What|Removed |Added
GCC build triplet|i386-unknown-netbsdelf1.6.2 |
GCC host triplet|i386-unknown-netbsdelf1.6.2 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21392
--- Additional Comments From pluto at pld-linux dot org 2005-05-05 00:31
---
(In reply to comment #12)
> The first attempt is at
>
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01835.html
>
patches for pr19664 and 20218 kill gcc bootstrap. gcj fails:
/home/users/build
--
What|Removed |Added
CC||mmazur at kernel dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--- Additional Comments From pluto at pld-linux dot org 2005-05-05 00:37
---
(In reply to comment #13)
> (In reply to comment #12)
> > The first attempt is at
> >
> > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01835.html
> >
>
> patches for pr19664 and 20218 kill g
--- Additional Comments From pcarlini at suse dot de 2005-05-05 00:47
---
... maybe, while you are at it, you can check whether the patch for 19664 alone
is ok with current mainline?!? Thanks in advance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
gcc-3.4.3 contains an incorrect header fix for "the __FD_ZERO macro
present in glibc 1.x". The file installed in
/lib/gcc/i686-pc-linux-gnulibc1/3.4.3/include/gnu/types.h
contains the following, with spurious double-backslashes:
/* DO NOT EDIT THIS FILE.
It has been auto-edited by fixinclude
--- Additional Comments From hjl at lucon dot org 2005-05-05 04:56 ---
I posted an updated patch
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00391.html
It works for me on ia32, ia64 and x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--- Additional Comments From hingwah at hingwah dot net 2005-05-05 04:58
---
i don't think compiler generated constructor should have the "privilege" to
invoke constructor of parent class which is private.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21363
1 - 100 of 105 matches
Mail list logo
