--- Comment #6 from wlam at kosmix dot com 2010-03-20 06:40 ---
Thanks for the quick fix! (I was just trying trunk at r157584 after your
comment above.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43415
--- Comment #5 from siarhei dot siamashka at gmail dot com 2010-03-20
08:45 ---
(In reply to comment #4)
Also, what's the configuration in this case i.e what architecture,
mode / cpu / fpu ?
Tested on ARM Cortex-A8 hardware, the problematic package built either natively
or
--- Comment #6 from dodji at gcc dot gnu dot org 2010-03-20 08:55 ---
Subject: Bug 43375
Author: dodji
Date: Sat Mar 20 08:55:32 2010
New Revision: 157590
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157590
Log:
Fix for PR c++/43375
gcc/cp/ChangeLog:
PR c++/43375
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #7 from dodji at gcc dot gnu dot org 2010-03-20 08:56 ---
Fixed in 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43375
--- 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
--- 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 #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 #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 #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 =
--- 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:
--- 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 #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 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 #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
--- 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
--- 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 #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
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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
--- 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
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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
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 #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=20145action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43454
--- 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=gccview=revrev=157592
Log:
2010-03-20 Richard Guenther rguent...@suse.de
PR
--- 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 #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.
--
--- 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 #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.
--
--- 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=20146action=view)
A fix for the PR
This bootstraps and regtests on FC9/x86_64
Paul
--
pault at gcc dot gnu dot org changed:
--- 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 #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
--- 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=gccview=revrev=157593
Log:
2010-03-20 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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 not
--- 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=gccview=revrev=157594
Log:
2010-03-20 Jerry DeLisle jvdeli...@gcc.gnu.org
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- 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 by
--- 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 implemented. As a
--- 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 #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
--- 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=gccview=revrev=157595
Log:
2010-03-20 Paul Thomas pa...@gcc.gnu.org
PR
--- 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 #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
--- 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 #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 #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=gccview=revrev=157596
Log:
2010-03-20 Andrew Pinski pins...@gmail.com
PR
--- 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=gccview=revrev=157597
Log:
gcc/cp/
2010-03-20 Simon Martin
--- 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 #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 #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 #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
--- 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 .
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
--- 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
--- 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 #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
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|--- |4.3.5
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
--- 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
--- 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 #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 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 #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 #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.
--
--- 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
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
--- 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
--- 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),
--- 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), (array *) ((void
--- 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
--- 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 #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
--- 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) ? ((Int)
--- 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 before
--- 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 : 0)
--- 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 #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.
--- 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=20147action=view)
test program to take a stack trace using _Unwind_ API
I'm attaching a test program which sets up a predictable call
--- 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 #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.
--
--- 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.
--
--- 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
--- 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
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/
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/
--- 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
--- 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.
--
--- 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
Simple testcase:
--8--8--8--8--8--8--8--8--8--8--8--
#include errno.h
#include unistd.h
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;
$ 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
--- 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
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: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
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;
}
1 - 100 of 105 matches
Mail list logo
