--- Comment #7 from bonzini at gcc dot gnu dot org 2005-11-09 08:20 ---
Reduced testcase
/* { dg-do run } */
/* { dg-options "-O -fdump-tree-dom3" } */
int Link[] = { -1 };
int W[] = { 2 };
extern void abort (void);
int f (int k, int p)
{
int pdest, j, D1361;
j = 0;
pdest = 0;
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gcc dot gnu dot
|
--- Comment #8 from bonzini at gcc dot gnu dot org 2005-11-09 08:22 ---
dom3 is at fault
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
Component
internal compiler error
subroutine nhatgrid()
implicit none
integer :: lambda
real(kind=8) :: arg,sigma
real(kind=8) :: dshpfunc
dshpfunc(arg)=-lambda/sigma*(arg/sigma)**(lambda-1)*exp(-(arg/sigma)**lambda)
end subroutine nhatgrid
--
Summary: internal compiler error with st
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-09 10:08
---
(In reply to comment #5)
> Don't worry, I do. :-) It comes from the linker, trigged by the
> source code for fedisableexcept, using machinery that's set up
> by to warn for functions that shouldn't be used, like
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-09 10:12
---
(In reply to comment #3)
> I believe I have a fix for this one that works with the previous patch to
> pr24489. I am testing along with work on pr24699 to make sure we have no
> conflicts or regressions. pr24719
--- Comment #7 from hp at bitrange dot com 2005-11-09 10:24 ---
Subject: Re: [4.1 regression] testsuite
failure:gfortran.fortran-torture/execute/in-pack.f90 exe
On Wed, 9 Nov 2005, fxcoudert at gcc dot gnu dot org wrote:
> --- Comment #6 from fxcoudert at gcc dot gnu dot org 200
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-09 11:07 ---
First, a hardware failure is possible - usually just re-trying may fix the
problem or make it show up somehow different / somewhere else, if this is the
case. Second, your gcc 3.4.2 is outdated, please update to a m
--- Comment #4 from eedelman at gcc dot gnu dot org 2005-11-09 11:28
---
Subject: Bug 22607
Author: eedelman
Date: Wed Nov 9 11:27:56 2005
New Revision: 106683
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106683
Log:
fortran/
2005-11-09 Erik Edelmann <[EMAIL PROTECTED]>
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||law at gcc dot gnu dot org
Severity|normal
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24755
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 11:44 ---
Confirmed, backtrace:
#0 0x080727d3 in recursive_stmt_fcn (e=0x9fec3b8, sym=0x9fec218) at
/home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/match.c:2727
#1 0x080727b5 in recursive_stmt_fcn (e=0x9fec540, sym=0x9fec
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-09 12:01 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00389.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-09 12:01 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00388.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-09 12:02 ---
Note your testcase will fail on every target except for s390:
/* { dg-do compile } */
/* { dg-options "-O1 -mpacked-stack" } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-11-09 12:08
---
*** Bug 21957 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2005-11-09 12:08
---
*** This bug has been marked as a duplicate of 22127 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from krebbel at gcc dot gnu dot org 2005-11-09 12:18 ---
Ups sorry. I've fixed that now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |krebbel at gcc dot gnu dot
|dot org
--- Comment #2 from krebbel at gcc dot gnu dot org 2005-11-09 12:24 ---
Patch committed:
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00387.html
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #24 from pinskia at gcc dot gnu dot org 2005-11-09 12:34
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #24 from pinskia at gcc dot gnu dot org 2005-11-09 12:34
---
Fixed.
--- Comment #25 from pinskia at gcc dot gnu dot org 2005-11-09 12:34
---
Subject: Bug 24644
Author: pinskia
Date: Wed Nov 9 12:33:59 2005
New Revision: 106693
URL: http://gcc.gnu.org/viewcvs?r
--- Comment #9 from rguenth at gcc dot gnu dot org 2005-11-09 13:14 ---
It's IVCANONs fault, pr24716.c.t76.ivcanon:
...
# pdest_23 = PHI <0(1)>;
:;
return pdest_23;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #2 from pault at gcc dot gnu dot org 2005-11-09 13:17 ---
Since recursive_stmt_fcn is involved, this looks like my doing!
I'll take a look tomorrow morning.
Paul T
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from rguenth at gcc dot gnu dot org 2005-11-09 13:31
---
Or more definitely, store copyprop.
# BLOCK 1 freq:122
# PRED: 0 [100.0%] (fallthru,exec) 31 [100.0%] (fallthru,exec)
# jD.1285_18 = PHI <0(0), 1(31)>;
# pD.1281_7 = PHI ;
# kD.1280_5 = PHI ;
# WD
--- Comment #11 from rguenth at gcc dot gnu dot org 2005-11-09 13:59
---
Doh, I have a fix. What a stupid error in analyze_evolution_in_loop.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-11-09 14:01
---
Created an attachment (id=10185)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10185&action=view)
patch
this is what I'm going to test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #9 from matz at suse dot de 2005-11-09 14:49 ---
A shorter testcase (which at least breaks on SuSEs 3.3-hammer compiler) is:
---
typedef union value {
long double d;
} Value;
double ld2d(Value v) {
return v.d;
}
---
By using a signed divide for pointer arithmetic an incorerct value can be
obtained given sufficient distance between two pointers.
I have tested this on gcc 3.4 (RedHat EL4 update 1) and the same behaviour
persists.
# gcc -v -save-temps -Wall -o test ./test.c
Reading specs from /usr/lib/gcc-lib/i
--- Comment #1 from j3p0uk at hotmail dot com 2005-11-09 14:51 ---
Created an attachment (id=10186)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10186&action=view)
Test source (.i)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-09 15:07
---
(In reply to comment #10)
> Or more definitely, store copyprop.
s/store/scev/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #18 from dir at lanl dot gov 2005-11-09 15:13 ---
That was it - my system had two versions of strip.
Thanks,
Dale
The final library build has some warning messages, but they do not seem to hurt
anything -
ranlib -c .libs/libgfortranbegin.a
creating libgfortranbegin.la
(c
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-09 15:17
---
(In reply to comment #18)
> That was it - my system had two versions of strip.
Where was the second one comming from?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #16 from thebohemian at gmx dot net 2005-11-09 15:18 ---
Created an attachment (id=10187)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10187&action=view)
preliminary patch - just for review
This is another preview of the patch. The patch begins to more and more depend
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-09 15:19 ---
Why do you think this is a bug. The difference between &a[3]-&a[4] better be
-1. (where a is an array).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #17 from thebohemian at gmx dot net 2005-11-09 15:22 ---
Created an attachment (id=10188)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10188&action=view)
lazy linker test setup
This is a small update to the test setup. BC-compilation is now done with
debugging symbols
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-09 15:23
---
Hmm, do we have an ABI change in 4.1:
We get in 4.1.0:
ld2d:
.prologue
.body
fnorm.d f8 = f8
br.ret.sptk.many b0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
--- Comment #6 from uros at kss-loka dot si 2005-11-09 15:27 ---
The problem is caused by the combination of (1) x86_64 parameter passing
convention, (2) x86 instructions that _require_ parameters in specific
registers and (3) sched1 scheduling pass.
ad 1)
x86_64 passes function parame
--- Comment #18 from aph at gcc dot gnu dot org 2005-11-09 15:28 ---
It's probably not the best idea to solve everything in this bug in a single
patch.
Better make several patches, for the different issues.
Also, if there are some verifier changes needed, let's get those committed
firs
--- Comment #20 from dir at lanl dot gov 2005-11-09 15:29 ---
It was in /usr/local/bin along with a 100 or so other programs - I suppose that
one of them installed it .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #21 from pinskia at gcc dot gnu dot org 2005-11-09 15:30
---
Closing as works for me then.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from matz at suse dot de 2005-11-09 15:32 ---
You mean ABI change, because the input register seems to be f8, instead of
in0 (as would be need for this union)? I'm not sure, but it looks fishy
at least.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-09 15:53 ---
Note that obtaining the difference of pointers that don't point to the same
object is invoking undefined behavior, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-09 15:57
---
(In reply to comment #11)
> You mean ABI change, because the input register seems to be f8, instead of
> in0 (as would be need for this union)? I'm not sure, but it looks fishy
> at least.
Actually it is not an AB
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 16:26 ---
This works for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-09 16:29
---
(In reply to comment #11)
> This is reproducable on gcc mainline on amd64:
This works for me with "GNU assembler 2.16.91 20051027" with the GCC mainline
on i686-linux-gnu
And with "GNU assembler 2.16" with the GCC
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-09 16:31 ---
Works just fine here. What glibc are you using?
pr24428.c and pr24428-2.c are the only dg-do run tls tests, so perhaps
your libc doesn't support TLS at all?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
Since end of May, quite a few libstdc++-v3 testcases, stressing atomicity.h
are failing on multi-processor ia64 machines. See, for instance, in:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00411.html
FAIL: 22_locale/locale/cons/12658_thread-1.cc execution test
FAIL: 22_locale/locale/co
--- Comment #27 from jason at gcc dot gnu dot org 2005-11-09 16:58 ---
Subject: Bug 21123
Author: jason
Date: Wed Nov 9 16:58:52 2005
New Revision: 106698
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106698
Log:
PR c++/21123
* method.c (use_thunk): Use build_c
Here's the test case:
---
typedef unsigned short ushort;
namespace X
{
typedef unsigned short ushort;
}
using namespace X;
int main()
{
ushort us = 0;
}
---
prompt> g++ main.cpp
main.cpp: In function 'int main()':
main.cpp:12: error: 'ushort' was not declared in this scope
main.cpp:12:
--- Comment #1 from pcarlini at suse dot de 2005-11-09 17:00 ---
(In reply to comment #0)
> Those tests *never* fail in 4_0-branch, which doesn't use the builtins, and
> never did in mainline before the below of mine (and a simultaneous one to
> the compiler, which emptied ia64intrin.h)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 17:03 ---
This is a dup of bug 23594.
*** This bug has been marked as a duplicate of 23594 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-09 17:03 ---
*** Bug 24758 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #28 from pinskia at gcc dot gnu dot org 2005-11-09 17:04
---
Fixed in 4.0.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #16 from reichelt at gcc dot gnu dot org 2005-11-09 17:12
---
Backport for the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 17:25 ---
Related to PR 9726.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDepend
--- Comment #4 from j3p0uk at hotmail dot com 2005-11-09 17:25 ---
The test case was a simple test case where I tried to show the mathematical
behaviour in as simple a way as possible.
The reason I thought that this may be a bug is because the behaviour on a
64-bit system is different a
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 17:30 ---
This is invalid because otherwise you get the incorrect answer for &a[3]-&a[4]:
a = 0x8049668 b = 0x804966c
pointer ( a - b )
0x
non-pointer ( ( ((un
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-09 17:35 ---
Hmm you said in:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg00149.html
That was really a glibc bug.
And actually 4.0 and before uses the builtins for ia64, this is where the
builtins came from in the first place.
The code
subroutine a (emask)
implicit none
real, intent(in) :: emask(:,:,:)
logical :: left(3), right(3)
integer :: i,j,k
i=1; j=1; k=1
left=.false.
right=.false.
if (.not.right(3)) left(1) = abs(emask(i,j,k+1)-1)<0.01)
end subroutine a
contains an error in the if statement. The
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 17:39 ---
I notice that we give an unclassifiable error almost any time there is a syntax
error.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pcarlini at suse dot de 2005-11-09 17:45 ---
(In reply to comment #2)
> Hmm you said in:
> http://gcc.gnu.org/ml/libstdc++/2005-11/msg00149.html
>
> That was really a glibc bug.
Exactly *was*. Ehi, do you think I'm stupid? Of course in the meanwhile
I have checked t
--- Comment #5 from daney at gcc dot gnu dot org 2005-11-09 17:46 ---
Created an attachment (id=10189)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10189&action=view)
Program that demonstrates how shutdown can solve the problem.
Compile socktest.c thusly:
gcc -g -o soctest socte
--- Comment #1 from redi at gcc dot gnu dot org 2005-11-09 17:51 ---
We need to doc much more than that ... we don't have any docs saying which TR1
components are supported or how to make use of them, do we?
I had some changes on my hard drive adding docs to the docs/html/ext pages, but
--- Comment #4 from pcarlini at suse dot de 2005-11-09 17:51 ---
(In reply to comment #3)
> .Alternately, the ia64 builtins
> themselves can be defective, but that seems much less likely to me, because
> we are talking about a very consistent b
--- Comment #2 from pcarlini at suse dot de 2005-11-09 17:52 ---
Your are welcome!
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned a
--- Comment #14 from rguenth at gcc dot gnu dot org 2005-11-09 18:01
---
Subject: Bug 24716
Author: rguenth
Date: Wed Nov 9 18:00:59 2005
New Revision: 106700
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106700
Log:
2005-11-09 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #15 from rguenth at gcc dot gnu dot org 2005-11-09 18:02
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #2 from joseph at codesourcery dot com 2005-11-09 18:09 ---
Subject: Re: gcc.dg/tls/pr24428.c execution test and
gcc.dg/tls/pr24428-2.c execution test fail on IA32
On Wed, 9 Nov 2005, jakub at gcc dot gnu dot org wrote:
> Works just fine here. What glibc are you using?
>
--- Comment #2 from bero at arklinux dot org 2005-11-09 18:13 ---
It definitely wasn't added in binutils csl-arm-branch... Is gcc csl-arm-branch
supposed to be used with binutils head now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24695
--- Comment #6 from aph at gcc dot gnu dot org 2005-11-09 18:22 ---
Two things:
Does this work for fds that aren't associated with sockets?
It doesn't quite avoid the need for locking, since we still need to make sure
that we only close an fd once.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #5 from pfl at iis dot fhg dot de 2005-11-09 18:35 ---
Ok, I switched to MacOSX.
There I have a /usr/gnu/build/gcc-4.0.2 diectory with the original sources.
Then I do a
../gcc-4.0.2/configure --cache-file=../mips-gcc-4.0.2.configure.cache
--prefix=/usr/gnu --bindir=/usr/gn
--- Comment #5 from bkoz at gcc dot gnu dot org 2005-11-09 18:36 ---
Created an attachment (id=10190)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10190&action=view)
tentative patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23591
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-09 18:40 ---
*** This bug has been marked as a duplicate of 24755 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-09 18:40 ---
*** Bug 24655 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
-
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24646
When compiling some files, the -da option or - AFAICT - any of its constituent
options changes the generated code. When using -da, the -quiet option can also
have an effect on the generated code, although this is harder to demonstrate.
--
Summary: -d option changes generated code
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 18:52 ---
Most (if not all) of these issues are usually a pass depending on addresses
being the same.
I think David E. has a bug filed about one of these issues already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2476
--- Comment #2 from amylaar at gcc dot gnu dot org 2005-11-09 18:59 ---
Created an attachment (id=10191)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10191&action=view)
test case
Mainline version 106440 configured for i686-pc-linux-gnu --with-arch=i686:
../../i686/gcc/cc1 -fprep
--- Comment #3 from amylaar at gcc dot gnu dot org 2005-11-09 19:08 ---
Created an attachment (id=10192)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10192&action=view)
test case
This is a shorter test case, but only debug information changes were observed
for this test case. co
--- Comment #7 from daney at gcc dot gnu dot org 2005-11-09 19:24 ---
Here is the first version of my patch:
http://gcc.gnu.org/ml/java-patches/2005-q4/msg00176.html
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2005-11-09 19:30 ---
Some additional details from testresults: the bulk of the builtin atomics
changes
went in around mid of April, the ia64 specific bits, on April, 14. All the
results that Andreas sent at the beginning of the month (for insta
--- Comment #4 from amylaar at gcc dot gnu dot org 2005-11-09 19:35 ---
I have observed the -quiet influence only with a proprietary testcase so far
(EEMBC aiifft01/bmark.c for sh-elf -m4 -ml -g -O3 -version -fomit-frame-pointer
-funroll-loops --param max-inline-insns-single=5).
Comp
I have a templated function which uses inline assembler (with MMX
instructions). Inline assembler is passed pointer to array element.
When this function is instantiated for the first time, code before inline
assembler is generated correctly. When it is instantiated for the second time,
one of regis
--- Comment #1 from krzysiek-gcc dot gnu dot org at lichota dot net
2005-11-09 19:46 ---
Created an attachment (id=10193)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10193&action=view)
Testcase for the bug
This is the testcase. Compile with:
g++-4.0 -save-temps -fPIC -ggdb3 -Wn
--- Comment #3 from redi at gcc dot gnu dot org 2005-11-09 19:49 ---
Created an attachment (id=10194)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10194&action=view)
alternative fix
This bug was my fault - sorry for the dumb mistake, and not catching it.
We could leave _M_get_de
--- Comment #2 from krzysiek-gcc dot gnu dot org at lichota dot net
2005-11-09 19:49 ---
Created an attachment (id=10195)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10195&action=view)
Assembler code generated from testcase
This is code generated from testcase.
In first instant
--- Comment #3 from krzysiek-gcc dot gnu dot org at lichota dot net
2005-11-09 20:00 ---
Created an attachment (id=10196)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10196&action=view)
Correct code generated by g++ 3.4.2
This is the correct code generated by g++ 3.4.2. It loads
The killloop-branch produces wrong code for the following test due to a bug in
loop-invariant.c or code related to it.
extern "C" void abort(void);
class runtime_error {};
void test01(int iters)
{
for (int i = 0; i < iters; ++i)
{
try {
throw runtime_error();
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-09 20:12 ---
Created an attachment (id=10197)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10197&action=view)
loop2_init dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-09 20:12 ---
Created an attachment (id=10198)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10198&action=view)
loop2_invariant dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
--- Comment #9 from aoliva at gcc dot gnu dot org 2005-11-09 20:13 ---
Subject: Bug 4372
Author: aoliva
Date: Wed Nov 9 20:13:41 2005
New Revision: 106703
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106703
Log:
PR other/4372
* tree.h (IDENTIFIER_TRANSPARENT_ALIAS): New.
(TRE
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-09 20:24 ---
Simplified example:
template
int f(int i)
{
asm("%0 %1 " : "+r"(i) );
return i;
}
int main(void)
{
f<0>(0)+ f<1>(0);
}
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from aldyh at gcc dot gnu dot org 2005-11-09 20:25 ---
I'll take a look at this.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 20:28 ---
For the first time template is instantiated, we get:
__asm__("%0 %1 ":"=r" i:"0" i);
The second time, we get:
__asm__("%0 %1 ":"=r" i:);
Somehow we brought back a bug from 2.95.3 (weird isn't it).
--
http://gc
--- Comment #5 from amylaar at gcc dot gnu dot org 2005-11-09 20:56 ---
(In reply to comment #4)
> -da without -quiet generally produces code that is larger than any of the
> above
> scenarios, but sometimes it produces identical code to -quiet (without -da).
>
I have now captured fou
--- Comment #10 from aoliva at gcc dot gnu dot org 2005-11-09 20:57 ---
Subject: Bug 4372
Author: aoliva
Date: Wed Nov 9 20:57:30 2005
New Revision: 106704
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106704
Log:
gcc/ChangeLog:
PR other/4372
* gthr-dce.h, gthr-posix.h, gthr-p
--- Comment #11 from aoliva at gcc dot gnu dot org 2005-11-09 20:58 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from wilson at tuliptree dot org 2005-11-09 21:07 ---
Subject: Re: [3.4/4.0/4.1 regression] amd64
register spill error with -fschedule-insns
On Wed, 2005-11-09 at 07:27, uros at kss-loka dot si wrote:
> (BTW: I have added Jim Wilson to CC of this bug as he is cur
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-09 21:08 ---
This is not an ia64 specific issue as far as I can see, on x86_64, we get:
(note 64 61 62 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 62 64 63 2 (set (reg:DI 63)
(reg:DI 0 ax)) -1 (nil)
(nil))
(insn 63 62 53
1 - 100 of 200 matches
Mail list logo
