--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-05
06:27 ---
Fixed in 3.4.4.
--
What|Removed |Added
Status|ASSIGNED|RESO
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05
05:47 ---
Subject: Bug 19034
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-05 05:45:55
Modified files:
gcc/cp : Change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
05:34 ---
Confirmed, also on i686-pc-openbsd3.1 which also uses sjlj exceptions.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
05:17 ---
Note ICC causes the same thing in terms of error vs warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21386
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
05:12 ---
(In reply to comment #2)
> i don't think compiler generated constructor should have the "privilege" to
> invoke constructor of parent class which is private.
It does not but ICC does the same thing. Try cre
--- 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
--- 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
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 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
--- 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
--
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: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
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
--
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21392
--- 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
--- 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
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 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
--- 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 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 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: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
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 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
--- 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 pinskia at gcc dot gnu dot org 2005-05-04
20:36 ---
Confirmed, a regression from 3.3.3.
--
What|Removed |Added
Status|UNCONFIRMED
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: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 =
--
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: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
---
/*
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
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21389
--- 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
--- 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 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 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 -
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 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
-
--- 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:30 ---
Lets reopen it and ...
--
What|Removed |Added
Status|RESOLVED
--- 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
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 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
-
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
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
--- 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 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 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
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: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
--- 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:10 ---
Confirmed, not a regression.
--
What|Removed |Added
Status|UNCONFIRMED
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: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
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 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
--- 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 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 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |law at gcc dot gnu dot org
|dot org |
Status|NEW
--- 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
--- 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 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 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 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 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 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
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 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
--
What|Removed |Added
CC||mmazur at kernel dot pl
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/
--- 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 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
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 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
--- 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
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 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
--- 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 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: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: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:31 ---
Could you attach the preprocessed source as requested by the web site?
--
What|Removed |Added
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 overholt at redhat dot com 2005-05-04 14:28
---
Any news here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20504
--
What|Removed |Added
Component|ada |target
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug
--- 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
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 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
--- 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 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 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 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 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 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
--
What|Removed |Added
Known to fail||4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
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
--- Additional Comments From giovannibajo at libero dot it 2005-05-04
08:16 ---
Fixed!
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- 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
1 - 100 of 105 matches
Mail list logo
