--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-21 03:37 ---
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01288.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-21 03:36 ---
*** Bug 33125 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33126
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-21 03:36 ---
*** This bug has been marked as a duplicate of 33126 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Build was successful after stripping out all the -Werror flags from the
makefiles.
/tmp/gcc--4.2.1.build/./gcc/xgcc -B/tmp/gcc--4.2.1.build/./gcc/
-B/opt/tg/powerpc-ibm-aix4.3.3.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.3.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.3.0/include -isystem
/opt/tg/powerpc-ib
--- Comment #3 from michelin60 at gmail dot com 2007-08-21 01:01 ---
Pr 33126 by torsten.debian.org seems to confirm this, even as that build was
for a cross-boot.
--
michelin60 at gmail dot com changed:
What|Removed |Added
--- Comment #2 from michelin60 at gmail dot com 2007-08-21 00:48 ---
This failure to boot perdures since since about 11.00 am. The extensive changes
submitted by Chao-ying Fu did not change anything.
Per telephone inquiry the same ICE occurs on a pentium3 but does not occur on a
pentium
I can not get past this error and build gcc/gfortran with or without bootstrap
enabled. Latest trunk.
In file included from
/home/jerryd/gcc/obj43/./prev-gcc/include-fixed/bits/string2.h:1308,
from /usr/include/string.h:417,
from ../../gcc43/libiberty/regex.c:14
--- Comment #1 from gdr at cs dot tamu dot edu 2007-08-21 00:23 ---
Subject: Re: New: C++ frontend finds static function in argument dependent
lookup based on template parameter
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| In the C++ standard section 14.6.4.2 [temp.dep.candida
--- Comment #5 from gdr at cs dot tamu dot edu 2007-08-21 00:19 ---
Subject: Re: C++ frontend should not warn about new a[0] in template context
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| The problem I see is that this unconditional warning warns about code which
is
| complet
In the C++ standard section 14.6.4.2 [temp.dep.candidate] says this:
"
For a function call that depends on a template parameter, if the function name
is an unqualified-id but not a template-id, the candidate functions are found
using the usual lookup rules (3.4.1, 3.4.2) except that:
-- For the p
--- Comment #4 from ian at airs dot com 2007-08-20 23:30 ---
The problem I see is that this unconditional warning warns about code which is
completely safe and correct. That break -Werror builds. There is no natural
way to avoid the warning in a template. Given that, if we want to hav
--- Comment #1 from mj1 at cog dot brown dot edu 2007-08-20 23:24 ---
Created an attachment (id=14085)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14085&action=view)
Sample program showing that uniform_int() returns value out of range
returns -1 when run on
[EMAIL PROTECTED] tm
--- Comment #3 from gdr at cs dot tamu dot edu 2007-08-20 23:23 ---
Subject: Re: C++ frontend should not warn about new a[0] in template context
"mec at google dot com" <[EMAIL PROTECTED]> writes:
| "new T[0]" looks like defined behavior to me.
|
| [expr.new] 5.3.4 -7-
| When the val
The uniform_int distribution in the following program (copied from start of the
Boost random documentation) returns a value (-1) that is outside of its range.
Thanks,
Mark Johnson
#include
#include
int main() {
std::tr1::mt19937 rng;
std::tr1::uniform_int<> six(1,6);
std::tr1::variate
--- Comment #22 from h dot b dot furuseth at usit dot uio dot no
2007-08-20 22:45 ---
Subject: Re: warn for uninitialized arrays passed as const* arguments
manu at gcc dot gnu dot org writes:
> But it seems that the current policy of GCC is to not assume that such
> functions actually
--- Comment #1 from hemant dot jaiswal at gmail dot com 2007-08-20 20:30
---
arm-linux-gcc is Configured with: ../gcc-3.4.6/configure
--prefix=/usr/local/swdevel/tools/arm --
target=arm-linux-gnu
--with-local-prefix=/usr/local/swdevel/tools/arm/arm-linux-
gnu/usr
--with-gxx-include-dir=
--- Comment #1 from schwab at suse dot de 2007-08-20 20:25 ---
Member lookup does not take accessibility into account. An inaccessible but
otherwise visible member is still considered a candidate.
--
schwab at suse dot de changed:
What|Removed |Ad
Compilation of following code fails with error:
a.cpp: In constructor `c::c()':
a.cpp:14: error: reference to `i' is ambiguous
a.cpp:8: error: candidates are: int b::i
a.cpp:3: error: int a::i
a.cpp:14: error: `i' was not declared in this scope
class a{
private:
int i;
--- Comment #2 from mec at google dot com 2007-08-20 19:31 ---
"new T[0]" looks like defined behavior to me.
[expr.new] 5.3.4 -7-
When the value of the expression in a direct-new-declarator is zero, the
allocation function is called to allocate an array with no elements. The
pointer re
--- Comment #5 from patchapp at dberlin dot org 2007-08-20 19:10 ---
Subject: Bug number PR32985
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/2007-08/msg01299.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from torsten at debian dot org 2007-08-20 19:10 ---
Created an attachment (id=14084)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14084&action=view)
Preprocessed source causing the failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33126
20070820 (experimental)
The host system is Debian unstable as of last week, but I don't think that
makes a difference :-)
Complete command line:
[EMAIL
PROTECTED]:~/rtems/gnu/powerpc-rtems/powerpc-rtems/libstdc++-v3/libsupc++$
/home/torsten/rtems/gnu/powerpc-rtems/./gcc/xgcc -shared-libgcc
-B
--- Comment #1 from michelin60 at gmail dot com 2007-08-20 19:07 ---
Created an attachment (id=14083)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14083&action=view)
preprocessed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33125
Thread model: posix
gcc version 4.3.0 20070820 (experimental)
/var/tmp/43/build-131/./gcc/cc1plus -E -quiet -nostdinc++ -v
-I/var/tmp/43/gcc-4.3.0/libstdc++-v3/../gcc
-I/var/tmp/43/build-131/powerpc-unknown-linux-gnu/libstdc++-v3/include/powerpc-unknown-linux-gnu
-I/var/tmp/43/build-131/powerpc
--- Comment #1 from gdr at cs dot tamu dot edu 2007-08-20 18:57 ---
Subject: Re: New: C++ frontend should not warn about new a[0] in template
context
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| For this simplified code:
|
| template
| char* f1() { if (c == 0) return 0; else
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| For this simplified code:
|
| template
| char* f1() { if (c == 0) return 0; else return new char[c]; }
| char* f2() { return f1<0>(); }
|
| the C++ frontend issues an unconditional warning. When compiling with no
| options, I get
|
| foo.cc:
--- Comment #21 from gdr at cs dot tamu dot edu 2007-08-20 18:50 ---
Subject: Re: warn for uninitialized arrays passed as const* arguments
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| When I say "constant are not propagated" I mean "the constant value of a
| variable" s
--- Comment #4 from vmakarov at redhat dot com 2007-08-20 18:46 ---
Yes, I belive my RA should manage the situation and use not only b0 register.
But in general, I think we need also register pressure heuristics in insn
scheduler before the register allocation to constrain insn movement
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-20 18:25 ---
Wow, scheduling plus reload does extremely horrible job here.
This is
b[0] = {};
b[0].a.j[0] = 0;
b[0].a.j[1] = 0;
b[0].a.j[2] = 0;
b[0].a.j[3] = 0;
b[0].a.j[4] = 0;
b[0].a.j[5] = 0;
b[0].a.j[6] = 0;
--- Comment #4 from Axel dot Thimm at ATrpms dot net 2007-08-20 18:05
---
The same thing happens with 4.2.1, only that there are additional warnings
before:
Comparing stages 2 and 3
warning: ./libgcc/_fixunssfdi.o differs
warning: ./libgcc/_udivmoddi4_s.o differs
[...]
warning: ./libgc
For this simplified code:
template
char* f1() { if (c == 0) return 0; else return new char[c]; }
char* f2() { return f1<0>(); }
the C++ frontend issues an unconditional warning. When compiling with no
options, I get
foo.cc: In function char* f1() [with int c = 0]:
foo.cc:3: instantiated fro
I am trying to cross-compile a filter driver for a printer, by adding it to
CUPS/filter directory( file name rastertostar) for arm-linux-gcc ( version
3.4.6).
This filter driver is compiling and working fine for i386 machine.But when i am
compiling it for arm-linux-gcc it gives an internal compiler
--- Comment #20 from manu at gcc dot gnu dot org 2007-08-20 17:12 ---
(In reply to comment #19)
>
> What if you had "const int i=0"? As I said before, use() may do a const-cast
> to get rid of the constness of its argument, but the result is only
> well-defined
> if the object pointed t
--- Comment #6 from echristo at apple dot com 2007-08-20 17:11 ---
No, I spoke to Daniel about it a while back, but he hasn't had time to look
into it. It's definitely caused by the toplevel changes to libgcc. The basic
idea is that the toplevel makefile re-installs libgcc into the gcc d
--- Comment #7 from asl at math dot spbu dot ru 2007-08-20 17:00 ---
Well, I haven't seen this. The only segfault I've seen was in trans-types.c
(patch mentioned)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
--- Comment #19 from bangerth at dealii dot org 2007-08-20 16:58 ---
(In reply to comment #18)
> When I say "constant are not propagated" I mean "the constant value of a
> variable" such as:
>
> int i=0;
> use(&i);
> foo(i);
>
> Here, GCC does not propagate the value of i to do f
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-20 16:51
---
(In reply to comment #5)
> How is it choking? Maybe I already seen this during preparation of quick
> patch.
Well, it's trying to reuse a decl without arglist for a function call with
arguments, and it leads to
--- Comment #5 from asl at math dot spbu dot ru 2007-08-20 16:47 ---
(In reply to comment #3)
> Two decls are generated for function x, the first one (inside MAIN__) doesn't
> have a proper argument list while the second one is OK. When I try to make
> gfortran emit only one decl per ext
--- Comment #18 from manu at gcc dot gnu dot org 2007-08-20 16:46 ---
When I say "constant are not propagated" I mean "the constant value of a
variable" such as:
int i=0;
use(&i);
foo(i);
Here, GCC does not propagate the value of i to do foo(0). Remove the call to
use and then it
--- Comment #4 from asl at math dot spbu dot ru 2007-08-20 16:46 ---
Ooops, attached patch is not complete. I also need:
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -1027,7 +1027,7 @@ gfc_get_nodes
--- Comment #17 from manu at gcc dot gnu dot org 2007-08-20 16:44 ---
(In reply to comment #16)
> (In reply to comment #15)
>
> > Of course, the output is '5' and not '0'. So yes, atoi() seems perfectly
> > able
> > to initialize buf. (or perhaps, I am still confused).
>
> Since use(
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-20 16:40 ---
This has nothing to do with dwarf2 nor unwinding.
Things break during reload which decides to reload something into the b0
register (which is live at that point and not very general purpose register
anyway).
--
ht
--- Comment #16 from bangerth at dealii dot org 2007-08-20 16:21 ---
(In reply to comment #15)
> Of course, the output is '5' and not '0'. So yes, atoi() seems perfectly able
> to initialize buf. (or perhaps, I am still confused).
I think you are. This program here segfaults:
--- Comment #15 from manu at gcc dot gnu dot org 2007-08-20 16:15 ---
(In reply to comment #14)
> This is meant to only counter your point that:
> > 'const' does not mean read-only in C++ at all, and much less in C.
> > atoi(const
> > char *) could always initialize buf[].
> This simply
--- Comment #7 from rask at gcc dot gnu dot org 2007-08-20 16:06 ---
Created an attachment (id=14082)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14082&action=view)
Preprocessed testcase; compile with -O2 -g -m2a -fno-builtin
It appears to fail the same way as earlier:
(gdb) fr
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Summary|Mistaken type mismatch error|[4.3 Regre
--- Comment #14 from bangerth at dealii dot org 2007-08-20 15:54 ---
(In reply to comment #12)
> This testcase has nothing to do with uninitialized variables.
No, of course. I only meant to reply to your assertion that there could be
cases where a function initializes an object that is
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-20 15:45 ---
Created an attachment (id=14081)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14081&action=view)
patch
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-20 15:39 ---
Ah no, this is a bug in fold-const introduced by the pplus merge. Fix:
@@ -9541,7 +9547,9 @@ fold_binary (enum tree_code code, tree t
tree arg01 = fold_convert (sizetype, TREE_OPERAND (arg0, 1));
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-20 15:30 ---
Reduced testcase:
struct dis386 {
const char *x;
};
static const struct dis386 float_reg[][2] = {
{ { "fadd" }, { "fadd" } },
};
void foo(int i, int j)
{
const struct dis386 *dp;
dp = &float_reg[i - 1][j]
--- Comment #24 from jason at gcc dot gnu dot org 2007-08-20 15:08 ---
Subject: Bug 7302
Author: jason
Date: Mon Aug 20 15:08:24 2007
New Revision: 127649
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127649
Log:
PR c++/7302
* cp/class.c (finish_struct_1): Warn
--- Comment #13 from manu at gcc dot gnu dot org 2007-08-20 15:08 ---
(In reply to comment #12)
>
> This testcase has nothing to do with uninitialized variables. If the variable
> is 'const' already, then there will never be a warning. Will it produce
> segmentation fault for a local au
--- Comment #10 from langton at gcc dot gnu dot org 2007-08-20 15:07
---
(In reply to comment #9)
> Adding -finit-real=nan (http://gcc.gnu.org/ml/fortran/2007-08/msg00408.html)
> is
> a real bonus for gfortran.
> Any chance to add "-finit-real=snan" to set "Signalling NaN" ?
> A SNaN
--- Comment #12 from manu at gcc dot gnu dot org 2007-08-20 15:03 ---
(In reply to comment #11)
> (In reply to comment #10)
> > I now think that Andrew is right and that PR33086 and this one are INVALID.
> > 'const' does not mean read-only in C++ at all, and much less in C.
> > atoi(con
--- Comment #11 from bangerth at dealii dot org 2007-08-20 14:56 ---
(In reply to comment #10)
> I now think that Andrew is right and that PR33086 and this one are INVALID.
> 'const' does not mean read-only in C++ at all, and much less in C. atoi(const
> char *) could always initialize b
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Status|UNCONFIRMED |NEW
Ever
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-20 14:49 ---
I now think that Andrew is right and that PR33086 and this one are INVALID.
'const' does not mean read-only in C++ at all, and much less in C. atoi(const
char *) could always initialize buf[]. However, perhaps it can a
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-20 14:47
---
Confirmed. The same thing is true for external procedures, like:
program test
real x
external x
print *, x(2)
end program test
real function x(i)
integer i
x = i + 1
end function x
Two decls are gene
--- Comment #5 from manu at gcc dot gnu dot org 2007-08-20 14:47 ---
Andrew, what about functions marked with attribute "pure" ?
int atoi(const char *) __attribute__ ((pure));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33086
--- Comment #7 from manu at gcc dot gnu dot org 2007-08-20 14:18 ---
Even simpler testcase:
int foo ()
{
int i = 0;
int j;
if (1 == i)
return j;
return 0;
}
This will only be reliably fixed by building a better SSA representation.
Moving the passes around will
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-20 13:54 ---
struct A
{
virtual int method(int);
int method();
};
struct B: A
{
int method(int);
};
That is the example. You need to add:
using A::method;
to get exposed in B, A::method.
--
pinskia at gcc dot gnu do
Hi Andrew,
As mentioned before this error message is really an internal error, we
really should be fixing GCC and not changing binutils. And I already
mentioned this is most likely PR 22371 and that you should be filing
bug reports about these two errors/ICEs.
I have filed PR 33122 to cover th
--- Comment #5 from nickc at redhat dot com 2007-08-20 13:48 ---
Bug report #33122 may be a duplicate of this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
--- Comment #1 from nickc at redhat dot com 2007-08-20 13:46 ---
Created an attachment (id=14080)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14080&action=view)
Compressed, pre-processed source file used to reproduce the problem
This source file was compiled with this command li
Bootstrapping gcc from the 19 Aug 2008 mainline sources (and possibly earlier
and/or later) with an integrated source tree containing the binutils mainline
sources fails with:
gcc/current/opcodes/i386-dis.c: In function 'dofloat':
gcc/current/opcodes/i386-dis.c:4193: error: type mismatch in po
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-20 13:25 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-20 13:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
Hello,
I have the classes A and B where B is derived from A. The following methods are
given:
bool A::method();
virtual bool A::method(int arg);
bool B::method(int);
Now when I want to call method() on an object of type B I get the compiler
error that there is no method() in class B and the onl
--- Comment #6 from mueller at gcc dot gnu dot org 2007-08-20 12:43 ---
I`d be happy to help with testing :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32756
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-20 12:32 ---
Subject: Bug 22369
Author: rguenth
Date: Mon Aug 20 12:31:44 2007
New Revision: 127647
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127647
Log:
2007-08-20 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-20 12:32 ---
Subject: Bug 22451
Author: rguenth
Date: Mon Aug 20 12:31:44 2007
New Revision: 127647
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127647
Log:
2007-08-20 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #9 from arnaud02 at users dot sourceforge dot net 2007-08-20
12:28 ---
Adding -finit-real=nan (http://gcc.gnu.org/ml/fortran/2007-08/msg00408.html) is
a real bonus for gfortran.
Any chance to add "-finit-real=snan" to set "Signalling NaN" ?
A SNaN cannot be the result of an
--- Comment #5 from nathan at gcc dot gnu dot org 2007-08-20 12:21 ---
I have a patch, which needs fuller testing. (I've been on vacation :))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32756
--- Comment #3 from rakdver at kam dot mff dot cuni dot cz 2007-08-20
12:10 ---
Subject: Re: Failing to represent the stride (with array) of a dataref when it
is not a constant
> --- Comment #2 from dorit at gcc dot gnu dot org 2007-08-20 05:55 ---
> > Making us return symbol
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-20 12:00
---
You can also now invoke it just with "-O1 -ftree-store-ccp" :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30840
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-20 11:57
---
> Here is a new reduced testcase (compile at -O3 -fno-strict-aliasing):
One more note, this testcase ICEs with the C front-end now :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30840
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-20 11:55
---
Here is a new reduced testcase (compile at -O3 -fno-strict-aliasing):
struct rxvt_salloc {
char *firstblock;
unsigned int firstfree;
};
struct line_t {
unsigned int *t;
unsigned int f;
};
struct rxvt_sall
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-20 11:47
---
I wasn't even aware of their existence! I'll do it (unless you want to?),
thanks for the doc patch.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mueller at gcc dot gnu dot org 2007-08-20 11:13 ---
ping.. any results?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32756
When gfortran compiles a module on OSX which declares defined size arrays the
resulting module object file contains the array's allocated memory making the
files potentially enourmous. e.g.
module test_module
real, dimension(1000) :: a
end module test_module
gfortran -c test_module.f90
If
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-20 10:31 ---
Fixed by:
2006-12-11 Aldy Hernandez <[EMAIL PROTECTED]>
Diego Novillo <[EMAIL PROTECTED]>
* gcc.dg/tree-ssa/pr26421.c: Likewise
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-20 10:26 ---
Is this still valid?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-20 10:20
---
(In reply to comment #7)
> 1) The actual cause of the ICE.
That point is unfortunately beyond my understanding.
> 2) The difference between precision and type bitsize in this situation.
>
> We have to decide if
On 8/20/07, Nick Clifton <[EMAIL PROTECTED]> wrote:
> But before I check such a patch in I would like to know if the gcc
> error message is really correct, or if I have run across a
> gimplification bug.
As mentioned before this error message is really an internal error, we
really should be
Hi Guys,
I tried bootstrapping the mainline gcc sources over the weekend,
using the current mainline binutils sources in an integrated source
tree. The bootstrap failed with a problem in bfd/elflink.c which I
have already reported and worked around. The build then failed
later on with
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-20 09:44 ---
Which is because...
TREE_OPERAND (pos, 1) = fold_build2 (PLUS_EXPR, itype,
fold_convert (itype,
TREE_OPERAND (pos, 1)),
--- Comment #6 from richard at codesourcery dot com 2007-08-20 09:40
---
Subject: Re: [4.3 Regression] internal compiler error: RTL check: expected
code 'reg', have 'subreg' in rhs_regno, at rtl.h:956
"bonzini at gnu dot org" <[EMAIL PROTECTED]> writes:
> --- Comment #5 from bonzi
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-08-20 09:27
---
Re-opening, 4.2 is still affected.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-20 09:23 ---
offset is not host_integerp because it has the overflow flag set because
-1 in a.c[-1] has the overflow flag set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-20 09:18 ---
This testcase needs a rereduction, the two reductions here work now.
Reducing now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30840
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-20 09:13 ---
Any news on this?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirme
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-20 09:13 ---
Even the non reduced testcase works now, so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from Joey dot ye at intel dot com 2007-08-20 08:53 ---
(In reply to comment #1)
> Nobody does "make install" with -j.
I guess so, that's why I set it "minor". But does that mean error is expected
with -j? My script had -j by accident and it costed me hours to identify the
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-20 08:52 ---
I get the original ICE now.
(gdb) p debug_generic_expr (stmt)
return
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
--- Comment #10 from ht990332 at gmail dot com 2007-08-20 08:51 ---
Will 4.2.2 get this fix or only trunk?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-20 08:49 ---
Fixed on the trunk, most likely by:
2007-08-19 Daniel Berlin <[EMAIL PROTECTED]>
Fix PR 32772
Fix PR 32716
Fix PR 32328
Fix PR 32303
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-20 08:48 ---
Fixed on the mainline now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 121 matches
Mail list logo
