--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-23 08:09
---
can't open .class, even though it exists: Too many open files
Add:
perror (can't open .class, even though it exists);
after the call to JCF_OPEN_EXACT_CASE in find_class and you get the error.
--
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-01-23 08:23
---
The temp zip file was being stayed opened even though it was empty. This
caused us to open too many files.
Anyways, I have a fix now:
Index: ../../gcc/java/jcf-io.c
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-01-23 08:28
---
Here is a better patch (with correct formating):
Index: ../../gcc/java/jcf-io.c
===
--- ../../gcc/java/jcf-io.c (revision 121050)
+++
--- Comment #2 from georg dot viehoever at web dot de 2007-01-23 08:30
---
Wow, that was fast.
You probably mean -fno-math-errno, or -ffast-math, which implies this. I have
verified the effect, and it works.
Thanks,
Georg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30545
--- Comment #15 from andreast at gcc dot gnu dot org 2007-01-23 08:44
---
Hah, that's why it builds here:
Darwin wolfram.local 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT
2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc
[wolfram:head/gcc/boehm-gc]
--- Comment #15 from Bil dot Kleb at NASA dot gov 2007-01-23 08:44 ---
I tried out the one dated 23-jan-07, but it was apparently also configured with
checks:
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --disable-checking to disable checks.
--
--- Comment #9 from patchapp at dberlin dot org 2007-01-23 08:50 ---
Subject: Bug number PR c++/17729
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-01/msg01869.html
--
Hi,
I'm not sure where to post my problem. sorry if there is a more adapted
mailing list.
After loged in with my Bugzilla account, I'm trying to add a new
Additional Comment to the bug #29845. I didn't modify any of the other
fields. I keep getting the following error message:
-
Not
gfortran -c test.f90
test.f90:8: internal compiler error: Segmentation fault
Backtrace:
0x0043c85e in mio_pointer_ref (gp=0x28) at module.c:1945
1945 p = get_pointer (*((char **) gp));
#1 0x0043ccb7 in mio_symbol_ref (symp=0x28) at module.c:2174
#2 0x0043cd39
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-23 10:34 ---
Based on the bugreport by Ignacio Fernández Galván
http://gcc.gnu.org/ml/fortran/2007-01/msg00531.html
The test case has been extracted from the Dynamo package,
http://www.pdynamo.org/Installation.html
--
On systems where possible, GCC should get knowledge about the errno location so
it can clobber the right memory location for calls only setting errno.
On glibc the errno location is obtained using a call to the __errno_location ()
library function, so the obvious thing would be to introduce
Attention: gcc-bugs@gcc.gnu.org, an email message detected as spam was sent by
you.
This notification is sent to you due to policies set by the system
administrator.
The entire message may not have reached its destination.
The spam message was reported to be: Likely spam message
Please contact
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-01-23 13:13 ---
Well, the obvious patch for the mainline is not working -- it looks like
GNATBIND is no longer fixed to use the staged ones:
/abuild/rguenther/obj/./prev-gcc/xgcc -B/abuild/rguenther/obj/./prev-gcc/
--- Comment #9 from bonzini at gnu dot org 2007-01-23 13:17 ---
Can you attach a working patch for 4.1 (for all three of GNATBIND, GNATLINK,
GNATMAKE; I prefer to err on the safe side)? Then of course we'll update it
and apply it to 4.3 first, but at least I can understand better what
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-23 13:26
---
matmul also has this problem:
$ cat a.f90
integer(kind=1) :: x(2,2), y(2,2), i
integer :: z(2,2)
print *, matmul(x,y)
!pack
!unpack
print *, maxval(x,dim=2), minval(x,dim=2)
print *, (1.2,0.2)**i
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from mueller at gcc dot gnu dot org 2007-01-23 13:33 ---
ah, no, this doesn't seem to be the same thing.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-01-23 13:52
---
Created an attachment (id=12937)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12937action=view)
patch for the mainline
This is a working patch for the mainline - GNATLINK is omitted. Note that the
only
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-23 13:57 ---
I don't get this. The enum value can be any integer apart from foo and bar.
Moreover, since it is undefined, it can be literally anything! So you need a
default: case to handle that.
In the first testcase, without a
--- Comment #4 from hjl at lucon dot org 2007-01-23 14:00 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01654.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
--- Comment #5 from hjl at lucon dot org 2007-01-23 14:03 ---
An updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01882.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
--- Comment #11 from bonzini at gnu dot org 2007-01-23 14:09 ---
You're right. gnattools is only built at the end of the bootstrap.
I'd prefer a slightly more conservative patch; I don't want to fix things later
if we know that the tools are needed somewhen during the build.
So,
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-23 14:13 ---
Could you provide a smaller testcase?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
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
As seen from the following log (building stage3)
/abuild/rguenther/obj/./prev-gcc/xgcc -B/abuild/rguenther/obj/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -gnatpg -gnata -g -O0
\
-I- -I. -Iada -I/space/rguenther/src/svn/trunk/gcc/ada
--- Comment #1 from bonzini at gnu dot org 2007-01-23 14:23 ---
Is this really a bug, or just an enhancement?
As far as I know, it's been like this forever (even when you used to make
gnat_lib_and_tools after make bootstrap).
--
bonzini at gnu dot org changed:
What
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-23 14:26 ---
It's an enhancement. Currently we do not use the finally built gnatmake, so
we'd
increase coverage if we'd do. (I just wanted to record this in a different
bug)
--
rguenth at gcc dot gnu dot org changed:
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-23 14:28 ---
What about a warning about __builtin_stdarg_start being deprecated? That will
be clearer than the current warning, and we can still keep backwards
compatibility (the user may use -Wno-deprecated to work-around the
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-23 14:35 ---
We already have a warning about discarding qualifiers somewhere. Perhaps we
could just add this to that one (saving us from yet another warning option).
--
manu at gcc dot gnu dot org changed:
What
--- Comment #12 from charlet at adacore dot com 2007-01-23 14:47 ---
Subject: Re: Top-level should pass GNATBIND, GNATLINK and GNATMAKE variables
down
GNATBIND = $(STAGE_PREFIX)gnatbind
GNATMAKE = gnatmake
GNATLINK = gnatlink
in both Make-lang.in and Makefile.in. (sidenote:
--- Comment #7 from igodard at pacbell dot net 2007-01-23 14:54 ---
My goof - sorry to trouble you
--
igodard at pacbell dot net changed:
What|Removed |Added
--- Comment #13 from paolo dot bonzini at lu dot unisi dot ch 2007-01-23
14:55 ---
Subject: Re: Top-level should pass GNATBIND, GNATLINK
and GNATMAKE variables down
True, they seem to be unused, but it's better to be consistent; for the same
reason I prefer to pass GNATLINK down
--- Comment #6 from pluto at agmk dot net 2007-01-23 15:02 ---
(In reply to comment #5)
I don't get this. The enum value can be any integer apart from foo and bar.
3.9.1/7, subnote. 43) says that enum isn't an integral type
but can be promoted to {signed/unsigned} int/long.
an
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-23 15:16
---
Confirmed. It's worth noting that the doc says the right thing:
Arguments:
PID Shall be a scalar INTEGER, with INTENT(IN)
SIGNAL Shall be a scalar INTEGER, with INTENT(IN)
STATUS (Optional) status flag
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-01-23 15:23
---
Well, I can confirm that one the reporter's code, on my i686-linux (Intel(R)
Pentium(R) III CPU family 1266MHz), whatever optimisation flags I give to
gfortran-4.3, g77-3.4.6 -O does a better job.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-23 15:32 ---
These issues have already been fixed as I can bootstrap now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from charlet at gcc dot gnu dot org 2007-01-23 15:44 ---
xnmake is an internal support tool used to automatically generate a file,
and gnattools should indeed only be built after a full bootstrap of the
compiler.
As for more coverage of gnatmake, this usage of gnatmake
--- Comment #7 from mueller at gcc dot gnu dot org 2007-01-23 15:47 ---
which revision is that? -r121081 fails here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
--- Comment #7 from mueller at gcc dot gnu dot org 2007-01-23 15:47
---
which revision is that? -r121081 fails here
revision 121050, and 121076.
-- Pinski
--- Comment #8 from pinskia at physics dot uc dot edu 2007-01-23 15:50
---
Subject: Re: [4.3 Regression] Gcc failed to bootstrap
--- Comment #7 from mueller at gcc dot gnu dot org 2007-01-23 15:47
---
which revision is that? -r121081 fails here
revision 121050,
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-23 15:55 ---
(In reply to comment #6)
an assignment of int to enum produces an error,
so how ( in defined non-hax0r way ) enum can be any integer?
if it can be, then what's difference between enum and int?
Undefined behaviour
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-23 15:57 ---
(In reply to comment #7)
* PR 12242
* PR 27975
* PR 12242
This should have been:
* PR 12242
* PR 27975
* PR 30357
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
The following small program gives an segmentation fault when compiled like
this:
extgccsrc g++ -Wall -fopenmp -O2 -I$POLDEST/ext/include -L$POLDEST/ext/lib
-otest test.cc -lblitz -lgomp -lm
test2.cc: In function int main():
test2.cc:7: internal compiler error: Segmentation fault
When removing
--- Comment #9 from hjl at lucon dot org 2007-01-23 16:00 ---
-r121081 fails here too.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #4 from bonzini at gnu dot org 2007-01-23 16:02 ---
Is the file placed in srcdir? If not, it's *right* to generate the file on
every stage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30556
--- Comment #10 from hjl at lucon dot org 2007-01-23 16:02 ---
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01882.html
works for me with revision 121081.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-23 16:04
---
For one your resolve.c patch is incorrect, see PR 30549.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-23 16:06
---
Two, I don't see any warning from cp/parser.c at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from charlet at gcc dot gnu dot org 2007-01-23 16:10 ---
Is the file placed in srcdir? If not, it's *right* to generate the file on
every stage.
Fair enough. Then there's nothing to fix or improve here.
Arno
--
charlet at gcc dot gnu dot org changed:
I just tried to compile Suse Linux package libnasl-2.2.6-40
with the new GNU C compiler version 4.3 snapshot 20070119.
I used compiler flag -O3. The compiler appeared to hang
for more than 30 minutes when compiling source code file regex.c.
I tried compiling the same file with the same compiler
--- Comment #1 from dcb314 at hotmail dot com 2007-01-23 16:13 ---
Created an attachment (id=12938)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12938action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-23 16:25 ---
This should be fixed with
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01728.html I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
--- Comment #5 from mueller at gcc dot gnu dot org 2007-01-23 16:26 ---
fortran seems to bootstrap now.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-23 16:27 ---
Can you attach the preprocessed source?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-01-23 16:37
---
Subject: Bug 30541
Author: rguenth
Date: Tue Jan 23 16:37:09 2007
New Revision: 121082
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121082
Log:
2007-01-23 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #13 from martin at mpa-garching dot mpg dot de 2007-01-23
16:53 ---
Could this be an enable-checking issue?
I'm only seeing the problem when configuring with --enable-checking=release,
otherwise the compiler bootstraps fine.
This is on i686-pc-linux-gnu.
(I also have
I have
lrwxrwxrwx 1 root root 12 Jan 22 14:54 /usr/bin/gnatchop - gnatchop-4.1
-rwxr-xr-x 1 root root 285224 Nov 25 12:24 /usr/bin/gnatchop-4.1
calling
gnatchop x.adb
works as expected, calling
gnatchop-4.1 x.adb
does not (PR29127), and
/usr/bin/gnatchop x.adb
doesn't work either!
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-23 17:09 ---
The testsuite is fixed by the following which should be safe because we're
adding the path of $host_gnat* to PATH first.
Index: run_acats
===
---
--- Comment #14 from hjl at lucon dot org 2007-01-23 17:22 ---
With revision 121082, I still got
cc1: warning/export/build/gnu/gcc/build-ia64-linux/./prev-gcc/xgcc
-B/export/build/gnu/gcc/build-ia64-linux/./prev-gcc/
-B/usr/gcc-4.3/ia64-unknown-linux-gnu/bin/ -c
--- Comment #2 from supermar at gmx dot de 2007-01-23 17:22 ---
The uncompressed preprocessed source is 1,7MB (unless I'm doing something wrong
here, it's just the -E flag to the usual compiler call, right?).
I uploaded it to http://data.marssoft.de/attachment-bug-30558.bz2
Thanks.
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-23 17:27 ---
Subject: Bug 30560
Author: rguenth
Date: Tue Jan 23 17:27:22 2007
New Revision: 121083
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121083
Log:
2007-01-23 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #1 from tbm at cyrius dot com 2007-01-23 17:51 ---
My backtrace looks slightly different but I can confirm this bug for
arm-linux-gnueabi. Lennert Buytenhek reported on debian-arm that fortran fails
to bootstrap when building natively and I verified that the testcase also
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
Here's a test case for the problem I point out in c++std-lib-17897. It shows
that operator(int) behaves differently (and, I claim, incorrectly) from
operator(long) or any other extractor except the one for short (which is
affected for the same reason).
$ cat t.cpp g++ t.cpp -static ./a.out
--- Comment #22 from patchapp at dberlin dot org 2007-01-23 19:45 ---
Subject: Bug number PR7651
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-01/msg01933.html
--
--- Comment #2 from hjl at gcc dot gnu dot org 2007-01-23 20:01 ---
Subject: Bug 30550
Author: hjl
Date: Tue Jan 23 20:01:40 2007
New Revision: 121086
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121086
Log:
2007-01-23 H.J. Lu [EMAIL PROTECTED]
PR libgcj/30550
--- Comment #3 from hjl at lucon dot org 2007-01-23 20:08 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #7 from pluto at agmk dot net 2007-01-23 20:15 ---
(In reply to comment #4)
Subject: Re: missed warnings about comparisons which are always true/false.
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Wextra warns for this, what is the bug?
I believe pluto
--- Comment #3 from pluto at agmk dot net 2007-01-23 20:15 ---
*** Bug 29694 has been marked as a duplicate of this bug. ***
--
pluto at agmk dot net changed:
What|Removed |Added
--
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
I just tried to compile Suse Linux package limal-ca-mgm-1.2.9-14
with the GNU C++ compiler version 4.3 snapshot 20070119.
The compiler said
/usr/include/blocxx/List.hpp: In member function 'void
blocxx4::ListT::push_back(const T) [with T = blocxx4::String]':
/usr/include/blocxx/List.hpp:362:
--- Comment #1 from dcb314 at hotmail dot com 2007-01-23 20:55 ---
Created an attachment (id=12939)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12939action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-23 20:56 ---
Some more debug information:
The error occurs when the symbol hessian is written.
The error is gone if one removes the : only ENERGY_CONSTRAINT or the use
atoms from the POTENTIAL_ENERGY module (if you have
I just tried to compile Suse Linux package lsvpd-0.16.0-35
with the GNU C compiler version 4.3 snapshot 20070119.
The compiler said
cc -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-unit-at-a-time -I../lib
-c -o node_handler.o node_handler.c
node_handler.c:213: error: inlined_to pointer is
--- Comment #1 from dcb314 at hotmail dot com 2007-01-23 20:57 ---
Created an attachment (id=12940)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12940action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
I just tried to compile Suse Linux package lynx-2.8.6_rel2-23
with the GNU C compiler version 4.3 snapshot 20070119.
The compiler said
gcc -DLINUX -D_GNU_SOURCE -DHAVE_CONFIG_H -I../.. -I../../src
-I../../src/chrtrans -I../../WWW/Library/Implementation -I../../ -O3
-fmessage-length=0
--- Comment #1 from dcb314 at hotmail dot com 2007-01-23 21:00 ---
Created an attachment (id=12941)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12941action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
--- Comment #36 from rakdver at gcc dot gnu dot org 2007-01-23 21:19
---
Patch for 4.2: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01941.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-23 21:19 ---
reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-23 21:27 ---
I get
./cc1 -quiet t.i -O -fno-unit-at-a-time t.i: In function atof:
t.i:1156: internal compiler error: in optimize_inline_calls, at
tree-inline.c:2674
Please submit a full bug report,
with preprocessed source if
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-23 21:29 ---
Nice one.
(gdb) up
#1 0x085aa055 in extract_range_from_assert (vr_p=0xbf806324, expr=0xb7ba1ee8)
at /home/richard/src/trunk/gcc/tree-vrp.c:845
845 gcc_assert (limit != var);
(gdb) call debug_generic_expr
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-23 21:36 ---
This is most likely a dup of bug 30537.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |tree-optimization
Keywords|
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-23 21:55 ---
Honza, we're not folding the comparison on inlining and later ICE in tree-vrp
because of this (from the einline dump):
# fp1_5 = PHI fp1_7(5), fp1_4(8), fp1_4(9)
L7:;
i_30 = fp0_6;
goto bb 14 (L10);
L18:;
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-23 21:56 ---
Created an attachment (id=12942)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12942action=view)
somewhat reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |tree-optimization
Keywords|
--- Comment #9 from andreast at gcc dot gnu dot org 2007-01-23 22:10
---
Here is what I get when I add -ansi to the CXX flags:
gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'void
gnu::java::nio::channels::FileChannelImpl::implTruncate(jlong)':
--- Comment #5 from simartin at gcc dot gnu dot org 2007-01-23 22:34
---
Subject: Bug 27492
Author: simartin
Date: Tue Jan 23 22:33:51 2007
New Revision: 121089
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121089
Log:
2007-01-23 Simon Martin [EMAIL PROTECTED]
PR
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot
|dot org
Hi,
the attached code, when compiled with the following gcc:
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../../gcc-SVN-20070121/gcc-SVN-20070121/configure
--prefix=/usr/local/MDLinux/opt/gcc-4.3
--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz 2007-01-23
23:08 ---
Created an attachment (id=12943)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12943action=view)
Triggers the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30565
--- Comment #14 from drab at kepler dot fjfi dot cvut dot cz 2007-01-23
23:19 ---
I've tested my original testcase for this bug and it seems to work for me on
i686 and gcc version 4.3.0 20070121 (experimental). So, it seems to be fixed.
Can anyone confirm, please?
--
The following program:
void f( int x )
{
class InnerClass
{
public:
static void g( int x )
{
// empty
}
};
}
produces a warning:
t.cc: In static member
--- Comment #2 from drab at kepler dot fjfi dot cvut dot cz 2007-01-23
23:34 ---
(In reply to comment #0)
gcc -O1 -ftree-pre -ftree-loop-linear -funroll-loops -c psycho_n1.c -o
psycho_n1.o
...
Removal of any of the
--- Comment #3 from astrange at ithinksw dot com 2007-01-23 23:36 ---
If they are the same size (and there is no speed impact), there is actually no
point to expect that they should compile to the same thing.
Of course; I meant that they're the same size at the moment. The optimal
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-23 23:43 ---
Created an attachment (id=12944)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12944action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-01-23 23:46 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Platform:
Fedora Core release 4 (Stentz)
Linux sharptail.lbl.gov 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT
2005 i686 i686 i386 GNU/Linux
% g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /net/rosie/scratch2/rwgk/gcc-4_2-branch/configure
1 - 100 of 140 matches
Mail list logo
