--- Comment #8 from rus at google dot com 2010-03-21 04:52 ---
Good point. I don't think that setenv should be there in the first place
actually. I'll try to fix that as well.
Just FYI, I'm planning to fix all the reported libstdc++ profile issues around
second week of April.
--
h
--- Comment #6 from siarhei dot siamashka at gmail dot com 2010-03-21
03:56 ---
(In reply to comment #4)
> IMO the reasons as described in my email is another motivation for Neon
> programmers to be using intrinsics rather than inline assembler and to improve
> in general Neon intrinsi
Comparing the Polyhedron 2005 benchmarks from current gcc 4.4 branch (r157587)
with those of gcc trunk (r157600) on x86_64-apple-darwin10 shows significant
regressions in the compile time compared to the previous release. The results
for gcc 4.4 branch are...
==
--- Comment #5 from siarhei dot siamashka at gmail dot com 2010-03-21
03:33 ---
I don't quite understand what's the problem: "This patch has the unhappy side
effect of clobbering s0, s1 and s2 if s3 is used because that's the only way we
can indicate that q0 is clobbered by the write to
--- Comment #1 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-21 03:28
---
This is output from:
gcc -mcpu=cortex-m3 -mthumb -O3 -S a.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43462
code:
extern int a;
void b();
main()
{
switch (a & 7) {
case 0: b(); break;
case 1: b(); break;
case 2: b(); break;
case 3: b(); break;
case 4: b(); break;
case 5: b(); break;
case 6: b(); break;
case 7: b(); break;
}
--- Comment #1 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-21 02:45
---
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/src/gcc-armtest/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/src/gcc-armtest/libexec/gcc/arm-none-eabi/4.5.0/lto-wrapper
Target: arm-none-eabi
Configured with
Truncation of unsigned to byte is not translated to uxtb insn, but truncation
to short is translated to uxth.
invocation:
gcc -mcpu=cortex-m3 -mthumb -O3 -S a.c
code (a.c):
unsigned a();
extern unsigned b;
main()
{
b = a() & 0xFF;
b = (unsigned char)a();
b = a() & 0x
--- Comment #1 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-21 02:24
---
In case it's relevant, the version from sources not combined with newlib (0.18)
crashed in same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43460
$ LANG=C /usr/src/gcc-armtest/bin/arm-none-eabi-gcc -c a.c
a.c: In function 'main':
a.c:7:1: internal compiler error: Segmentation fault
[...]
$ cat a.c
main()
{
asm goto("" test);
__builtin_unreachable();
test:
;
}
It's the same with valid jump inside asm goto().
$ gcc -v
Usi
Simple testcase:
--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
#include
#include
int testfunc(void)
{
int ret;
while (1) {
const unsigned int MY_BUF_SIZE = 20;
char buf[MY_BUF_SIZE];
if (read(0, buf, sizeof(buf)) < 0) {
ret = errno;
go
--- Comment #7 from paolo dot carlini at oracle dot com 2010-03-21 01:59
---
Silvius, when you will go through the various roblems on non-linux systems for
this test, also remember that setenv, as used in profiler_trace.h for example,
isn't always available, must be wrapped in #ifdef _G
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-21 01:50
---
This is expected, given our implementation and the current status vs C99
macros. For now just tweak the dg- lines, include hppa*-*-hpux*. At some point
we'll want to clean-up the whole thing.
--
http://gcc
--- Comment #6 from paolo dot carlini at oracle dot com 2010-03-21 01:44
---
*** Bug 43457 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-21 01:44
---
*** This bug has been marked as a duplicate of 43259 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++
-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/o
pt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/g
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++
-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/o
pt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/g
--- Comment #3 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-21 01:08
---
In case you're still interested, there is 'asm goto' coming in gcc 4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40078
--- Comment #9 from davek at gcc dot gnu dot org 2010-03-21 00:04 ---
No activity since the start of the year, no response to request for information
in a month. Probably was just a glitch; suspending in the absence of any
further information.
--
davek at gcc dot gnu dot org changed
--- Comment #11 from joseph at codesourcery dot com 2010-03-20 23:46
---
Subject: Re: gcc -O code generation error
I advise referring to
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1252.htm
which is what has been integrated in C1X.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-03-20 23:19
---
Oh yes the partial vs full order issue.
There is a nice paper about this:
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n926.htm
12.3 is the part which I think explains it all.
--
http://gcc.gnu.org/bugzilla
--- Comment #9 from gccbug at dworkin dot nl 2010-03-20 23:14 ---
Subject: Re: gcc -O code generation error
> No, we have a | b. There is an order inside a and b but no order between a
> and
> b.
That's depressing. C99 says in 5.1.2.3:
Evaluation of an expression may produce
--- Comment #26 from mikpe at it dot uu dot se 2010-03-20 22:36 ---
Created an attachment (id=20147)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20147&action=view)
test program to take a stack trace using _Unwind_ API
I'm attaching a test program which sets up a predictable call
--- Comment #2 from marbacz at gmail dot com 2010-03-20 22:25 ---
Passing -m32 make the hang disappear.
Below is slightly less reduced version of previous test case. It comes from gnu
bc.
It causes ICE. Uncommenting declarations changes ICE into hang. ICE doesn't go
away with -m32.
gc
--- Comment #25 from mikpe at it dot uu dot se 2010-03-20 22:10 ---
(In reply to comment #24)
> This rings a bell and the comment in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206#c8
> is probably related.
I don't think this is at all the same as PR29206. PR29206 is very old now,
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-20 21:54 ---
(In reply to comment #7)
> Subject: Re: gcc -O code generation error
>
> To clarify even further, we have
>
> (..., (f->sp++)->u.number [SEQUENCE POINT] ? 1 : 0) |
> (..., (f->sp++)->u.number [SEQUENCE POINT] ? 4
--- Comment #7 from gccbug at dworkin dot nl 2010-03-20 21:51 ---
Subject: Re: gcc -O code generation error
To clarify even further, we have
(..., (f->sp++)->u.number [SEQUENCE POINT] ? 1 : 0) |
(..., (f->sp++)->u.number [SEQUENCE POINT] ? 4 : 0)
So the modifications of f->sp are bef
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-20 21:18 ---
Just to clarify we have:
((i_push_value(f, (f->fp - 1)),
(--f->sp)->type = 0x01, f->sp->u.number = ((Int) 0x1L), i_index(f),
(--f->sp)->type = 0x01, f->sp->u.number = ((Int) 0x8L), kf_and(f),
(f->sp++)->u.number) ?
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-20 21:16 ---
I cannot follow the () correctly. There is no sequence point here because it
is a | separating the modifications of f->sp. So this is not a bug in GCC but
a bug in your code.
--
pinskia at gcc dot gnu dot org c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-20 21:01 ---
Seems to be the simple-minded CSE that gimplification performs, of f->sp.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-20 20:59 ---
>There's a sequence point after evaluating the first operand.
With -W -Wall, I get:
t.c:79:58: warning: operation on âf->spâ may be undefined
Looks like that is the issue.
So there might be still an missing seq
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-20 20:53 ---
(In reply to comment #1)
> (f->sp++)->u.number) ? ((Int) 0x1L) : ((Int) 0x0L)) | (((--f->sp)->type =
> 0x01,
> f->sp->u.number = ivar10,
> (f->argp + 3)->u.number = ivar3,
> i_funcall(f, (object *) ((void *)0), (arr
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-20 20:40 ---
(f->sp++)->u.number) ? ((Int) 0x1L) : ((Int) 0x0L)) | (((--f->sp)->type = 0x01,
f->sp->u.number = ivar10,
(f->argp + 3)->u.number = ivar3,
i_funcall(f, (object *) ((void *)0), (array *) ((void *)0), 0, 5 , 1),
(f->sp
--- Comment #9 from davek at gcc dot gnu dot org 2010-03-20 20:33 ---
Right you are. I'll just have to hope it gets approved quickly while those
remaining P1s gradually tick away... :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
gcc configuration:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-3ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --en
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-20 20:21 ---
Java is not release critical. If it doesn't make 4.5.0 it can easily make
4.5.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-03-20 20:19
---
See fortran-exp branch where we are working these issues. Once the splay-tree
structure is in place we can then focus on setting a limit and not "simplify"
the constructor.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-20 20:15 ---
Works for me on i?86-linux.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from davek at gcc dot gnu dot org 2010-03-20 20:02 ---
Raising priority P4 -> P3 and Cc'ing RM.
I didn't want to ask to block the release for a bug in a long-neglected
language on a secondary target before I was sure I'd be able to come up with a
fix in time, but now that
--- Comment #25 from davek at gcc dot gnu dot org 2010-03-20 19:46 ---
This was fixed on 2009-11-30 by r.154853, which enabled libstdc++ as a DLL on
windows platforms.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from ramana at gcc dot gnu dot org 2010-03-20 19:33 ---
As per the last comment.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ramana at gcc dot gnu dot org 2010-03-20 19:32 ---
Now Fixed . Yay.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-opt
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|--- |4.3.5
htt
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-opt
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-opt
--- Comment #6 from laurent at guerby dot net 2010-03-20 19:26 ---
I haven't built 4.3 in a while, if this is fixed in 4.4 and 4.5 it's good
enough for me so feel free to close as WONTFIX for 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38696
--- Comment #4 from ramana at gcc dot gnu dot org 2010-03-20 19:22 ---
Ah - hang on a minute . What binutils are you building with ? Can you try with
a more recent binutils ?
cheers
Ramana
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39244
--- Comment #5 from ramana at gcc dot gnu dot org 2010-03-20 19:16 ---
Laurent,
Is this still a problem on 4.3 branch ?
Ramana
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38696
gcc -O2 -flto 1.c 2.c hangs.
-O1 or without -flto compiles and links just fine.
1.c:
struct bar {int x;};
extern struct bar foo(void);
int main()
{
struct bar x=foo();
return 0;
}
2.c:
typedef struct{int x;} bar;
bar foo (void)
{
bar x;
return x;
}
gcc -v:
Using b
--- Comment #3 from ramana at gcc dot gnu dot org 2010-03-20 19:02 ---
(In reply to comment #2)
> Could this be a problem with boehm-gc ?
>
It's hard to say if this is a problem with Boehm GC or not . The OP hasn't
given any more information and nor has he given a testcase to look at .
--- Comment #24 from ramana at gcc dot gnu dot org 2010-03-20 18:54 ---
This rings a bell and the comment in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206#c8
is probably related.
If so, this is essentially a dup of PR29206 and I'm not sure what more we can
do with this.
cheers
R
--- Comment #7 from hjl dot tools at gmail dot com 2010-03-20 18:09 ---
An updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00937.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
--- Comment #6 from simartin at gcc dot gnu dot org 2010-03-20 18:04
---
Fixed in 4.5 (I've merged the two test cases into one, and have improved it
with parts from Michael's)
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-20 18:01 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00936.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
--- Comment #5 from simartin at gcc dot gnu dot org 2010-03-20 18:01
---
Subject: Bug 43081
Author: simartin
Date: Sat Mar 20 18:01:18 2010
New Revision: 157597
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157597
Log:
gcc/cp/
2010-03-20 Simon Martin
PR c++/43081:
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-20 17:46 ---
Subject: Bug 43156
Author: pinskia
Date: Sat Mar 20 17:45:37 2010
New Revision: 157596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157596
Log:
2010-03-20 Andrew Pinski
PR target/43156
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-20 17:45 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-03-20 17:34
---
Closing, this was fixed some time ago.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-20 17:00 ---
But Simons patch was accepted. Simon: can you simply combine the two
testcases into one? No need to artificially lengthen the time for make check.
--
matz at gcc dot gnu dot org changed:
What|Remov
--- Comment #3 from pault at gcc dot gnu dot org 2010-03-20 16:02 ---
Fixed on trunk
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-20 16:01 ---
Subject: Bug 43450
Author: pault
Date: Sat Mar 20 16:01:17 2010
New Revision: 157595
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157595
Log:
2010-03-20 Paul Thomas
PR fortran/43450
* tra
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-20 15:33 ---
That hoisting/sinking is usually marked with that BLOCK from which it has been
sunk or hoisted. And even if not, no debug info consumer I'm aware of will
tell you anything about the variables that are not in the scope
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-20 15:20 ---
Well. I'll just implement that given the silence.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #55 from rguenth at gcc dot gnu dot org 2010-03-20 15:12
---
(In reply to comment #54)
> (In reply to comment #53)
> > > optimize_function_for_size_p (cfun) is true if attribute(cold) is set
> > > on it or we are optimizing for size.
> >
> > It is what is presently implemen
--- Comment #54 from rguenth at gcc dot gnu dot org 2010-03-20 14:59
---
(In reply to comment #53)
> > optimize_function_for_size_p (cfun) is true if attribute(cold) is set
> > on it or we are optimizing for size.
>
> It is what is presently implemented. As a consequence (illustrated b
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-opt
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-03-20 14:42
---
Subject: Bug 43409
Author: jvdelisle
Date: Sat Mar 20 14:42:04 2010
New Revision: 157594
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157594
Log:
2010-03-20 Jerry DeLisle
PR fortran/43409
--- Comment #53 from dominiq at lps dot ens dot fr 2010-03-20 14:40 ---
> optimize_function_for_size_p (cfun) is true if attribute(cold) is set
> on it or we are optimizing for size.
It is what is presently implemented. As a consequence (illustrated by this pr),
optimize for speed is no
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-03-20 14:39
---
Subject: Bug 43409
Author: jvdelisle
Date: Sat Mar 20 14:39:00 2010
New Revision: 157593
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157593
Log:
2010-03-20 Jerry DeLisle
PR fortran/43409
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-20 14:34 ---
I saw
_CRTIMP unsigned int __cdecl __MINGW_NOTHROW _rotl(unsigned int, int)
__MINGW_ATTRIB_CONST;
_CRTIMP unsigned int __cdecl __MINGW_NOTHROW _rotr(unsigned int, int)
__MINGW_ATTRIB_CONST;
_CRTIMP unsigned long __c
--- Comment #52 from rguenther at suse dot de 2010-03-20 14:19 ---
Subject: Re: [4.4/4.5 Regression] Weird interaction
between optimize_insn_for_speed_p and -funsafe-math-optimizations
On Sat, 20 Mar 2010, dominiq at lps dot ens dot fr wrote:
> --- Comment #51 from dominiq at lps
--- Comment #1 from pault at gcc dot gnu dot org 2010-03-20 14:06 ---
Created an attachment (id=20146)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20146&action=view)
A fix for the PR
This bootstraps and regtests on FC9/x86_64
Paul
--
pault at gcc dot gnu dot org changed:
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-20 14:04 ---
But we can end up hoisting/sinking scalar code outside of the lexical block
of variable uses. I think a better approach would be to limit the locations
to regions that overlap lexical block + life range.
--
htt
--- Comment #7 from siarhei dot siamashka at gmail dot com 2010-03-20
13:58 ---
Resolved, as now it WORKSFORME.
--
siarhei dot siamashka at gmail dot com changed:
What|Removed |Added
--- Comment #6 from siarhei dot siamashka at gmail dot com 2010-03-20
13:55 ---
The crash disappeared when recompiling libXft-2.1.13 library with gcc 4.4.3.
Either it was fixed, or something else changed and it is not getting triggered
anymore. I guess this bug can be closed.
--
ht
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-20 13:44 ---
Fixed for 4.5 sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-20 13:44 ---
Subject: Bug 43438
Author: rguenth
Date: Sat Mar 20 13:44:18 2010
New Revision: 157592
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157592
Log:
2010-03-20 Richard Guenther
PR rtl-optimization/4
--- Comment #1 from bruno at clisp dot org 2010-03-20 13:39 ---
Created an attachment (id=20145)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20145&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43454
The attached program gives a warning about 'check_moo' being unused,
despite the variable being declared with __attribute__ ((__unused__)).
= bug.cc ==
extern "C" int c_foo (void);
namespace gnulib { static int (*foo) (void) = ::c_foo
--- Comment #51 from dominiq at lps dot ens dot fr 2010-03-20 13:21 ---
The following patch fixes this pr:
--- ../_clean/gcc/predict.c 2009-11-25 18:20:33.0 +0100
+++ gcc/predict.c 2010-03-20 14:03:33.0 +0100
@@ -251,7 +251,7 @@ optimize_edge_for_speed_p (edge
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #2 from steven at gcc dot gnu dot org 2010-03-20 13:02 ---
Waiting for OP to try suggestion of comment #1.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #50 from dominiq at lps dot ens dot fr 2010-03-20 13:02 ---
> optimize_insn_for_speed_p is more precise in that it allows hot functions
> to be optimized for speed even with -Os. This is quite important for
> embedded targets where you generally want to optimize for size but
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #8 from steven at gcc dot gnu dot org 2010-03-20 12:59 ---
Carrot, re. your comment #7: Time for that thoroughly testing.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2010-03-20 12:58 ---
Shouldeth be fixedeth by aforementionedeth patcheth (comment #7). Yay!
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-20
12:47 ---
Just to verify, I rebuilt gcc in a gcc+newlib combined tree and indeed it
builds correctly.
Configure line:
../gcc-combined/configure --with-newlib --prefix=/usr/src/gcc-armtest --target
arm-none-eabi --ena
--- Comment #4 from ramana at gcc dot gnu dot org 2010-03-20 12:42 ---
Patch submitted here for comments.
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00925.html
IMO the reasons as described in my email is another motivation for Neon
programmers to be using intrinsics rather than inli
--- Comment #3 from batuzovk at ispras dot ru 2010-03-20 12:35 ---
(In reply to comment #2)
> Does that look any better to you ?
Yes, definitely better. Thank you for quick response.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440
--- Comment #6 from pault at gcc dot gnu dot org 2010-03-20 11:29 ---
Problem is slightly different on fortran-dev, as Dominique says in comment #5.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at gmail dot com 2010-03-20 11:26 ---
(In reply to comment #2)
> class Foo;
> Foo* f();
> int main() {
>Foo* p = f();
>delete [] p;
> }
I can't see how the compiler could possibly do anything useful in this case
if Foo is incomplete. I can't find any
--- Comment #5 from dominiq at lps dot ens dot fr 2010-03-20 11:22 ---
Revision 157552 does not fix the ICE for gfortran.dg/dynamic_dispatch_5.f03
with -fwhole-file on the fortran-dev branch:
/opt/gcc/work/gcc/testsuite/gfortran.dg/dynamic_dispatch_5.f03:32:0: internal
compiler error: i
--- Comment #2 from ramana at gcc dot gnu dot org 2010-03-20 10:51 ---
TARGET_MD_ASSEMBLE_CLOBBERS might just be the help we need on this one - I
think I have a patch which generates the following code. Does that look any
better to you ?
foo:
@ args = 0, pretend = 0, frame = 8
--- Comment #25 from dominiq at lps dot ens dot fr 2010-03-20 10:45 ---
> We are executing the range [scat_1+1, T_10-2] before executing the
> range [0, scat_1-1].
Do you understand why graphite does not detect that the loop for [scat_1+1,
T_10-2] depends on the one for [0, scat_1-1]?
--- Comment #8 from burnus at gcc dot gnu dot org 2010-03-20 09:52 ---
(In reply to comment #7)
> Fixed in 4.5
But not marked as FIXED. I did so now, I hope that's OK.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from toon at moene dot org 2010-03-20 09:39 ---
Works when using Debian's version of gfortran 4.4.3 and their gdb (version
7.0.1).
--
toon at moene dot org changed:
What|Removed |Added
--- Comment #4 from kkojima at gcc dot gnu dot org 2010-03-20 09:08 ---
I'm able to reproduce it with -O2 -fno-schedule-insns on 4.4.
Perhaps debian uses the local patch to make -fno-schedule-insns default.
I'll backport the patch referred in #2 to 4.4 branch if it passes
the usual tests
1 - 100 of 104 matches
Mail list logo
