--- Comment #5 from malitzke at metronets dot com 2007-06-13 07:09 ---
All I want for gcc is that it meets both the letter __and__ the spirit of
applicable contracts and specifications.
First, the GPL is a contract, do __not__ take my word for it but consult a
lawyer.
Second, the C st
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-13 07:27 ---
(In reply to comment #2)
> I can't reduce that any more, it depends on the module files being huge: if
> you
> trim them down to a lower number of symbols, they ICE disapears. And I can't
> reproduced it either on x86
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-13 07:30 ---
The C extensions are disabled with --disable-decimal-float. I never said they
were not, in fact here is a quote from me:
Even if you disable dfp, libdecnumber is still needed to compile gcc as
disable-decimal-float
--- Comment #16 from rob1weld at aol dot com 2007-06-13 07:53 ---
I did some testing on the CVS of crlibm, (it needs a few files from
crlibm-1.0beta1.tar.gz).
The new docs list these interesting features:
portable to any system implementing the ISO-C99 and IEEE-754 standards,
co
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-06-13 08:02
---
(In reply to comment #3)
> Are there any equivalences in the the sources for the modules and do they have
> any data statements? Even if they do, I am not sure that I believe that the
> PR29786 patch is involved
--- Comment #11 from rob1weld at aol dot com 2007-06-13 08:06 ---
The configure script should check the headers against the library version.
Two people from "gcc.gnu.org" and I all got nailed by this. It may bite others
with less computer knowledge than ourselves.
The "bug" is this:
--- Comment #1 from dorit at il dot ibm dot com 2007-06-13 08:41 ---
Sorry about the breakage. Does it work for you if you change the testcase as
follows?:
Index: pr32224.c
===
--- pr32224.c (revision 125641)
+++ pr32224.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-13 08:50 ---
> Sorry about the breakage. Does it work for you if you change the testcase as
> follows?:
Yes it will fix it but note there is still a bug in the ia64 back-end anyways
so this bug should not be closed as being fix
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-13 09:01 ---
Dear All,
> > I think that you are probably right - it looks like my patch for PR29786 is
> > to
> > blame, since it is the only thing to touch trans-common.c for a long time.
This is incorrect - it goes back at lea
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-13 09:04 ---
PS - It also explains a failure by gfortran to produce a working version of the
PROTEUS tokamak equilibrium code. I just tried, for the first time, to compile
it with no optimization. It is SLOW but it goes. It
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-13 09:30 ---
The problem lies with the common block aux32, which is declared in subroutine
unpki with 6 integer(4) arrays at the beginning and, elsewhere, is declared
with default reals. Apparently, this makes a mess of the laying
--- Comment #12 from rob1weld at aol dot com 2007-06-13 09:32 ---
>> Comment #10 From Andrew Pinski 2007
>> This is not a bug.
>> Here is the deal, the reporter compiled GCC with the new headers but is using
>> the old library (which is known to be buggy).
> Comment #6 From Rob
> warnin
--- Comment #13 from rob1weld at aol dot com 2007-06-13 09:38 ---
Reopen bug reason: Request we add proposed fix to main configuration script.
--
rob1weld at aol dot com changed:
What|Removed |Added
-
--- Comment #52 from seb at frankengul dot org 2007-06-13 10:12 ---
(In reply to comment #51)
> I believe I'm seeing this bug using a redhat build: gcc4.1.1-1 (shows up all
> the way through -51). It's only on 64bit FC5, 32bit is okay and am installing
> FC6 to test. Building XULRunner w
When compiling with g++ -fprofile-arcs -ftest-coverage ... I got the following
segmentation fault:
/temp//TypeDictionary.C: In function (static destructors for
/temp//TypeDictionary.C):
/temp//TypeDictionary.C:315: internal compiler error: Segmentation fault
Taking a look at the file
--- Comment #17 from joseph at codesourcery dot com 2007-06-13 11:30
---
Subject: Re: Paranoia UCB GSL TestFloat libm tests fail
- accuracy of recent gcc math poor
I previously suggested to the crlibm authors that they consider assigning
it to the FSF for contribution to libgcc-math
--- Comment #3 from ubizjak at gmail dot com 2007-06-13 11:55 ---
(In reply to comment #2)
> > Sorry about the breakage. Does it work for you if you change the testcase
> > as follows?:
>
> Yes it will fix it but note there is still a bug in the ia64 back-end anyways
> so this bug shou
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-13 12:08
---
Can you provide a working patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
--- Comment #8 from pault at gcc dot gnu dot org 2007-06-13 12:26 ---
This fixes it but is, as yet unregtested. I'll do the business tonight and
will commit as 'obvious', if all is well.
Thanks, Dale!
Paul
Index: gcc/fortran/trans-common.c
--- Comment #5 from pranav dot bhandarkar at gmail dot com 2007-06-13
12:36 ---
Which RTL pass should take care of such induction variable optimization in 4.3
? For e.g In 4.1, It was old-loop that was doing it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 13:14 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-13 13:24 ---
Sorry if I was not clear before. This is the correct fix for the testcase but
not the bug itself. Users could accidently use the %q0 and then get the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32274
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-13
13:28 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> It's my turn to ask: so what information does hppa_can_use_return_p
> need to make the decision ?
We need to know that the return
--- Comment #7 from rask at sygehus dot dk 2007-06-13 13:36 ---
Looking at this again, I don't think the transformation I'm making with the
splitter is valid, because I'm making up a zero extension which wasn't there to
begin with. The upper part could have been non-zero before the instr
Even when an explicit interface is known, no warnings are generated when array
argument bounds (available to the compiler) don't match. Consider the
following:
module mod
implicit none
contains
subroutine a(n,v)
integer,intent(in)::n
real,dimension(n),intent(in)::v
write(*,*)v
end subroutine a
--- Comment #9 from dir at lanl dot gov 2007-06-13 13:39 ---
Your Welcome Paul,
With a little luck, the fix for this will cure the remaining problems that I
have been having with my programs when optimization is turned on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
--- Comment #1 from terry at chem dot gu dot se 2007-06-13 13:43 ---
(Whoops. Mixed up output in that last post. Only 8 reals are printed in
reality. My bad.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
--- Comment #2 from patrick dot pastoor at onespin-solutions dot com
2007-06-13 14:26 ---
I am really sorry. But I think there is no possiblity to upload a preprocessed
source here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32316
--- Comment #2 from ckirshen at gnupower dot net 2007-06-13 14:37 ---
This problem definitely exists on both hpux 11v2 and 11v3, even when passing in
--with-gnu-as and --with-as. I'm trying this on gcc-3.4.3 and gcc-3.4.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18388
--- Comment #10 from pault at gcc dot gnu dot org 2007-06-13 15:00 ---
I goofed - the previous does not fix it at all.
I hope that I am not too late to stop folk from building with this patch.
Cheers
Paul
PS Compiling the subroutines separately or padding out the first aux32 both fix
--- Comment #6 from jakub at gcc dot gnu dot org 2007-06-13 15:22 ---
I see that PR25505 caused a bunch of code generation regressions.
On i?86, with -O2 -m32:
_Complex double foo (_Complex double x)
{
return __builtin_cexp (x);
}
generated code got much worse, similarly:
elemental fun
The spec file explains that the picture "%c" stands for
locale's date and time (including the time zone).
However, the replacement picture doesn't include %z (which
isn't supported AFAICS.)
from the spec:
-- %c locale's date and time (Sat Nov 04 12:02:33 EST 1989)
from the body:
[EMAIL PROTECTED] cat run.f90
subroutine aa(v)
integer,dimension(:),intent(out)::v
write(*,*)size(v)
v=0
end subroutine aa
program ff
implicit none
integer,dimension(10)::w
w=1
write(*,*)w
call aa(w(1:5))
write(*,*)w
end
[EMAIL PROTECTED] gfortran -Wall -W -fbounds-check -O --std=f95 --pedantic
+++ This bug was initially created as a clone of Bug #27668 +++
The following invalid code snippet triggers an ICE since GCC 3.4.0:
==
template struct A {};
template void foo(A);
==
bug.cc:1: error:
>gcc-4.3 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-checking --prefix=/opt/gcc
--enable-shared --enable-threads --program-suffix=-4.3 --enable-__cxa_atexit
--disable-nls --with-mpfr=/usr/local
--enable-languages=c,c++,objc,obj-c++,treelang,fortran
In a template-context, pointers to overloaded methods are not correctly
resolved. the following main.cpp does not compile on gcc 4.1.2, however it does
compile on version 3.4.6:
#include
#include
#include
#include
namespace mi = boost::multi_index;
struct field_ts
{
int ts() const { return
--- Comment #1 from tsarkov at cs dot man dot ac dot uk 2007-06-13 15:42
---
Created an attachment (id=13697)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13697&action=view)
Preprocessed sources
Code that triggers ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-06-13 15:45 ---
Fixed:
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00615.html
by this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00842.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-06-13 15:57 ---
(In reply to comment #2)
> The generic implementation, including for SSE, is
> isgreater (abs(f), FLT_MAX)
> For isfinite, use islessequal instead. For isnan, one can use
> isunordered(f, f)
> For isnormal, it'd
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-13 15:57 ---
If you would provide an explicit interface for AA, the binary would not
segfault:
$> cat pr32319.f90
program ff
implicit none
integer,dimension(4)::w
w=1
write(*,*)w
call aa(w(2:3))
write(*,*)w
contains
--- Comment #2 from terry at chem dot gu dot se 2007-06-13 16:10 ---
Ah. Of course explicit interfaces are required for automatic array arguments.
My Fortran-Fu seems to be deserting me at the moment. :-(
--
terry at chem dot gu dot se changed:
What|Removed
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-13 16:17 ---
Neither SUN nor Intel fortran compilers issue such a warning.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||spark at gcc dot gnu dot org
Keywords|
--- Comment #3 from terry at chem dot gu dot se 2007-06-13 16:23 ---
(In reply to comment #2)
> Neither SUN nor Intel fortran compilers issue such a warning.
>
Indeed. That does not imply that gfortran shouldn't, though. Hence the
enhancement request.
--
http://gcc.gnu.org/bugzi
[EMAIL PROTECTED] cat run.f90
module mod
implicit none
contains
subroutine aa(v)
integer,dimension(:),intent(out)::v
write(*,*)size(v)
v=0
end subroutine aa
end module mod
program ff
use mod
implicit none
integer,dimension(10)::w
w=1
call aa(w((/3,2,1/)))
write(*,*)w
end
[EMAIL PROTECTED] gfortra
The result of the division of 18446744065119617024llu by the result of (1<<31)
is wrong on a 32bit platform.
Reproduce: gcc s.c && ./a.out
should have exit code 0 but doesn't.
Expected: gcc -DEXPECTED s.c && ./a.out
has exit code 0 as expected.
gcc -v
Reading specs from /usr/lib/gcc/i386-red
--- Comment #1 from gcc at axel-naumann dot de 2007-06-13 16:50 ---
Created an attachment (id=13699)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13699&action=view)
Test case as stated in the report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32324
--- Comment #7 from jconner at apple dot com 2007-06-13 17:09 ---
(In reply to comment #6)
> I see that PR25505 caused a bunch of code generation regressions.
> On i?86, with -O2 -m32:
> ...
When you say regressions, I assume you mean size/performance, not correctness,
right? If so, th
--- Comment #4 from appfault at hotmail dot com 2007-06-13 17:38 ---
Yes in addition to the issue of adding a test case, it is quite unsettling to
not know what might have fixed it. Reopening pending response to comment 2 and
comment 3.
--
appfault at hotmail dot com changed:
--- Comment #18 from kargl at gcc dot gnu dot org 2007-06-13 17:52 ---
> The libm library is the least accurate and on average the fastest; though not
> fastest for every function instance. The most accurate is always CRLibm,
> sometimes it is fastest. The MPFR library is second most acc
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-13 17:53 ---
Look at PR 17108 also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDep
--- Comment #5 from appfault at hotmail dot com 2007-06-13 17:56 ---
Ok well, I'll take your word on that, since I can't really tell where gcc and
ld end and glibc begins. It's perhaps glibc that is in need of better
documentation then. However if I file such a zilla I suspect it will
--- Comment #2 from andrew dot stubbs at st dot com 2007-06-13 18:00
---
As it happens, I encountered your real problem quite recently. :)
"(int)(1<<31)" is undefined (C99 standard 6.5.7/4).
This modified version gives the same result both ways:
int main (){
unsigned long long a =
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-13 18:03 ---
Thanks for finding this bug! I think it is the following in the Fortran 2003
standard:
"12.4.1.2 Actual arguments associated with dummy data objects"
"If a nonpointer dummy argument has INTENT (OUT) or INTENT (INOUT)
During a mainline bootstrap on alpha-dec-osf5.1b, the libstdc++ configure
failed:
checking for exception model to use... configure: error: unable to detect
exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
config.log reveals:
configure:13794: checking for exception model to u
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |target
This may be a duplicate of PR 28868
a.c
=
typedef struct a1 {
int x;
} a1_t __attribute__((may_alias));
=
a.c:3: internal compiler error: in splice_child_die, at dwarf2out.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 19:27 ---
> It does not occur targeting
I doubt those use dwarf2/3 :).
*** This bug has been marked as a duplicate of 29436 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-06-13 19:27
---
*** Bug 32326 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from patchapp at dberlin dot org 2007-06-13 19:30 ---
Subject: Bug number PR32323
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-06/msg00910.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #5 from daney at gcc dot gnu dot org 2007-06-13 19:44 ---
Unfortunatly the patch causes an ICE compiling crtstuff.c. I will have to
adjust it a bit...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
Given the following code:
--
typedef unsigned int size_t;
typedef unsigned long long uint64;
extern "C" {
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n) /*throw ()*/;
}
ex
--- Comment #6 from dje at gcc dot gnu dot org 2007-06-13 20:00 ---
>From IRC:
see.c:2732 makes a copy of an insn and then hacks on it with validate_change
(and it's close relatives). This copy has a basic_block, even though it is not
in the insn stream, as well as the same insn_uid as
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-13 20:12 ---
Subject: Bug 32323
Author: burnus
Date: Wed Jun 13 20:12:40 2007
New Revision: 125684
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125684
Log:
2007-06-13 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-13 20:14 ---
Fixed in 4.3.
As it is neither a regression nor a wrong-code bug, it will not be fixed for
4.2.1 or 4.1.3.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from ubizjak at gmail dot com 2007-06-13 20:20 ---
RFC patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00916.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
--- Comment #6 from daney at gcc dot gnu dot org 2007-06-13 20:39 ---
Created an attachment (id=13700)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13700&action=view)
Revised patch.
I don't know what I was thinking with the first version of the patch :-( The
new version I think
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-13 20:45
---
Hard to tell what is going wrong. I've been building and using compilers on
i386-darwin with no problem. Please contact the people behind HPC MacOS X to
see if they can help you using this compiler, or download ou
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-06-13 20:49
---
(In reply to comment #9)
> I don't see the point of these questions though. After all, I confirmed your
> bug with gcc 4.1, and also that it's fixed in 4.2 and 4.3. So the remaining
> question is whether this w
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27766
nThis||
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27766
nThis||
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
When the attached file is compiled with a mingw32 build of GCC 4.2.0 using the
-O2 option (gcc -O2 -c timestamp2.i), lines 159 and 160 are never executed when
running the program that uses this file. Since the hashitem function modifies
the variable b which is passed to it by-address, leaving those
--- Comment #1 from tdragon at tdragon dot net 2007-06-13 21:19 ---
Created an attachment (id=13701)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13701&action=view)
Preprocessed example source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 21:20 ---
Why is the store to dest not being removed?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from dougkwan at google dot com 2007-06-13 21:25 ---
The address of dest has been passed to memcpy() and the alias analysis
considers the varaible to escape. So potentially foo() can see the value of
dest if memcpy() stash the pointer somewhere. This is impossible but the
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-13 21:32 ---
No, it should be marked as non escaping later on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-13 21:37 ---
On the trunk, dest is changed to be non addressable in alias5, why is it not
doing it in 4.2?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-13 21:42 ---
(In reply to comment #2)
> The address of dest has been passed to memcpy() and the alias analysis
> considers the varaible to escape. So potentially foo() can see the value of
> dest if memcpy() stash the pointer som
--- Comment #6 from dougkwan at google dot com 2007-06-13 21:50 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
Fixing alias analysis in 4.2.0 will make this problem go away but it
does not change the underlying issue in the stack local sharing co
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-13 21:53 ---
(In reply to comment #6)
> Fixing alias analysis in 4.2.0 will make this problem go away but it
> does not change the underlying issue in the stack local sharing code.
Is that really true? The underlying issue is s
--- Comment #7 from echristo at apple dot com 2007-06-13 22:16 ---
Um. Right. :)
The new version is fine if it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-13 22:21 ---
Do you mean the last two stores to b:
b->time = time;
b->progress = found ? 4 : 2;
Though we could have an alias violation if you don't cast back in hashitem to
the correct type of the argument. This is still a b
--- Comment #3 from tdragon at tdragon dot net 2007-06-13 22:27 ---
(In reply to comment #2)
> Do you mean the last two stores to b:
> b->time = time;
> b->progress = found ? 4 : 2;
Yes, those two lines are the ones that are wrongly skipped.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #10 from geoffk at gcc dot gnu dot org 2007-06-13 22:31 ---
I think this problem is limited to just typeinfo.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tdragon at tdragon dot net 2007-06-13 22:36 ---
(In reply to comment #2)
> Though we could have an alias violation if you don't cast back in hashitem to
> the correct type of the argument.
hashitem() uses the type as punned to HASHDATA* (where HASHDATA is a struct
wit
--- Comment #5 from tdragon at tdragon dot net 2007-06-13 22:47 ---
Is it possible that an optimization enabled by -O2 *assumes* that hashitem()
will conform with strict aliasing by not dereferencing that argument, and thus
optimizes those lines away? (Not the case.) If this is what is h
--- Comment #15 from rob1weld at aol dot com 2007-06-13 23:39 ---
>Can you provide a working patch?
Soon. I am trying to fix the math inaccurcy in GCC 4.3.0 and merge a a new math
library. You can try sticking that oneliner into your configure if your in a
rush.
--
http://gcc.gnu.o
The bug report is about the use of the option "-fwhole-program".
When I compiled a program (crlibm-0.18beta1.tar.gz , described in bug report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180 ) I found that GCC 4.2.0 with
option "-O2" produced code that was _slightly_ faster than GCC 4.3.0 with
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 23:50 ---
Read the documentation, use `externally_visible' as the docs say to.
There is nothing here really except you did not read the docs at all, even
though you quoted them :).
--
pinskia at gcc dot gnu dot org change
--- Comment #8 from dougkwan at google dot com 2007-06-14 00:14 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
I thought like you do initially. But then I was told that in gimple
everything is promoted to function scope. So dest is not out of sco
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-14 00:28 ---
(In reply to comment #8)
> Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
> code
>
> I thought like you do initially. But then I was told that in gimple
> everything is promoted to fu
--- Comment #10 from dougkwan at google dot com 2007-06-14 00:35 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
Talked to Dan Berlin and Diego Novillo here at Google. They told me
that all locals are promoted to function scope.
In generally, the
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-14 00:42
---
Look at the code in cfgexpand.c, expand_used_vars, this looks at the source
blocks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-06-14 00:42
---
This code has been there since 4.0.0 so this has been true since then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
--- Comment #13 from dougkwan at google dot com 2007-06-14 00:46 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
Yes, I saw the code there yesterday and I was wondering if the block
scope got fixed up somehow.
14 Jun 2007 00:42:23 -, pinskia
--- Comment #14 from pinskia at gmail dot com 2007-06-14 00:52 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
On 14 Jun 2007 00:46:28 -, dougkwan at google dot com
<[EMAIL PROTECTED]> wrote:
> Yes, I saw the code there yesterday and I was won
--- Comment #15 from dougkwan at google dot com 2007-06-14 00:59 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
Then the stack local sharing code is very broken. It should do a real
live-range analysis instead of using block scoping information f
1 - 100 of 115 matches
Mail list logo
