include usr/include/net/if.h
[EMAIL PROTECTED]:~/Files/Test$ gcc -v test.c -o test
/usr/local/bin/gcc -v test.c -o test
Using built-in specs.
Target: ia64-hp-hpux11.23
Configured with: /tmp/gcc-4.0.2.tar.gz/gcc-4.0.2/configure
--host=ia64-hp-hpux11.23 --target=ia64-hp-hpux11.23
In this code,
unsigned short
crc (unsigned short crc, unsigned char data)
{
unsigned char i, x16;
for (i = 0; i 8; i++)
{
x16 = (data ^ (unsigned char) crc) 1;
data = 1;
if (x16)
{
crc ^= 0x4002;
crc = 1;
--
bonzini at gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||16798, 18395
Severity|normal |enhancement
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-09 09:48 ---
I can reproduce the ICE on i686 with 3.4.4, but it seems to be fixed with
g++ (GCC) 3.4.6 20060110 (prerelease) which tells us
testLatency.cc: In function `latency latencyOf(size_t, widthTag, widthTag,
int)':
--- Comment #12 from jason at gcc dot gnu dot org 2006-02-09 09:54 ---
Subject: Bug 22439
Author: jason
Date: Thu Feb 9 09:54:36 2006
New Revision: 110789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110789
Log:
PR c++/25979
* tree.def: Elaborate on difference
--- Comment #13 from jason at gcc dot gnu dot org 2006-02-09 09:54 ---
Subject: Bug 24365
Author: jason
Date: Thu Feb 9 09:54:36 2006
New Revision: 110789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110789
Log:
PR c++/25979
* tree.def: Elaborate on difference
--- Comment #10 from jason at gcc dot gnu dot org 2006-02-09 09:54 ---
Subject: Bug 25979
Author: jason
Date: Thu Feb 9 09:54:36 2006
New Revision: 110789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110789
Log:
PR c++/25979
* tree.def: Elaborate on difference
--- Comment #10 from jason at gcc dot gnu dot org 2006-02-09 09:54 ---
Subject: Bug 16405
Author: jason
Date: Thu Feb 9 09:54:36 2006
New Revision: 110789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110789
Log:
PR c++/25979
* tree.def: Elaborate on difference
--- Comment #1 from cadetg at googlemail dot com 2006-02-09 09:59 ---
if I change the system lib getppdp.h from extern union mpinfou spu_info[]; to
extern union mpinfou spu_info; it works. But I don't know if it is really a
good idea to change the system lib...
--
cadetg at
I expect the following snippet to compile without errors (even a warning(s)
should be parametrized).
As stated in [class.temporary]/5, the temporaries can be bound to non-const
references too...
struct A {};
A fct() { return A(); }
int main(int, char**)
{
const A aConstRef = fct(); //
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-09 10:06 ---
and see which -march is really in effect
^^^! so please show output of '-v' added. If that still doesn't show i686 or
up, please attach preprocessed source (-save-temps produces a Wraphelp.i for
you)
--
--- Comment #3 from pcarlini at suse dot de 2006-02-09 11:53 ---
Working on it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-02-09 12:38
---
Subject: Bug 26180
Author: dnovillo
Date: Thu Feb 9 12:38:35 2006
New Revision: 110794
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110794
Log:
PR 26180
* tree-vrp.c
--- Comment #4 from dnovillo at gcc dot gnu dot org 2006-02-09 12:42
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00743.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
public class poo
{
Object bar (boolean[] bb)
{
return bb.clone();
}
}
ecj generates:
1: invokevirtual Method java.lang.Object.clone ()java.lang.Object
BEA generates (with -source 1.5):
1: invokevirtual Method [Z.clone ()java.lang.Object
and with -source 1.4:
1: invokevirtual
--- Comment #1 from aph at gcc dot gnu dot org 2006-02-09 12:53 ---
Cross-reference https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180418
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Priority|P1
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-09 13:32 ---
Fixed on the mainline by:
PR tree-opt/24365
* tree-inline.c (declare_return_variable): Also clear
DECL_COMPLEX_GIMPLE_REG_P as needed in the modify_dest case.
--
pinskia at gcc dot gnu
--enable-threads --disable-libgcj
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.3 20060209 (prerelease)
$ /opt/gcc-svn/trunk/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/opt/gcc-svn/trunk
--enable-threads
Thread model: posix
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-09 13:35
---
Fixed on the mainline at least for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-09 13:38 ---
Still a bug on the 4.1 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26180
--- Comment #6 from dnovillo at gcc dot gnu dot org 2006-02-09 13:40
---
Subject: Bug 26180
Author: dnovillo
Date: Thu Feb 9 13:40:52 2006
New Revision: 110795
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110795
Log:
PR 26180
* tree-vrp.c
--- Comment #7 from dnovillo at gcc dot gnu dot org 2006-02-09 13:41
---
.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-09 13:51 ---
Actually it's already fixed in 3.4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from aph at gcc dot gnu dot org 2006-02-09 14:03 ---
Subject: Bug 26192
Author: aph
Date: Thu Feb 9 14:03:17 2006
New Revision: 110798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110798
Log:
2006-02-09 Andrew Haley [EMAIL PROTECTED]
PR java/26192
Hi,
it seems that the
if(val=max) val=max;
statement is on some processors faster than
if(valmax) val=max;
I will attach a testcase, which shows that the first version seems to be faster
on amd based systems, the second version on intel based systems. Might be
something -O can detect and
--- Comment #3 from aph at gcc dot gnu dot org 2006-02-09 14:05 ---
Subject: Bug 26192
Author: aph
Date: Thu Feb 9 14:05:31 2006
New Revision: 110799
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110799
Log:
2006-02-09 Andrew Haley [EMAIL PROTECTED]
PR java/26192
--- Comment #1 from snakebyte at gmx dot de 2006-02-09 14:05 ---
Created an attachment (id=10813)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10813action=view)
testcase for possible optimization
This is the used benchmark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26196
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Priority|P3 |P5
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-09 14:07 ---
Your benchmark is flawed in many different ways.
First the branch prediction cache is not going to be warm in your benchmark
unlike real code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26196
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-09 14:14 ---
Subject: Bug 26134
Author: pinskia
Date: Thu Feb 9 14:13:57 2006
New Revision: 110800
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110800
Log:
2006-02-09 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-09 14:15 ---
The orginal problem as I reported is fixed. The next problem just requires a
tree combiner or forward-prop to handle this case also.
Closing as fix, if someone wants to open a new bug for the problem comment #1,
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-09 14:18 ---
All you are saving is one or two instructions if val == max, in real life that
is usually no more than 0.1% now if it was really in the hot loop, it might be
1-2% depending on how hot the loop really is.
--
--- Comment #4 from snakebyte at gmx dot de 2006-02-09 14:18 ---
wow, thats a fast reply. You got a pointer on how to warm the branch prediction
cache or is this all a no-issue an we can mark this as not a bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26196
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-09 14:31 ---
Subject: Bug 26179
Author: pinskia
Date: Thu Feb 9 14:31:28 2006
New Revision: 110801
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110801
Log:
2006-02-09 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-09 14:32 ---
Fixed. Thanks for your report.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from roger at eyesopen dot com 2006-02-09 14:41 ---
Hi David, nm $objdir/gcc/libgcc.a contains both __ctzdi2 and __ctzti2 for me.
grasp% nm libgcc.a | grep ctz
_ctzsi2.o:
T __ctzdi2
_ctzdi2.o:
T __ctzti2
The post-commit bootstrap and regression test
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-09 14:46
---
Subject: Bug 25251
Author: pinskia
Date: Thu Feb 9 14:46:04 2006
New Revision: 110802
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110802
Log:
2006-02-09 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-09 14:46
---
Fixed now in 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following testcase triggers an ICE when compiled with
-O2 -ftree-vectorize on x86_64-unknown-linux-gnu (mainline):
=
struct A
{
int* x[2];
A() { for (int** p=x; px+2; ++p) *p = 0; }
};
struct B
{
char c;
A a0, a1, a2, a3, *p;
B()
--- Comment #11 from roger at eyesopen dot com 2006-02-09 14:54 ---
p.s. I can also confirm that this patch fixes the test case in PR25028 for me
on mips-sgi-irix6.5. This failed previously with undefined references to
__floattisf and __floattidf, but now not only compiles and links
--- Comment #4 from roger at eyesopen dot com 2006-02-09 15:00 ---
My recent fix for PR target/22209 adding TImode support for MIPS, just fixed
this
PR's testcase for me on mips-sgi-irix6.5. The new fix*.c and float*.c source
files may be useful in resolving the remaining PR25028 issue
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-09 15:10 ---
Confirmed. (there is a missed optimization here also which Richard G. and I am
looking at right now).
Anyways,
Before:
# p_247 = PHI D.2477.a0.x[0](2);
L183:;
# TMT.32_246 = V_MAY_DEF TMT.32_255;
*p_247 =
--- Comment #33 from tobi at gcc dot gnu dot org 2006-02-09 15:12 ---
Thomas,
I'm seeing the following failure on the trunk:
Running /home/pcl331/schluter/src/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/unf_io_convert_4.f90 -O0 execution test
FAIL:
--- Comment #9 from tobi at gcc dot gnu dot org 2006-02-09 15:24 ---
For the record, Walt Brainerd's testcase from #6 is as follows:
PROGRAM fc107
! Submitted by Walt Brainerd, The Fortran Company
! GNU Fortran 95 (GCC 4.1.0 20050322 (experimental))
! Windows XP
! Output should
--- Comment #2 from tobi at gcc dot gnu dot org 2006-02-09 15:25 ---
This is a duplicate, because the patch I'm about to send for PR14771 also fixes
this.
*** This bug has been marked as a duplicate of 14771 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from tobi at gcc dot gnu dot org 2006-02-09 15:25 ---
*** Bug 20894 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14771
struct A
{
int* x[2];
A() { for (int** p=x; px+2; ++p) *p = 0; }
};
struct B
{
char c;
A a0, a1, a2, a3, *p;
B() {}
B(const B b) : c(), a0(b.a0), p(b.p) {}
~B() { delete p; }
};
inline void foo(const B b) { new B(b); }
void bar()
{
foo(B());
foo(B());
}
After cfg_cleanup
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-09 15:43 ---
Confirmed, this testcase is from PR 26197.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-09 15:45 ---
(In reply to comment #1)
Confirmed. (there is a missed optimization here also which Richard G. and I
am
looking at right now).
This missed optimization is filed as PR 26198.
--
--- Comment #11 from tobi at gcc dot gnu dot org 2006-02-09 15:55 ---
Adding Walt Brainerd, as requested in
http://gcc.gnu.org/ml/fortran/2005-04/msg00344.html.
Patch posted here: http://gcc.gnu.org/ml/fortran/2006-02/msg00172.html
--
tobi at gcc dot gnu dot org changed:
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|Tobias dot Schlueter at |unassigned at gcc dot gnu
|physik dot uni-muenchen
--- Comment #3 from tobi at gcc dot gnu dot org 2006-02-09 16:00 ---
Duplicate as it's automatically fixed by the patch for PR14771
*** This bug has been marked as a duplicate of 14771 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from tobi at gcc dot gnu dot org 2006-02-09 16:00 ---
*** Bug 25048 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14771
--- Comment #3 from law at redhat dot com 2006-02-09 16:03 ---
Subject: Re: [4.2 regression] ICE in
is_old_name, at tree-into-ssa.c:466
On Thu, 2006-02-09 at 15:10 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org
The following code snippet triggers an ICE on mainline when
compiled with -O3 -g (on x86_64-unknown-linux-gnu):
===
struct A
{
double x[3];
double get() const { return x[0]; }
};
A bar2(const A a)
{
A a1;
for (int i=0; i3; ++i)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-09 16:39 ---
Confirmed, it worked with 4.2.0 20051217.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
cc1 (from frsely built compiler) segfaults on the following commands
% g++ -v --help
[...]
/home/gdr/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -quiet -v help-dummy -quiet
-
dumpbase help-dummy -mtune=generic -auxbase help-dummy -version --help -o
/tmp/c
ceCzZP2.s
The following options are
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-02-09 16:51
---
Confirmed.
Even simpler testcase:
===
namespace N
{
namespace M = N;
namespace M {}
}
===
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pcarlini at suse dot de 2006-02-09 17:24 ---
Martin, I have a patch in the making which is supposed to fix the problem.
However, with that patch applied, your testcase still fails the third
assertion, that is 'assert (-1 == ifs.tellg ());' at line 15, because tellg
--- Comment #5 from sebor at roguewave dot com 2006-02-09 17:29 ---
Here's my analysis copied from the post on the Sun C++ Forum.
According to 27.6.1.3, p36a, tellg() behaves as an unformatted input function
(as described in 27.6.1.3, p1).
From 27.6.1.3, p1: Each unformatted input
--- Comment #6 from pcarlini at suse dot de 2006-02-09 17:35 ---
(In reply to comment #5)
Here's my analysis copied from the post on the Sun C++ Forum.
[snip]
Ah, now I remember thanks! It's a very old issue, unrelated to the present one,
I remember discussing it briefly with
--- Comment #7 from sebor at roguewave dot com 2006-02-09 17:43 ---
Sure, whatever works for you :)
FWIW, I find the current behavior in this specific case quite reasonable (i.e.,
it seems reasonable to expect to be able to get the current position even when
the stream has reached the
--- Comment #5 from janis at gcc dot gnu dot org 2006-02-09 18:01 ---
Subject: Bug 23348
Author: janis
Date: Thu Feb 9 18:01:31 2006
New Revision: 110809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110809
Log:
Backport from mainline:
2005-12-28 Tobias
--- Comment #5 from janis at gcc dot gnu dot org 2006-02-09 18:01 ---
Subject: Bug 21945
Author: janis
Date: Thu Feb 9 18:01:31 2006
New Revision: 110809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110809
Log:
Backport from mainline:
2005-12-28 Tobias
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-09 18:03 ---
opts.c is being miscompiled by reload.
This is a dup of bug 25636.
*** This bug has been marked as a duplicate of 25636 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #30 from pinskia at gcc dot gnu dot org 2006-02-09 18:03
---
*** Bug 26200 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I have been contacted about compiling MUMPS.
http://graal.ens-lyon.fr/MUMPS/MUMPS_4.6.tar.gz
For some reason, gfortran 4.1.0 writes out __convert_i4_i8
as a function within a module. The question is why?
gfc -O2 -Wfatal-errors -I../libseq -Dpord -I. -I../include -c dmumps_ooc.F
gfc -O2
--- Comment #5 from sje at cup dot hp dot com 2006-02-09 18:55 ---
A patch to binutils was submitted and checked in for this. The test will pass
with the latest binutils now. I am not sure if the defect should be closed or
not.
Binutils patch:
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-02-09 19:12
---
Possibly related to the patch for PR 25716 (committed to mainline 2005-01-25).
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from amylaar at gcc dot gnu dot org 2006-02-09 19:17
---
Subject: Bug 16194
Author: amylaar
Date: Thu Feb 9 19:17:09 2006
New Revision: 110810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110810
Log:
PR inline-asm/16194
gcc:
* tree.h
--- Comment #8 from dje at gcc dot gnu dot org 2006-02-09 19:30 ---
Try adding the legitimize_reload_address fragment for unaligned offset from
gcc-4.X:
/* Force ld/std non-word aligned offset into base register by wrapping
in offset 0. */
if (GET_CODE (x) == PLUS
--- Comment #34 from tkoenig at gcc dot gnu dot org 2006-02-09 20:03
---
(In reply to comment #33)
Hi Tobi,
I'm seeing the following failure on the trunk:
Running /home/pcl331/schluter/src/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/unf_io_convert_4.f90 -O0
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-02-09 20:25
---
Fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-02-09 20:26 ---
I got a patch... now where to put the testcase...
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-02-09 20:54 ---
Subject: Bug 26141
Author: amylaar
Date: Thu Feb 9 20:54:12 2006
New Revision: 110811
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110811
Log:
PR target/26141
gcc:
* sh.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-09 21:07 ---
Fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from themgt at mail dot ru 2006-02-09 21:08 ---
I have to excuse myself, this is not a gcc bug!
I found out, that the only cmov-infected binaries were those of xorg.
It is a problem of mmx/sse inlcudes in their files:
https://bugs.freedesktop.org/show_bug.cgi?id=5093
So
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-02-09 21:45 ---
(In reply to comment #3)
I am currently regtesting the backported patch (merged cleanly except for
ChangeLogs) in the 4.1 branch for sh-elf and sh64-elf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26141
--- Comment #19 from amylaar at gcc dot gnu dot org 2006-02-09 21:53
---
(In reply to comment #17)
I am currently testing the back-merged patch in the 4.1 branch on
i686-pc-linux-gnu native, X sh-elf, X sh64-elf, X arm-elf and X cris-elf.
I have no intention on working on this bug in
--- Comment #19 from rakdver at gcc dot gnu dot org 2006-02-09 22:34
---
Subject: Bug 24762
Author: rakdver
Date: Thu Feb 9 22:34:23 2006
New Revision: 110815
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110815
Log:
PR rtl-optimization/24762
* df-scan.c
--- Comment #20 from rakdver at gcc dot gnu dot org 2006-02-09 22:34
---
Fixed.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #22 from steven at gcc dot gnu dot org 2006-02-09 22:59 ---
Fascinating how quickly review happens for a patch for a P1 bug report blocking
a release
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
--- Comment #44 from steven at gcc dot gnu dot org 2006-02-09 23:02 ---
Ping! :-)
Micha, are you going to take this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #6 from steven at gcc dot gnu dot org 2006-02-09 23:05 ---
It seems to me that this is only a SCEV enhancement request. Seb?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC|stevenb at suse dot de |
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot
--- Comment #31 from steven at gcc dot gnu dot org 2006-02-09 23:14 ---
Someone will have to investigate this one better.
According to comment #29, inlining is no longer a problem so the bug subject
line was no longer correct.
--
steven at gcc dot gnu dot org changed:
$ cat ar.java
import java.util.regex.*;
public class ar
{
public static void main (String args[])
{
Pattern p = Pattern.compile ([0-9.]++\\%);
}
}
$ gcj -C ar.java
$ gij ar
$ gij ar
Exception in thread main java.util.regex.PatternSyntaxException: At position
8 in regular expression
--- Comment #2 from pault at gcc dot gnu dot org 2006-02-09 23:23 ---
Subject: Bug 25059
Author: pault
Date: Thu Feb 9 23:23:28 2006
New Revision: 110816
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110816
Log:
2006-02-09 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #11 from pault at gcc dot gnu dot org 2006-02-09 23:23 ---
Subject: Bug 26038
Author: pault
Date: Thu Feb 9 23:23:28 2006
New Revision: 110816
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110816
Log:
2006-02-09 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #2 from pault at gcc dot gnu dot org 2006-02-09 23:23 ---
Subject: Bug 25070
Author: pault
Date: Thu Feb 9 23:23:28 2006
New Revision: 110816
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110816
Log:
2006-02-09 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-02-09 23:52 ---
There is no simple way how scev could determine that x == i at the end of loop
(unless we insert something like ASSERT_EXPRs at the condition). Persuading
dom and VRP not to perform this transformation would
[...]
make[2]: Leaving directory `/tmp/gcc-4.0.2/build'
make[2]: Entering directory `/tmp/gcc-4.0.2/build/stage2-gcc'
/tmp/gcc-4.0.2/build/prev-gcc/xgcc -B/tmp/gcc-4.0.2/build/prev-gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC
-W -Wall -Wwrite-strings
[...]
make[2]: Leaving directory `/tmp/gcc-4.0.2/build'
make[2]: Entering directory `/tmp/gcc-4.0.2/build/stage2-gcc'
/tmp/gcc-4.0.2/build/prev-gcc/xgcc -B/tmp/gcc-4.0.2/build/prev-gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC
-W -Wall -Wwrite-strings
--- Comment #1 from pierre42d at 9online dot fr 2006-02-10 00:03 ---
title error sorry
--
pierre42d at 9online dot fr changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-10 00:05 ---
What options did you pass to configure?
And yes this is a bug but it should not effect compiling with the default
options.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26204
--- Comment #13 from tobi at gcc dot gnu dot org 2006-02-10 00:10 ---
Subject: Bug 14771
Author: tobi
Date: Fri Feb 10 00:10:47 2006
New Revision: 110819
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110819
Log:
fortran/
2006-02-09 Tobias Schlueter [EMAIL PROTECTED]
struct Simple
{
int a;
};
template typename T, int T::*U struct Test
{
void Foo(T *obj, int v)
{
if (U != 0)
obj-*U = v;
}
};
int main(int argc, const char **argv)
{
TestSimple, Simple::a t1;// ok
TestSimple, 0 t2; // error, but should
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-10 01:19 ---
Comeau gives the following error:
ComeauTest.c, line 19: error: argument of type int is incompatible with
template parameter of type int Simple::*
TestSimple, NULL t2; // error, but
1 - 100 of 109 matches
Mail list logo
