--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-07-27 05:14
---
Subject: Bug 28335
Author: jvdelisle
Date: Thu Jul 27 05:14:19 2006
New Revision: 115772
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115772
Log:
2006-07-26 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-07-27 05:13
---
Subject: Bug 28335
Author: jvdelisle
Date: Thu Jul 27 05:12:59 2006
New Revision: 115771
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115771
Log:
2006-07-26 Jerry DeLisle <[EMAIL PROTECTED]>
--
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
--- 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:
:
0: 94 21
--- 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 representa
--- 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=11954&action=view)
workaround patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28508
--- 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=11953&action=view)
test case
bc.s and bnc.s have the range (form -512 to 508) of PC-relative.
If all 2byte instruction h
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
1
--- 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
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 #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
--
http://gcc.gnu.org/bugzil
--- 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
--
http://gcc.gnu.org/bugzilla
--- 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=gcc&view=rev&rev=115765
Log:
PR rtl-optimization/28071
* regmove.c (reg_
--
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 #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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- 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 (pass_loop_opti
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 #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 it
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: expe
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 full
--- 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
>
>
>
> --- 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
--- 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=11952&action=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 compiler
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 bu
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
'exc
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, [etc
--- 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
--- 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 #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 #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=gcc&view=rev&rev=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=gcc&view=rev&rev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus
--- 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=gcc&view=rev&rev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus
--- 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=gcc&view=rev&rev=115763
Log:
PR tree-optimization/27882
* cgraph.c (cgra
--- 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 #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 #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 #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 #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=11951&action=view)
Current status of patch
Here's the current patch. It regtests fine, and
seems to do the Right Thing.
I haven'
--- 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 #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), parame
--- 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 mo
--- 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 #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 #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
--
$ cat radix.c
#include
#include
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 undeclared identifie
--- 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=11950&action=view)
take-II this one works at -head as well
Bon,
apparently I'm (almost) the only one who uses gcj on fr
--- 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. Wa
--- 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
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
--
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 #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
--- 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 #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=11949&action=view)
The source mentioned in description
Source that won't compile
--
http://gcc.gnu.org/bugzilla/show
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 = __gn
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 libbacke
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), a(2),
--- 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
--- 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=gcc&view=rev&rev=115760
Log:
PR rtl-optimization/27907
* expr.c (force_ope
--- 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 #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 #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.
--
htt
--- 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=11948&action=view)
test case
Testcase from application "xstow".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |target
Target Milestone|--- |4.2.0
http:/
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 T
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 fir
--- 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;
}
--
http://gcc.gnu.org/bugzill
--- 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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |target
http:
-- 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, destruc
--- 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
--- 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 constructor
--- 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=11947&action=view)
test case
Testcase from application 'john'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
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 #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
--- 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 #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=gcc&view=rev&rev=115758
Log:
gcc/
PR middle-end/28403
* optabs.c (expan
--- 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=gcc&view=rev&rev=115757
Log:
gcc/
PR middle-end/28402
* optabs.c (expan
--- 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=gcc&view=rev&rev=115756
Log:
gcc/
PR middle-end/28403
* optabs.c (expan
--- 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=gcc&view=rev&rev=115755
Log:
gcc/
PR middle-end/28402
* optabs.c (expan
--- 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 tbm at cyrius dot com 2006-07-26 13:26 ---
Created an attachment (id=11946)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11946&action=view)
test case
Testcase from application dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
--- 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=11945&action=view)
test case
Testcase from application dcraw
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
--- 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 th
$ 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 ( nics.hasM
--- 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
--
http://gcc.gnu.org/bug
--- 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 #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 G
--- 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;
sig
--- 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 an
--- 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
--
http://gcc.gnu.org/bugzil
--- 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
a
--
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- 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 difficult
--- 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 #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 #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 g
1 - 100 of 101 matches
Mail list logo
