--- Additional Comments From rth at gcc dot gnu dot org 2005-01-28 08:11
---
I'm starting to think there's something wrong with the system 64-bit libc.
Lets close for now, and I'll report again if I can find something reproducible.
--
What|Removed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28
08:16 ---
IMO, sparc.h's LINK_GCC_C_SEQUENCE_SPEC probably is specific to solaris and
not
generally applicable. May-be, it's an historic artefact.
As I already said, it is generally applicable and not specific
--- Additional Comments From ralf dot corsepius at rtems dot org
2005-01-28 09:17 ---
(In reply to comment #2)
IMO, sparc.h's LINK_GCC_C_SEQUENCE_SPEC probably is specific to solaris and
not
generally applicable. May-be, it's an historic artefact.
As I already said, it is
I was doing some experiments and I discovered that I can access a private member
function if I make it virtual and do few other tricks. The code is below.
The Base class called is printed. So, basically when someone wants to access
a virtual function (by explicit type casting), there is no check
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28
09:25 ---
With the patch from comment #10 I get the following extra failures:
gcc.c-torture/compile/20011130-1.c -O0 (test for excess errors)
gcc.c-torture/compile/20011130-1.c -O1 (test for excess errors)
--- Additional Comments From amit_choudhary at mindtree dot com 2005-01-28
09:29 ---
Created an attachment (id=8088)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8088action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19665
struct L { void *a; };
struct S {
static S *foo (L *x)
{
return (S *) ((char *) x - (unsigned long) (((S *) 0)-*S::a));
}
L a;
};
causes ICE in fold_convert (abort at the very end of the function).
Works fine with G++ 3.2.3-RH and HEAD.
Breakpoint 2, fold_convert (type=0x2a97b66d00,
--- Additional Comments From falk at debian dot org 2005-01-28 09:41
---
Since this cast has undefined behaviour, as a is not actually a B, any
behaviour of the program is acceptable, including what you get. Note that
private was never meant as a security feature, there are lots of ways
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28
09:49 ---
Hmm, what target, what options did you use?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
--- Additional Comments From pcarlini at suse dot de 2005-01-28 09:56
---
Thanks for the nice testcase. Is this really a GCC bug, or a binutils bug:
http://bugs.gentoo.org/show_bug.cgi?id=79711
???
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Additional Comments From pcarlini at suse dot de 2005-01-28 09:58
---
Thanks. We are now reasonably confident that the patch is safe, besides
providing a good performance improvement. Most probably we shall apply
it soon, I'll take care of the next steps. Thanks again.
--
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-28 10:01
---
Any target I have tried, any options.
It fails at least on {i386,x86_64,ppc,ppc64,s390,s390x}-redhat-linux,
with -O{0,1,2,3,s}.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28
10:16 ---
As I already said, it is generally applicable
RTEMS-gcc proves this statement is to be incorrect.
Please quote the whole sentence, not a random chunk out of context.
Anyway, I have applied a
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28
10:37 ---
It seems that, above a given size, gfortran declares the array as non-static:
$ cat a.f90
program kk
implicit none
integer, parameter :: N=32768**2
real, dimension(N) :: input
call
Is this ICE well known? (4.0.0 20050127)
struct integral_constant { };
templatetypename _Tp
struct is_function
: public integral_constant { };
template
struct is_function
: public integral_constant { };
--
Summary: ICE on (very trivial)
--- Additional Comments From joseph at codesourcery dot com 2005-01-28
11:09 ---
Subject: Re: [4.0 Regression] Compilation
SEGFAULTs with -O1 -finline-functions on the x86_64 architecture.
On Fri, 28 Jan 2005, steven at gcc dot gnu dot org wrote:
gcc.c-torture/compile/20011130-1.c
$ cat dosfile.f90
program main
character(len=1), parameter :: cr = achar(13)
write(10,'(2A)') '1',cr ! Generate CR-LF on Unix
rewind(10)
read (*,*) n
end
$ gfortran dosfile.f90
$ time ./a.out
(^C here, or this loops forever)
real0m1.260s
user0m0.000s
sys 0m0.005s
$ gfortran
-in specs.
Configured with: /scratch/gcc/configure --quiet
--prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,f95
--with-gmp=/afs/mpa/data/martin/mygmp
Thread model: posix
gcc version 4.0.0 20050128 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/f951 bug.f90
-quiet
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28
11:14 ---
This bug is shared by both g77 3.2.3 and ifort 8.1.
Good company, at least :-)
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19668
--- Additional Comments From martin at mpa-garching dot mpg dot de
2005-01-28 11:14 ---
Created an attachment (id=8089)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8089action=view)
compressed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
--
What|Removed |Added
Keywords||ice-on-valid-code
Known to fail||4.0.0
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28
11:49 ---
As always with modules, reducing is indeed painful. There are already many bugs
reported with modules and gfortran (some of them even very basic), and this
could probably be one of those. Unless you have
--
What|Removed |Added
CC||coudert at clipper dot ens
||dot fr
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28
12:19 ---
Did you try to compile this file without optimization (as is indicated in:
http://www.netlib.org/lapack/faq.html#1.26)? The code in the ?lam*.f files is
used to determine the machine precision (which
--- Additional Comments From joel at oarcorp dot com 2005-01-28 12:24
---
Subject: Re: LINK_GCC_C_SEQUENCE_SPEC doesn't play nice
with RTEMS
ebotcazou at gcc dot gnu dot org wrote:
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28
08:16 ---
IMO,
--- Additional Comments From lanius at gentoo dot org 2005-01-28 13:02
---
It may be related to this change in binutils:
http://sources.redhat.com/ml/libc-alpha/2004-12/msg00062.html
Changes from binutils 2.15.91.0.1:
2. Fix the x86_64 linker to prevent non-PIC code in shared
--
What|Removed |Added
CC||lanius at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28
13:08 ---
We agreed with you and the patch doesn't impact any target beside RTEMS.
Our link rules are not those of Solaris.
OK. Note that the current default was originally added for Linux, not Solaris.
--
--- Additional Comments From pcarlini at suse dot de 2005-01-28 13:13
---
I think HJ may be interested...
--
What|Removed |Added
CC|
--- Additional Comments From ralf dot corsepius at rtems dot org
2005-01-28 13:31 ---
Then I don't understand, why it's exactly them which apply a similar work-around
as RTEMS does:
# grep LINK_GCC_C_SEQUENCE_SPEC *.h
linux64.h:#undef LINK_GCC_C_SEQUENCE_SPEC
linux64.h:#define
--- Additional Comments From simon dot strandman at telia dot com
2005-01-28 13:35 ---
Thanks for the nice testcase. Is this really a GCC bug, or a binutils bug:
http://bugs.gentoo.org/show_bug.cgi?id=79711
Downgrading binutils from 2.15.92.0.2 to 2.15.90.0.1.1 fixed the compilation
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28
13:47 ---
Created an attachment (id=8090)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8090action=view)
Simpler example of failing C source code
This is a simpler example of failing C code (which won't
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
13:53 ---
: Search converges between 2004-11-25-014001-trunk (#656) and
2004-11-25-161001-trunk
(#657).
Confirmed.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
14:00 ---
So this is invalid, closing as such.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
14:06 ---
Started to be rejected (on the mainline at the time):
: Search converges between 2003-07-23-trunk (#302) and 2003-07-24-trunk (#303).
Started to ICE:
: Search converges between 2004-02-02-3.4 (#1) and
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
14:07 ---
I think this patch fixes the problem but I don't have time to back port it:
2004-06-08 Andrew Pinski [EMAIL PROTECTED]
* fold-const.c (fold_convert): Treat OFFSET_TYPE like
POINTER_TYPE
--- Additional Comments From ralf dot corsepius at rtems dot org
2005-01-28 14:11 ---
The patch contained in
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00405.html
doesn't seem to work for me, rsp. triggers another ICE, at least the error
message seems to have changed:
With today's
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
14:15 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02117.html.
--
What|Removed |Added
--
What|Removed |Added
Component|c++ |target
GCC build triplet|x86_64-pc-linux-gnu |
GCC host triplet|x86_64-pc-linux-gnu |
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-01-28 14:21 ---
Folding x.foo[2] == x.foo to false does not help the testcase, as fold
never sees this comparison. Instead the initial code the C++ frontend
creates for ctor and dtor of arrays contains
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-01-28 14:26 ---
One patch for empty-loop removal was posted here by Zdenek
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01679.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
14:27 ---
The timings for 3.3.2 and 4.0.0 are the same are faster for 4.0.0 so closing as
fixed.
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28
14:29 ---
The inner loop does not terminate in this example,
until a segfault is hit.
$ cat sl5-error.c
#include stdio.h
void foo(float * x);
int main()
{
float x[4];
foo (x);
return 0;
}
void foo
With LAST_UPDATED: Fri Jan 28 05:05:32 UTC 2005 I get:
Running
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
...
FAIL: gcc.c-torture/execute/builtins/strlen-3.c compilation, -O1
With the message in the gcc.log being:
Executing on host:
--- Additional Comments From martin at mpa-garching dot mpg dot de
2005-01-28 14:41 ---
OK, I managed to reduce the testcase (phew!). Here it is:
module ModelData
implicit none
Type ClTransferData
integer :: NumSources
end Type ClTransferData
Type(ClTransferData) :: CTransScal
end
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
14:42 ---
Confirmed, happens every where.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From martin at mpa-garching dot mpg dot de
2005-01-28 14:43 ---
(From update of attachment 8089)
a reduced testcase can be found in the comments
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
14:48 ---
Can someone do the timings again on x86, I think we are faster at -O1 now than
previous versions and
faster for all other optimization levels?
On ppc-darwin we speed up about 3% (-O2/-O3) to 16% (-O1)
With LAST_UPDATED: Fri Jan 28 05:05:32 UTC 2005 I get:
Running /home/hp/combined/combined/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp
...
FAIL: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times rtmem 1
With the message in the .log being:
Executing on host: /home/hp/combined/mmixware-sim/gcc/xgcc
--- Additional Comments From chris at bubblescope dot net 2005-01-28 14:53
---
I don't think this bug has anything to do with libstdc++ (which over covers
errors in the c++ standard library). I would suggest changing the Component to
c++, which I suspect a closer match for where the bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
14:59 ---
Already fixed by:
2005-01-26 Steven Bosscher [EMAIL PROTECTED]
* gcc.dg/tree-ssa/20030711-2.c: Run at -O2, not -O1.
--
What|Removed |Added
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28
14:59 ---
I think this is a duplicate of PR16861 (probably the most annoying bug on
scientific codes these days, since they do use modules a lot).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
15:02 ---
(In reply to comment #5)
I think this is a duplicate of PR16861 (probably the most annoying bug on
scientific codes these days, since they do use modules a lot).
This is not a duplicate of PR16861.
Here
--- Additional Comments From daveregs at rsaisp dot com 2005-01-28 15:10
---
Hi Chris,
I beleive that this problem may be related to the typeinfo header or other
related headers that are involved with RTTI.
I have also refered to an older bug that involved this same problem which was
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28
15:15 ---
I will do timings with a bunch of gcc3.x compilers and gcc4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-28 15:15
---
The date is wrong in ChangeLog entry quoted in comment #1 (just checked).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19671
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28
15:17 ---
Then I don't understand, why it's exactly them which apply a similar
work-around as RTEMS does:
# grep LINK_GCC_C_SEQUENCE_SPEC *.h
linux64.h:#undef LINK_GCC_C_SEQUENCE_SPEC
linux64.h:#define
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28
15:18 ---
That patch is just gross. Come on, builtin_maybe_infinite_loop?!
There are better and easier ways to kill dead loops. Like, a loop
optimizer that simply removes dead loops ;-)
--
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28
15:23 ---
I fixed the date.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19671
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-01-28 15:29 ---
Looking into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19402
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28 15:59
---
Hi Steven, I now ( gcc version 4.0.0 20050128 (experimental) )get the following,
where the first number is the timing.
multgen/basic_mult gfortran -O3 -ffast-math mult.f90
multgen/basic_mult ./a.out
In the following C source file test.c,
int compare(char const * p1, int n1, char const * p2, int n2) {
char const * q1 = p1 + n1;
char const * q2 = p2 + n2;
while (p1 q1 p2 q2) {
int n = *--q1 - *--q2;
if (n) {
return n;
}
}
return n1 - n2;
}
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28
16:23 ---
The -xN you add make ifort specialize the code for Pentium 4. So far,
nobody has cared to make GCC produce good code for the good old Pentium 4
so I would not be terribly surprised if we lose a lot just on
--- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28 16:31
---
You could try gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse
-ftree-loop-linear -ftree-vectorize yourcode.f90 and see if it helps.
Unhappily, seems to make things slower:
multgen/basic_mult
--- Additional Comments From law at redhat dot com 2005-01-28 16:36 ---
Should be fixed with today's change to fold-const.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19643
This is a bug that is specific to functions where RESULT is specified in the
function statement(function foo). In this case, the pointer itself is
printed.
Where RESULT is not specified, functions return a pointer result
correctly(function bar). Here the value pointed too is printed.
$ cat
--- Additional Comments From bangerth at dealii dot org 2005-01-28 17:01
---
atexit only takes a pointer to a function to be run on exit of the
program. The fact that this is an empty function is unbeknownst to
it, and probably the code in the middle-end that has to deal with
that. I
--- Additional Comments From prthomas at drfccad dot cea dot fr 2005-01-28
17:02 ---
Subject: RE: Runtime hang in LAPACK routine SLAMC1 - i
n Quetzal benchmark suite
Bon soir François-Xavier,
Tu as raison! Même -O1 fait coincer le programme.
Je suis étonné quand-même que le
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-01-28
17:08 ---
Francois-Xavier Coudert's comment is spot on. Reducing the optimisation to -O0
removes the need for this peculiar fix.
We could do with a repository for funnies that are not quite bugs. I SAY
REMOVE
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28
17:20 ---
(reply to comments #3 and #4)
The print statement in the code induces I/O, which in some sense disrupt the
flow of code and has the effect of making unaware of possible optimizations. I
can't offer a
On Fri, 28 Jan 2005, jv244 at cam dot ac dot uk wrote:
--- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28
16:31 ---
You could try gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse
-ftree-loop-linear -ftree-vectorize yourcode.f90 and see if it helps.
Unhappily, seems
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-28
17:22 ---
Subject: Re: missing transformations lead to
poorly optimized code
On Fri, 28 Jan 2005, jv244 at cam dot ac dot uk wrote:
--- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28
17:33 ---
Subject: Bug 19583
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-28 17:32:58
Modified files:
gcc: ChangeLog gimple-low.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28
17:33 ---
Subject: Bug 16558
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-28 17:32:58
Modified files:
gcc: ChangeLog gimple-low.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28
17:34 ---
Subject: Bug 16558
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-28 17:33:54
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From marco at gnome dot org 2005-01-28 17:35
---
Colin, is this one the cause of the setTimeStamp/getTimeStamp mismatch with
postgre jdbc? I have a testcase for that one in case it's of any use...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19649
--- Additional Comments From ian at airs dot com 2005-01-28 17:35 ---
Fixed in mainline.
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
Attachment #6629|text/plain |application/x-zip
mime type||
The following program doesn't compile:
public interface OutSideInterface
{
public interface InsideInterface
{
void m(int p, int p2);
};
}
Note the empty statement (semicolon) on line 6.
This is legal (jikes accepts it) but deprecated.
Compiling with -C gives:
OutSideInterface.java:6:
--- Additional Comments From dog at bluezoo dot org 2005-01-28 18:19
---
The relevant JLS production is ClassMemberDeclaration:
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#18988
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19674
Hi,
The small example below gives an incorrect result on 32 bit platforms. Both
tests should lead to the same result, but one is false, the other is true.
tested with the following compilers, all of them exhibiting the bug:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
18:47 ---
This is a dup of bug 323. The problem is excessive precission.
*** This bug has been marked as a duplicate of 323 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
18:47 ---
*** Bug 19675 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From ian at airs dot com 2005-01-28 18:49 ---
We aren't waiting for anything, so move out of WAITING state.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
18:53 ---
(In reply to comment #5)
I'll move this bug back to the C++ component.
Consider the following C++ code:
struct Foo { ~Foo() {} int i; };
struct A { Foo foo[2]; };
void foo () {
static A a;
}
We
--- Additional Comments From cognot at earthdecision dot com 2005-01-28
18:54 ---
(In reply to comment #1)
This is a dup of bug 323. The problem is excessive precission.
*** This bug has been marked as a duplicate of 323 ***
Hi,
Looking at the thread for bug #323 it would seem to
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
18:59 ---
Only happens on x86.
--
What|Removed |Added
Severity|critical
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
19:03 ---
I cannot test this right now but this might be fixed on the mainline.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
19:04 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From cognot at earthdecision dot com 2005-01-28
19:04 ---
(In reply to comment #3)
Only happens on x86.
True.
But only with gcc. Under Windows M$ .NET and DevStudio 6 give a correct result
if Improve float consitency is turned on.
Haven't tried with the Intel
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
19:07 ---
Really comparing two floating point with equallity is not a good thing to do.
This again is a dup of bug
323.
*** This bug has been marked as a duplicate of 323 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
19:07 ---
*** Bug 19675 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
AVR Target 20041205 snapshot
gcc version 4.0.0 20041205 (experimental)
/avrdev/libexec/gcc/avr/4.0.0/cc1.exe -quiet -v looprv.c -quiet -dumpbase
looprv.c -mmcu=atmega169 -auxbase looprv -Os -Wall -version -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -o looprv.s
Loop
--- Additional Comments From bangerth at dealii dot org 2005-01-28 19:11
---
Why do you think the front-end doesn't know that the destructor is empty?
It sees its definition, and it knows about potential destructors of
member objects and base classes, so it should have all the
--- Additional Comments From andrewhutchinson at cox dot net 2005-01-28
19:12 ---
Created an attachment (id=8092)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8092action=view)
Testcase c source
Testloop3() is NOT reversed. Others for reference are.
--
--- Additional Comments From andrewhutchinson at cox dot net 2005-01-28
19:13 ---
Created an attachment (id=8093)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8093action=view)
Expanded RTL
Expanded RTL from looprv testcase source
--
--
What|Removed |Added
Component|c |target
Keywords||missed-optimization
--- Additional Comments From andrewhutchinson at cox dot net 2005-01-28
19:14 ---
Created an attachment (id=8094)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8094action=view)
Optimised RTL
Final Optimised RTL before asm code generation.
--
Following Eclipse code snippet that fails:
protected void join(InternalJob job) {
final IJobChangeListener listener;
synchronized (lock) {
listener = new JobChangeAdapter() {
public void done(IJobChangeEvent event) {
1 - 100 of 165 matches
Mail list logo
