--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-26 06:22
---
Hum... don't we want to backport that fix to 4.1?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from stefano dot franzoni at marposs dot com 2006-07-26
07:13 ---
Subject: Re: msp430-gcc with -Wunreachable-code Segmentation
fault
I think this was fixed in 3.3 and I think this is a dup of bug 11142 or
even PR
10660 or PR 10580.
I believe you are correct
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-26 08:03 ---
It says warning: signed and unsigned type in conditional expression and that
is the case:
unsigned int found_len = 0 ? a - b : foo;
because a - b is signed and foo is unsigned.
--
rguenth at gcc dot
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-26 08:05 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-26 08:06 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-07-26 08:34
---
A patch for the library functions CSHIFT, PACK and SPREAD has been submitted:
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01103.html
The only one that is still not working is thus RESHAPE; it's proving
--- Comment #4 from micis at gmx dot de 2006-07-26 09:04 ---
The patch http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01043.html fixes that
bug for the reduced source as well as for the original source.
Many thanks!
Michael Cieslinski
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
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=28490
--- Comment #1 from pcarlini at suse dot de 2006-07-26 11:26 ---
Out of curiosity, can you try whether changing the optimization level has any
effect? I'm asking because we are also seeing random failures of
ext/pb_ds/regression/priority_queue_rand.cc on ia64-linux which go away at -O0
--- Comment #9 from patchapp at dberlin dot org 2006-07-26 11:30 ---
Subject: Bug number PR c++/28250
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01108.html
--
--- Comment #5 from gurganbl at rose-hulman dot edu 2006-07-26 11:42
---
That would be a problem in assignment, not in the conditional. Additionally, if
I do unsigned int baz = 0;
signed int bar = -1;
baz = bar;
I get no warning. I agree with what you say about there being a problem
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-26 11:47 ---
No, you are incorrect. Anyways the warnings about ?: are to make sure that you
know that they are different signedness, which might change the behavior
slightly than what you are expecting.
unsigned int baz = 0;
--- Comment #27 from fxcoudert at gcc dot gnu dot org 2006-07-26 12:07
---
I just got the missing g77 intrinsics list down to:
Access, fcn, Check file accessibility.
ChMod,sub, Change file modes.
FSeek,fcn, Position file (low-level).
GMTime, fcn, Convert time to
--- Comment #11 from amylaar at gcc dot gnu dot org 2006-07-26 12:30
---
(In reply to comment #10)
If I had to guess I'd say that this was a C++ front end problem, or
maybe a recent change in cgraph.
It can't have been a particularly recent change, since it already failed
with GNU
--- Comment #15 from dtemirbulatov at gmail dot com 2006-07-26 12:53
---
As Andrew posted, the question is the impact on other targets...
Looking at the patch, it is only about e500(TARGET_E500 defined only for e500),
so it should not impact other targets
--
$ cat IPv6Test.java
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.util.Enumeration;
public class IPv6Test
{
public static void main( String args[] ) throws Exception
{
Enumeration nics = NetworkInterface.getNetworkInterfaces();
while (
--- Comment #2 from drow at gcc dot gnu dot org 2006-07-26 13:11 ---
Subject: Re: ext/pb_ds/regression/tree_data_map_rand.cc fails with a
particular random seed.
On Wed, Jul 26, 2006 at 11:26:01AM -, pcarlini at suse dot de wrote:
Out of curiosity, can you try whether changing
--- Comment #4 from tbm at cyrius dot com 2006-07-26 13:26 ---
Created an attachment (id=11945)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11945action=view)
test case
Testcase from application dcraw
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
--- Comment #5 from tbm at cyrius dot com 2006-07-26 13:26 ---
Created an attachment (id=11946)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11946action=view)
test case
Testcase from application dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
--- Comment #3 from pcarlini at suse dot de 2006-07-26 13:27 ---
Thanks a lot for your feedback. Then, I think we should look first for things
like uninitialized variables and/or miscompilations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-07-26 13:30
---
Subject: Bug 28402
Author: rsandifo
Date: Wed Jul 26 13:30:34 2006
New Revision: 115755
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115755
Log:
gcc/
PR middle-end/28402
* optabs.c
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-07-26 13:32
---
Subject: Bug 28403
Author: rsandifo
Date: Wed Jul 26 13:32:01 2006
New Revision: 115756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115756
Log:
gcc/
PR middle-end/28403
* optabs.c
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-07-26 13:34
---
Subject: Bug 28402
Author: rsandifo
Date: Wed Jul 26 13:34:17 2006
New Revision: 115757
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115757
Log:
gcc/
PR middle-end/28402
* optabs.c
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-07-26 13:35
---
Subject: Bug 28403
Author: rsandifo
Date: Wed Jul 26 13:35:34 2006
New Revision: 115758
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115758
Log:
gcc/
PR middle-end/28403
* optabs.c
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-07-26 13:38
---
Patch applied to branches.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-07-26 13:39
---
Patch applied to branches
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
The options -Wformat -Wmissing-format-attribute causes the
warning: function might be possible candidate for `printf' format attribute
for a call to vsnprintf() even though its prototype already
has the printf format attribute.
This is observed with the
preinstalled gcc 4.1.0 on SUSE Linux 10.1
--- Comment #4 from tbm at cyrius dot com 2006-07-26 13:48 ---
Created an attachment (id=11947)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11947action=view)
test case
Testcase from application 'john'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
--- Comment #12 from drow at gcc dot gnu dot org 2006-07-26 13:59 ---
It is a cgraph change. There were several patches affecting cgraph_remove_node
during this time period; it was probably one of those. The problem is that we
throw away the body of the abstract copy of the
--- Comment #4 from pcarlini at suse dot de 2006-07-26 14:55 ---
Confirmed on x86-linux. I did:
Index: rand_regression_test.hpp
===
--- rand_regression_test.hpp(revision 115714)
+++ rand_regression_test.hpp(working
-- sample program --
struct Command {
Command() {}
virtual ~Command() {}
};
void tryfunc() {
Command cmd;
for (;;) { throw 1; }
}
-- end sample program --
Disassembly of tryfunc():
(notice at 58-5c, constructor is called on r1+8, but at
88-90,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |target
--- Comment #15 from tbm at cyrius dot com 2006-07-26 15:25 ---
One of our (Debian's) Hurd porters has confirmed that this patch works.
Alfred, can you please clean it up and submit it to gcc-patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
--- Comment #16 from ams at gnu dot org 2006-07-26 15:35 ---
Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared
I'll try to get around it as soon as I can. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
--- Comment #1 from atgraham at gmail dot com 2006-07-26 15:42 ---
Actually, the for loop is unnecessary. Here's a shorter version that displays
the same problem:
struct Command {
virtual ~Command() {}
};
void tryfunc() {
Command cmd;
throw 1;
}
--
I received the run time error message upper bound of dimension 1 exceeded. I
initially thought that I had an array with an upper bound of 1, and that the
array index was larger than that. I now think that the error message tells me
that I have a rank-2 array, and that the upper bound of the
I get the following ICE with gcc 4.2 on ia64. The reduced testcase fails on
gcc 4.0/4.1 with an error but the original file compiles fine and only produces
an ICE with gcc 4.2 at -O.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O xstow-tree.cpp
xstow-tree.cpp: In member function 'bool
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |target
Target Milestone|--- |4.2.0
--- Comment #1 from tbm at cyrius dot com 2006-07-26 16:22 ---
Created an attachment (id=11948)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11948action=view)
test case
Testcase from application xstow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 16:22 ---
dimension 1 means to me, the first dimension. I don't see why it was not
hard to understand, in fact I did not read the rest of your message until I
already said to myself this was the first dimension.
--
--- Comment #2 from tbm at cyrius dot com 2006-07-26 16:30 ---
Huh, the testcase fails at -O but works at -O2. (But the original sources
failed at -O2).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
--- Comment #3 from tbm at cyrius dot com 2006-07-26 16:36 ---
This bug got introduced between 20051122 and 20060218.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-07-26 16:47 ---
Subject: Bug 27907
Author: rakdver
Date: Wed Jul 26 16:47:28 2006
New Revision: 115760
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115760
Log:
PR rtl-optimization/27907
* expr.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-26 17:02 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
When using the following test :
=== CODE BEGIN ==
:::
test.f90
:::
program test
implicit none
integer, dimension(3), parameter :: a=(/1,2,3/)
integer, dimension(3), parameter :: b=(/4,5,6/)
!integer, dimension(6), parameter :: y=(/ a(1),
It appears that GCC is assuming that the system linker can accept the +init
option. In the ld(1) man page, +init appears under the heading 64 Bit (ELF)
Link Editor options, and the system is 32-bit-only---might that have something
to do with it?
(begin build log excerpt)
ranlib
When compiling c++ code, you can get an error similar to this one:
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h:
In function '_RandomAccessIterator
std::__unguarded_partition(_RandomAccessIterator, _RandomAccessIterator, _Tp)
[with _RandomAccessIterator =
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2006-07-26
17:42 ---
Created an attachment (id=11949)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11949action=view)
The source mentioned in description
Source that won't compile
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 17:42 ---
I think GCC needs the GNU binutils linker now.
Also how did you configure GCC?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
--- Comment #2 from skunk at iskunk dot org 2006-07-26 17:55 ---
(In reply to comment #1)
I think GCC needs the GNU binutils linker now.
It certainly needs the GNU assembler (explicit configure-time error to that
effect), and I built binutils 2.17. That one said that (GNU) ld is not
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
The file in question here is gcc-4.1.1/gcc/tree-vectorizer.h, though I notice
there are many more instances of this issue in the GCC tree:
find gcc-4.1.1 -name '*.[ch]' -exec pcregrep
'^\s+#\s*(define|undef|if|endif)' {} \; | wc -l
326
(same command, but with pcregrep -l)
62
I know that
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 18:23 ---
Your compiler is not ANSI/ISO C complaint.
And in GCC 4.1.0 and above (maybe it was 4.0.0), we require an ISO C90 compiler
which this is valid ISO C90.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from skunk at iskunk dot org 2006-07-26 18:36 ---
I was under the impression that the bootstrapping process would first build an
intermediate compiler, itself written in a safe subset of C, that would then
build the full GCC, which could use modern features as needed. Was
--- Comment #5 from arno at heho dot snv dot jussieu dot fr 2006-07-26
18:36 ---
Created an attachment (id=11950)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11950action=view)
take-II this one works at -head as well
Bon,
apparently I'm (almost) the only one who uses gcj on
$ cat radix.c
#include stdio.h
#include float.h
int main()
{
printf(FLT_RADIX = %i\n,FLT_RADIX);
printf(DBL_RADIX = %i\n,DBL_RADIX);
return 0;
}
$ gcc radix.c
radix.c: In function 'main':
radix.c:7: error: 'DBL_RADIX' undeclared (first use in this function)
radix.c:7: error: (Each
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 18:50 ---
only FLT_RADIX exists in the C99 standard.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-26 18:52 ---
FLT_RADIX is for all of float, double and long double.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28500
--- Comment #3 from skunk at iskunk dot org 2006-07-26 19:00 ---
I'm sorry; I meant to write Why was it decided to...?
What strikes me as odd about this, moreover, is that the incompatibility
appears gratuitous; the extra whitespace doesn't help anything. Is this a case
of wanting to
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-26 19:02 ---
(In reply to comment #3)
What strikes me as odd about this, moreover, is that the incompatibility
appears gratuitous; the extra whitespace doesn't help anything. Is this a case
of wanting to (eventually) use
--- Comment #1 from kargl at gcc dot gnu dot org 2006-07-26 19:15 ---
First, you'll want to upgrade to at least 4.1.1 form 4.0.2.
Second, yes, it appears to be a bug. These lines work as expected.
integer, dimension(6), parameter :: y=(/ a(1:3), b(1:3) /)
integer, dimension(6),
--- Comment #27 from rakdver at gcc dot gnu dot org 2006-07-26 19:38
---
Patch for the wrong choice of induction variable:
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01125.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-07-26 19:49 ---
Created an attachment (id=11951)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11951action=view)
Current status of patch
Here's the current patch. It regtests fine, and
seems to do the Right Thing.
I haven't
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-07-26 19:52
---
gfortran 4.0 series is seriously broken and shouldn't be considered for
production use. Indeed, your testcase and variations work with the gfortran 4.2
branch, except for the following:
$ cat a.f90
integer,
--- Comment #5 from skunk at iskunk dot org 2006-07-26 19:53 ---
(In reply to comment #4)
Modern C as in 15 years is a joke. 15 years is enough for vendors to provide
a
new C compiler.
Sometimes, you can't get a newer version (e.g. licensing issues). Sometimes,
you don't want to
--- Comment #6 from schwab at suse dot de 2006-07-26 20:03 ---
This _is_ plain ANSI C89.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-07-26 20:08
---
Here's a reduced testcase:
Compile (on x86_64-unknown-linux-gnu) with:
g++ -O -ftree-vectorize -ftree-vectorizer-verbose=1 --param ggc-min-expand=0
--param ggc-min-heapsize=0
On i686-pc-linux-gnu you'll probably
--- Comment #28 from hubicka at gcc dot gnu dot org 2006-07-26 20:17
---
Subject: Bug 27882
Author: hubicka
Date: Wed Jul 26 20:17:32 2006
New Revision: 115763
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115763
Log:
PR tree-optimization/27882
* cgraph.c
--- Comment #16 from dje at gcc dot gnu dot org 2006-07-26 20:22 ---
Subject: Bug 28170
Author: dje
Date: Wed Jul 26 20:21:49 2006
New Revision: 115764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus
--- Comment #9 from dje at gcc dot gnu dot org 2006-07-26 20:22 ---
Subject: Bug 28150
Author: dje
Date: Wed Jul 26 20:21:49 2006
New Revision: 115764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus
--- Comment #19 from dje at gcc dot gnu dot org 2006-07-26 20:22 ---
Subject: Bug 27287
Author: dje
Date: Wed Jul 26 20:21:49 2006
New Revision: 115764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus
--- Comment #20 from dje at gcc dot gnu dot org 2006-07-26 20:25 ---
patch backported
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from dje at gcc dot gnu dot org 2006-07-26 20:26 ---
patch backported
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #17 from dje at gcc dot gnu dot org 2006-07-26 20:27 ---
patch backported
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
The following testcase triggers an ICE since at least GCC 2.95.3:
=
struct A
{
operator int();
};
int i = __real__ A();
=
bug.cc:6: internal compiler error: in add_builtin_candidate, at cp/call.c:1979
Please submit a full bug report,
The following testcase triggers an ICE since at least GCC 2.95.3:
=
void foo() {}
void foo(void[]);
=
bug.c:2: error: declaration of 'type name' as array of voids
bug.c:2: internal compiler error: tree check: expected class 'type', have
The following testcase triggers an ICE since at least GCC 2.95.3:
=
void i;
void foo()
{
__asm__ ( : +r (i));
}
=
bug.c: In function 'foo':
bug.c:5: internal compiler error: in gimplify_expr, at gimplify.c:5902
Please submit a full bug
--- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 ---
(In reply to comment #6)
This _is_ plain ANSI C89.
ISO C90 was specified. Yes, my bad, ANSI does allow whitespace before the
#---but what of it? It's good practice anyhow to place the mark first, and
the Tru64 compiler
--- Comment #6 from tbm at cyrius dot com 2006-07-26 20:58 ---
Created an attachment (id=11952)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11952action=view)
test case
Testcase from application yorick.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
--- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 ---
(In reply to comment #6)
This _is_ plain ANSI C89.
ISO C90 was specified. Yes, my bad, ANSI does allow whitespace before the
#---but what of it? It's good practice anyhow to place the mark first, and
the Tru64
--- Comment #8 from pinskia at physics dot uc dot edu 2006-07-26 20:59
---
Subject: Re: Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 ---
(In reply to comment #6)
This _is_ plain ANSI C89.
The following testcase triggers an ICE since GCC 4.0.0:
==
void foo(void (*p)(int n, int x[n])) {}
==
bug.c: In function 'foo':
bug.c:1: internal compiler error: in make_decl_rtl, at varasm.c:1005
Please submit a
The following invalid code snippet triggers an ICE since GCC 3.4.0:
=
struct A
{
A : ();
A : (int);
};
A a = (A){0};
=
bug.cc:3: error: expected primary-expression before ')' token
bug.cc:3: error: name 'A' has incomplete type
bug.cc:4: error:
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-07-26 21:35
---
A similar testcase crashes in a different position:
==
struct A
{
A : ();
A : (int);
};
struct B
{
char c;
A a;
};
B b = (B){0};
==
On mainline
The following code snippet causes an ICE since GCC 4.0.0:
struct A
{
virtual void* foo() = 1;
};
bug.cc:3: internal compiler error: in grokfield, at cp/decl2.c:850
Please submit a full bug report, [etc.]
A similar code
--- Comment #4 from schwab at suse dot de 2006-07-26 21:47 ---
Broken since r111459:
2006-02-26 Steven Bosscher [EMAIL PROTECTED]
* common.opt (-floop-optimize, -frerun-loop-opt): Remove.
* tree-pass.h (pass_loop_optimize): Remove.
* passes.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-26 21:54 ---
(In reply to comment #4)
Broken since r111459:
That would mean it was a latent bug. In fact you can most likely reproduce the
failure with -fno-loop-optimize.
--
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--- Comment #23 from hubicka at gcc dot gnu dot org 2006-07-26 22:52
---
Subject: Bug 28071
Author: hubicka
Date: Wed Jul 26 22:51:56 2006
New Revision: 115765
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115765
Log:
PR rtl-optimization/28071
* regmove.c
--- Comment #1 from patchapp at dberlin dot org 2006-07-26 23:35 ---
Subject: Bug number PR c/28502
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01128.html
--
--- Comment #3 from patchapp at dberlin dot org 2006-07-26 23:35 ---
Subject: Bug number PR c++/27668
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01130.html
--
I haven't had much experience with basic_ifstream, so please forgive me if this
is expected gcc behavior.
Observed behavior:
getline on an instance of basic_ifstream unsigned char fails to copy a line
of the source file to the buffer.
Expected behavior:
basic_ifstream unsigned char getline
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-07-27 01:01
---
OK , simple enough. Will do shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
e have often gotten the following assembler error with -g option
since m32r-linux-gnu-gcc-4.0 released.
/tmp/cch1oLgA.s: Assembler messages:
/tmp/cch1oLgA.s:2591: Error: operand out of range (145 not between -128 and
127)/tmp/cch1oLgA.s:3358: Error: operand out of range (145 not between -128 and
--- Comment #1 from inaoka dot kazuhiro at renesas dot com 2006-07-27
01:48 ---
Created an attachment (id=11953)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11953action=view)
test case
bc.s and bnc.s have the range (form -512 to 508) of PC-relative.
If all 2byte instruction
--- Comment #2 from inaoka dot kazuhiro at renesas dot com 2006-07-27
01:52 ---
Created an attachment (id=11954)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11954action=view)
workaround patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28508
--- Comment #1 from pcarlini at suse dot de 2006-07-27 01:53 ---
This is a well known source of puzzlement. The point is that, according to the
C++ standard, the external (on disk) representation is in any case made of
*chars*. Therefore, in general, conversions from/to that
--- Comment #2 from atgraham at gmail dot com 2006-07-27 02:47 ---
This bug appears to only happen when the compiler is built with SjLj
exceptions. When the compiler is built for dwarf2 exceptions, this test case
(and my original problem area) are both correct:
tryfunc():
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28506
1 - 100 of 102 matches
Mail list logo
