--- Comment #15 from jhopper at safe-mail dot net 2009-07-30 06:37 ---
btw, these results also show something else of interest: pgo degrades
performance
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
--- Comment #14 from jhopper at safe-mail dot net 2009-07-30 05:09 ---
one more thing to mention about gcc, is the configurations during their
compilation: (although it may not have much sense as those things were never
really having an effect to the anticipated extent)
../gcc-4.a.b/con
--- Comment #13 from jhopper at safe-mail dot net 2009-07-30 04:39 ---
one last thing: and try not to take the LU DECOMPOSITION test seriously between
the various gcc testing runs, there was great difference even when using the
same executable several times, except of corse for the huge
--- Comment #12 from jhopper at safe-mail dot net 2009-07-30 04:34 ---
one more note about executable size in memory:
while there was no difference in sizes in memory for all gcc versions
for icc versions there was a great difference:
VERSION VIRTRSS
gcc (all) ~2000kb 500kb
ic
--- Comment #11 from jhopper at safe-mail dot net 2009-07-30 04:24 ---
forgot to mention executable sizes:
all tested gcc versions 4.2 4.3 and 4.4 were 100kb, intel executables were 68
and 72 kb respectively (version 10, 11).
executable size in memory (both VIRT and RSS) did not change
--- Comment #10 from jhopper at safe-mail dot net 2009-07-30 04:16 ---
abit more comprehensive gcc 4.2.4 vs 4.3.3 vs 4.4.0 vs 4.4.1 comparison using
nbench:
hardware: Intel celron 320 (prescott, SSE3, 256KB L2, socket 478) @ 2970 mhz
kernel: specially optimized by intel compiler 10 (lin
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-30 03:59 ---
Doesn't DLL source need to be compiled with -fPIC to allow it to work?
So what is happening is you are getting a runtime relocation inside the
.text.unlikely section which should not happen for DLLs I think ...
--
--- Comment #52 from danglin at gcc dot gnu dot org 2009-07-30 03:55
---
This ICE appears to have been fixed on the trunk by revision 149750:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00631.html
The change affected inlining (see PR 40908), so possibly the problem is
just latent.
--
--- Comment #2 from ramiro dot polla at gmail dot com 2009-07-30 03:43
---
I might be guessing wildly since I don't know that much about PE, but this is
what more I've found:
It crashes loading the dll in __pei386_runtime_relocator at address 65ec12a8:
65ec1290 <__pei386_runtime_reloca
--- Comment #9 from joel at gcc dot gnu dot org 2009-07-30 01:29 ---
(In reply to comment #8)
> Is comment #5 meant to be a claim that the patch does not fully fix the bug?
> If so, please state with what revision on what target the problem is still
> observed.
No. I reported this inde
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-07-29 23:08 ---
There is no indication in this bug report of whether the issue also
appears for 4.5. If it does, please update the regression marker to
"4.4/4.5 Regression".
--
jsm28 at gcc dot gnu dot org changed:
Wh
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.5.0
http://gcc.g
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.2
http://gcc.g
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.2
http://gcc.g
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.5.0
http://gcc.g
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.5.0
http://gcc.g
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40866
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40861
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-07-29 22:55 ---
Tru64 is not a primary or secondary target so setting to P4.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-07-29 22:54 ---
Solaris x86 is not a primary or secondary target so setting to P4.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40671
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-07-29 22:52 ---
Setting to P4, but restore to P3 if a C or C++ test for this bug is found.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from ppluzhnikov at google dot com 2009-07-29 22:51 ---
Confirm: r149235 fixes the problem here :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-07-29 22:51 ---
Setting to P4 on the basis that the described bug circumstances involve
a RUNTESTFLAGS setting to use a single .exp file, please restore to P3
if it appears without using any RUNTESTFLAGS setting.
--
jsm28 at gcc d
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-07-29 22:48 ---
As I understand it this is fixed by the patch shown (r149235),
please reopen if not.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jsm28 at gcc dot gnu dot org 2009-07-29 22:47 ---
Darwin not using (a non-ancient version of) the GNU assembler is sufficient
explanation for any assembler syntax issue appearing there but not on other
targets. Closing as fixed.
--
jsm28 at gcc dot gnu dot org ch
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
--- Comment #8 from jsm28 at gcc dot gnu dot org 2009-07-29 22:37 ---
Is comment #5 meant to be a claim that the patch does not fully fix the bug?
If so, please state with what revision on what target the problem is still
observed.
In any case, the targets mentioned are not primary or s
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-07-29 22:33 ---
x86_64-pc-mingw32 is not a primary or secondary platform, moving to P4.
Please restore to P3 if this also appears on i686-mingw32 or another
primary or secondary platform.
--
jsm28 at gcc dot gnu dot org changed:
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--- Comment #2 from bennett dot schneider at yahoo dot com 2009-07-29
22:11 ---
I've seen the same behaviour and was able to fix two separate issues. First,
the @ symbol on the leaq instruction is not necessary. This code is being
inserted because NO_PROFILE_COUNTERS is not defined (
--- Comment #54 from jason at gcc dot gnu dot org 2009-07-29 21:09 ---
Thanks for the testcase, the patch I just checked in should fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
--- Comment #4 from jonathan dot sd24 at yahoo dot de 2009-07-29 21:05
---
Template-Parameters can be results of long calculations or typedefs with
several layers of indirection.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
--- Comment #9 from paolo dot carlini at oracle dot com 2009-07-29 21:02
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #8 from paolo at gcc dot gnu dot org 2009-07-29 21:00 ---
Subject: Bug 40908
Author: paolo
Date: Wed Jul 29 21:00:10 2009
New Revision: 150228
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150228
Log:
2009-07-29 Paolo Carlini
PR libstdc++/40908
*
--- Comment #53 from jason at gcc dot gnu dot org 2009-07-29 20:36 ---
Subject: Bug 14912
Author: jason
Date: Wed Jul 29 20:35:40 2009
New Revision: 150223
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150223
Log:
PR c++/14912
* cp-tree.h (enum tsubst_flags): Ad
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-07-29 20:16
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-07-29 20:16
---
Subject: Bug 40834
Author: rguenth
Date: Wed Jul 29 20:16:32 2009
New Revision: 150222
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150222
Log:
2009-07-29 Richard Guenther
PR c++/40834
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
20:13 ---
Subject: Re: FAIL: abi_check
> Try something like this:
Works for me.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40908
--- Comment #6 from paolo dot carlini at oracle dot com 2009-07-29 19:46
---
Try something like this:
Index: config/abi/pre/gnu.ver
===
--- config/abi/pre/gnu.ver (revision 150220)
+++ config/abi/pre/gnu.ver (wor
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-29 19:42
---
Yes, that is not supposed to be exported. Indeed, it isn't, on x86_64, for
example. For some reason, a 3_4 linker script pattern matches it, probably
matches std::m* things...
--
http://gcc.gnu.org/bugzill
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
19:31 ---
Subject: Re: FAIL: abi_check
> By "a function", I meant of course _ZNSt5mutexC1Evstd::mutex::mutex(). In the
> meanwhile I checked that indeed that symbol normally is *not* exported at all.
I see a weak d
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-29 19:20 ---
Ah, it's because I don't push to lto_global_var_decls. We can at
write-global-declarations time walk over all global vars and exchange the
written decl for
the largest in the chain.
--
http://gcc.gnu.org/bugzil
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
18:27 ---
Subject: Re: FAIL: abi_check
> If I'm not wrong, please double check, nothing happened in the library proper
> between those versions, thus it looks like by chance a function is not inlined
> anymore and n
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-29 18:15 ---
patches should be sent to gcc-patches with a proper changelog entry and a note
on how you tested the patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from rguenther at suse dot de 2009-07-29 18:18 ---
Subject: Re: LTO doesn't merge common sections properly
On Wed, 29 Jul 2009, rth at gcc dot gnu dot org wrote:
> --- Comment #4 from rth at gcc dot gnu dot org 2009-07-29 18:10 ---
> So LTO still produces N out
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-29 18:12 ---
long lo_b_2268X;
long lo_a_2267X;
long lo_c_2271X;
...
lo_a_2267X = 65535 & a_1962X;
lo_b_2268X = 65535 & b_2266X;
...
lo_c_2271X = ((lo_a_2267X) * (lo_b_2268X));
...
if ((536870911 < lo_c_2271X)) {
...
--- Comment #4 from rth at gcc dot gnu dot org 2009-07-29 18:10 ---
So LTO still produces N output object files for N input files?
Cause you can't just output
.comm i,4,4
.comm i,8,8
in one object file, and I didn't see any changes to varasm.c...
--
http://gcc.gnu.org/bugzill
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-29 18:07
---
By "a function", I meant of course _ZNSt5mutexC1Evstd::mutex::mutex(). In the
meanwhile I checked that indeed that symbol normally is *not* exported at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-29 18:03
---
If I'm not wrong, please double check, nothing happened in the library proper
between those versions, thus it looks like by chance a function is not inlined
anymore and now is matched by old loose bits of the l
--- Comment #3 from rguenther at suse dot de 2009-07-29 18:01 ---
Subject: Re: LTO doesn't merge common sections properly
On Wed, 29 Jul 2009, rth at gcc dot gnu dot org wrote:
> --- Comment #2 from rth at gcc dot gnu dot org 2009-07-29 17:55 ---
> I believe a "proper" way to
--- Comment #2 from rth at gcc dot gnu dot org 2009-07-29 17:55 ---
I believe a "proper" way to handle this, preserving the semantics that
the linker provides, is to transform this into
union {
double _1;
int _2;
} i;
and replace occurrences with i._1, i._2, etc.
Perhaps a more in
1 incompatible symbols
0
_ZNSt5mutexC1Evstd::mutex::mutex()
version status: incompatible
GLIBCXX_3.4
type: functionstatus: added
=== libstdc++-v3 check-abi Summary ===
# of added symbols: 119
# of missing symbols:0
# of incompatible symbols: 1
usin
--- Comment #4 from sperber at deinprogramm dot de 2009-07-29 17:42 ---
(From update of attachment 18271)
In the preprocessed file, the test that gets elided is in line 20307.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40907
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-29 17:41 ---
>an overflow check in the internal arithmetic gets elided.
Does -Wno-strict-overflow fix the issue? Does -fwrapv fix the issue?
If so you are depending on overflow being defined as wrapping and the code is
undefin
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-29 17:40 ---
../s48/c/scheme48vm-32.c: In function 'current_code_vector':
../s48/c/scheme48vm-32.c:1426:8: warning: 'v_231X' may be used uninitialized in
this function
../s48/c/scheme48vm-32.c: In function 'HtopD12136':
../s48/c/
--- Comment #1 from sperber at deinprogramm dot de 2009-07-29 17:37 ---
Created an attachment (id=18271)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18271&action=view)
preprocessed source file
gcc -v output:
kramer[420] gcc -v -save-temps -c -DHAVE_CONFIG_H
-D__COMPILING_SCHEM
When compiling Scheme 48 with -O2, an overflow check in the internal arithmetic
gets elided. This bug showed up sometime after gcc 4.0.1. It's in 4.4.1, and
in the 4.5-20090723 snapshot. It's been seen on 32-bit Linux and 32-bit
FreeBSD.
The code snippet in question in c/scheme48vm-32.c is this:
--- Comment #7 from danglin at gcc dot gnu dot org 2009-07-29 17:09 ---
In the 'ch' pass, we have:
:
a.85 = a;
SR.155_25 = b._M_value;
...
This gets transformed in the 'cplxlower' pass to
:
a.85 = a;
SR.155$real_7 = REALPART_EXPR ;
SR.155$imag_1 = IMAGPART_EXPR ;
However,
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-29 17:07 ---
Created an attachment (id=18270)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18270&action=view)
A patch for the bug
A patch for the problem.
1. reverse the direction of "change_address
Hi. Try this program:
#include
void f(long double a)
{
if (a != 1.0) abort();
}
int g(long double b)
{
f(b);
return 0;
}
int main(void)
{
g(1.0);
return 0;
}
Compile it with "-O2 -mpush-args -mno-accumulate-outgoing-args
-fomit-frame-pointer -fno-inline
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-29 16:10 ---
IIRC the cold attribute does a couple of things. The only thing I think that
might cause this is putting it into a .text.cold section.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
GCC creates invalid executable when an array from one DLL is accessed from
another DLL in a function with __attribute__((cold)).
--
$ cat dll1.c
int foo[2] = {0, 1};
$ cat dll2.c
extern int foo[2];
__attribute__((cold))
int bar(void)
{
return foo[1];
}
$ cat main.c
int bar(void);
int
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
16:02 ---
Subject: Re: [4.5 Regression] FAIL:
g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and
above
Attached tree dump.
Dave
--- Comment #6 from dave at hiauly1 dot hia dot
--- Comment #1 from kretz at kde dot org 2009-07-29 14:51 ---
I just tested with 4.4.1 and I can still confirm the problem.
--
kretz at kde dot org changed:
What|Removed |Added
---
--- Comment #7 from burnus at gcc dot gnu dot org 2009-07-29 14:47 ---
FIXED on the trunk (4.5) - does not affect any branch.
(In reply to comment #5)
> The patch seems to work:
It caused a regression when I tried to regtest it as I missed another
(follow-up) place, cf. http://gcc.gnu.
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-29 14:45 ---
Subject: Bug 40898
Author: burnus
Date: Wed Jul 29 14:44:51 2009
New Revision: 150216
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150216
Log:
2009-07-29 Tobias Burnus
PR fortran/40898
*
--- Comment #6 from matz at gcc dot gnu dot org 2009-07-29 14:43 ---
Marvelous, ia64 doesn't support alignment compensation. So, xfailing the
test on such targets seems the right way. Fixed again.
--
matz at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from matz at gcc dot gnu dot org 2009-07-29 14:42 ---
Subject: Bug 40830
Author: matz
Date: Wed Jul 29 14:41:38 2009
New Revision: 150215
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150215
Log:
PR middle-end/40830
* gcc.dg/vect/vect-pre-interact.c: XFAIL for no
http://gcc.gnu.org/onlinedocs/gfortran/COUNT.html
"COUNT(MASK [, DIM [, KIND]]) counts the number of .TRUE. elements of MASK
along the dimension of DIM. If DIM is omitted it is taken to be 1. DIM is a
scalar of type INTEGER in the range of 1 /leq DIM /leq n) where n is the rank
of MASK."
The desc
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-07-29 13:40
---
(In reply to comment #8)
> That only detects direct loops, does it?
Actually, now I may understand but no, it is exactly the other way
round. The patch above only detects indirect loops, when there are at
le
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-29 13:39 ---
I'm working on this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assign
t1.c
double i;
t2.c
int i;
int main () { return i; }
should be accepted with -fcommon.
What needs to be done is that we have to keep a list of decls per symtab
entry that we might end up merging to and we need to return the proper
decl when looking up the canonical decl.
A warning is still appr
>From 464.h264ref we can see that for
t1.c
const int i[10] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
t2.c
extern int i[10];
int main () { return i[0]; }
we should merge both decls, retaining the const qualification (the middle-end
considers both types compatible, lto_symtab_compatible doesn't).
--
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
13:08 ---
Subject: Re: [4.5 Regression] FAIL:
g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and
above
> Can you please try this with -fno-tree-sra? If you have a revision
> earlier
--- Comment #4 from jb at gcc dot gnu dot org 2009-07-29 12:46 ---
(In reply to comment #3)
> Is there a particular reason why we can not change this to off_t with 4.5.?
>
Yes, it would break the ABI. As it's such a minor issue, IMHO it can be
postponed until we need to break the ABI f
--- Comment #1 from dodji at gcc dot gnu dot org 2009-07-29 12:40 ---
Subject: Re: New: enum constants don't appear in debug_pubnames
Le 10/04/2009 01:42, tromey at gcc dot gnu dot org a écrit :
> enum constants don't appear in .debug_pubnames.
> It seems like perhaps they should, bec
--- Comment #6 from davek at gcc dot gnu dot org 2009-07-29 12:08 ---
Fixed on gcc-4_3-branch.
Not present on gcc-4_4-branch, fix was applied to HEAD before branching.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from davek at gcc dot gnu dot org 2009-07-29 11:45 ---
Subject: Bug 38903
Author: davek
Date: Wed Jul 29 11:45:30 2009
New Revision: 150209
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150209
Log:
PR bootstrap/38903: Backport fix from HEAD.
* con
--- Comment #2 from janus at gcc dot gnu dot org 2009-07-29 11:41 ---
(In reply to comment #1)
> In a similar vain: One could introduct an option to disable warning for the
> deleted features
Good point. In particular these are:
(1) Real and double precision DO variables.
(2) Branchi
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-29 11:01
---
looks similar to bug 40843 but I'm not sure if it's the same
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40901
--- Comment #14 from rguenther at suse dot de 2009-07-29 10:57 ---
Subject: Re: Function object abstraction penalty
with inline functions.
On Wed, 29 Jul 2009, jamborm at gcc dot gnu dot org wrote:
> --- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-29 10:16
> ---
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-07-29 10:33
---
Bootstrap and testing finished fine, I submitted the patch:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01642.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-29 10:33 ---
I don't think this is a backend specific problem but more an rtl-optimization
problem where combine with its sign extension detection machinery should be
extended to detect such cases.
--
ramana at gcc dot gnu do
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-07-29 10:28
---
The patch seems to work:
$ cat a.f90
subroutine foo
use ISO_C_BINDING
implicit none
interface
function LoadLibrary(lpFileName) bind(C,name='LoadLibraryA')
use ISO_C_BINDING
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-29 10:20 ---
FX: As you seemingly have a working cross compiler: Can you check the patch
below?
(One does not need to consider the return value as gfc_return_by_reference
deals with that. Only the last change is relevant, the oth
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-29 10:16
---
(In reply to comment #12)
> ... at least scheduling FRE is still on the list of possible things
> todo (can you check if that fixes 3713 as well?)
>
No, it doesn't (unlike the testcase above, for which FRE is eno
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-07-29 09:51 ---
(In reply to comment #8)
> > --- Comment #7 from jamborm at gcc dot gnu dot org 2009-07-28 20:59
> > ---
> > So, I belive the patch below fixes this issue and I am going to
> > bootstrap it overnight. Hon
Consider the following code fragment:
BEGIN CODE ==
#include
using namespace std;
class A {
private: //protected:
template
struct s {
enum {value = y };
};
public:
A() {}
};
int main() {
A();
cout << A::s<10>::value << endl;
return 0;
}
END CODE ==
Both
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-29 09:35 ---
Subject: Bug 40851
Author: burnus
Date: Wed Jul 29 09:35:15 2009
New Revision: 150203
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150203
Log:
2009-07-29 Tobias Burnus
PR fortran/40851
*
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-29 09:33 ---
You don't see it on ARM for this case because of tail-calling. But for Thumb or
without sibcall optimizations you do see this problem.
--
ramana at gcc dot gnu dot org changed:
What|Removed
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org
|dot org
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-07-29 09:27 ---
Can you please try this with -fno-tree-sra? If you have a revision
earlier than 147980 (new SRA) at hand, can you try that with
-fno-tree-sra? Thanks.
I'll try to reproduce this on gcc61 at the compile farm but it
--- Comment #4 from davek at gcc dot gnu dot org 2009-07-29 09:23 ---
Reopening against 4.3.4 RC 20090727.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from carrot at google dot com 2009-07-29 08:57 ---
Created an attachment (id=18266)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18266&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40900
Compile the following code with options -Os -mthumb -march=armv5te
extern short shortv2();
short shortv1()
{
return shortv2();
}
Gcc generates
push{r3, lr}
bl shortv2
lsl r0, r0, #16// A
asr r0, r0, #16// B
pop {r3, pc}
The
--- Comment #11 from ro at techfak dot uni-bielefeld dot de 2009-07-29
08:20 ---
Subject: Re: [4.4/4.5 Regression] tools.zip doesn't build on systems with
short command lines
htl10 at users dot sourceforge dot net writes:
> I have a slightly different message on alphaev68-dec-osf5.1a
1 - 100 of 110 matches
Mail list logo
