Hello Joe,
The other hurdle would be the ABI. It's very particular since it has
to accommodate calling into and from EBC, x86, x86_64, ia64, and any
other architecture available. It's structured mainly on Microsoft's
stdcall ABI.
I have read the part about EBC of EFI specification.But I
surfing the web, searching some tool for statically analize the stack
usage I found a pdf from 5 years ago, from the 2005 GCC Developers’
Summit:
http://www.gccsummit.org/2005/2005-GCC-Summit-Proceedings.pdf
In that document is described a GCC command line options: -fstack-usage
(par 2.2.1, pag
Hello Andrew,
Who would maintain this EFI back-end?
The EFI specification was originally developed by Intel, and is now
managed by the Unified EFI Forum[http://www.uefi.org/home/].
So, you don't know who would maintain the EFI back-end that you're
proposing for gcc?
I feel sorry that I
I use avr-gcc and arm-elf-gcc, both version 4.4.3.
I tryed to invoke gcc with -fstack-usage:
cc1: error: unrecognized command line option -fstack-usage
why?
Presumably because the option isn't implemented in this compiler.
where is that option?
An old version is at
Jae Hyuk Kwak wrice...@gmail.com writes:
[...]
Is that true that current implementation of gcc on i386 optimizes
switch statement with decision tree?
I was expecting somebody who can confirm this.
You can see for yourself by writing a variety of switch{} statements
and observing the assembly
Il giorno ven, 19/03/2010 alle 13.20 +0100, Eric Botcazou ha scritto:
I use avr-gcc and arm-elf-gcc, both version 4.4.3.
I tryed to invoke gcc with -fstack-usage:
cc1: error: unrecognized command line option -fstack-usage
why?
Presumably because the option isn't implemented in this
Hello Tristan,
I think the main issue is that EFI C dialect is not ANSI-C
compliant: the size of pointer is determined
at the run-time and therefore the layout of the structure is not
static. Gcc doesn't support this model.
As I read some related information, LLVM IR doesn't care the size
And why this option has been removed?
It hasn't, it never got merged in the FSF tree.
no hope to have that option again in upcoming versions of gcc?
Some hope to have it merged at some point, but no promises as usual.
--
Eric Botcazou
On 16/03/2010 09:15, Sean D'Epagnier wrote:
I went through the c++ parser and added support for fixed point there.
Everything seems to be working, and I am able to use fixed-point
numbers in c++.
The c++ parser is kind of complex and it is possible I missed
something. I would love to get
On Mar 19, 2010, at 1:33 PM, b95705...@ntu.edu.tw wrote:
Hello Tristan,
I think the main issue is that EFI C dialect is not ANSI-C compliant: the
size of pointer is determined
at the run-time and therefore the layout of the structure is not static.
Gcc doesn't support this model.
As
On Mar 19, 2010, at 12:48 PM, b95705...@ntu.edu.tw wrote:
I use Macbook with refit ,and its EFI shell version is 1.10.I have read
some related information but I don't find how to launch EBC virture machine.
I am truely want to know how could I launch it with fully appreciation.
And I am
David Miller wrote:
You said you would fix this several nights ago, but I still
haven't seen any changes to fixincludes since then.
When will you get around to fixing these regressions you
introduced?
Thank you.
Done. Terribly sorry for the delay. I became unemployed and
got a two week
Hi,
What does this message really mean?
i.e. What should I do about it?
ld.so should be loading shared objects in /usr/local/lib,
and that is where libmpc.so lives, so what gives?
Thanks - Bruce
$ cat /etc/SuSE-release
openSUSE 11.1 (x86_64)
VERSION = 11.1
$ ../configure
Hi folks!
I've moved on from register allocation (see Understanding IRA thread)
and onto scheduling.
In particular, I am investigating the effectiveness of the sched1
pass on our architecture and the associated interblock-scheduling
optimisation.
Let's start with sched1 ...
For our
On Fri, Mar 19, 2010 at 5:02 PM, Bruce Korb bruce.k...@gmail.com wrote:
Hi,
What does this message really mean?
i.e. What should I do about it?
run ldconfig or use binaries from
http://download.opensuse.org/repositories/devel:/gcc/openSUSE_11.1
Richard.
ld.so should be loading shared
On 19/03/2010 16:02, Bruce Korb wrote:
Hi,
What does this message really mean?
What it really means is that configure couldn't get the compiler to work, it
doesn't know why, but anyway that there was no object file created after it
tried to invoke the compiler from which it could attempt to
Hi Richard,
On Fri, Mar 19, 2010 at 9:12 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Mar 19, 2010 at 5:02 PM, Bruce Korb bruce.k...@gmail.com wrote:
Hi,
What does this message really mean?
i.e. What should I do about it?
run ldconfig or use binaries from
On Fri, 19 Mar 2010, Ian Bolton wrote:
Let's start with sched1 ...
For our architecture at least, it seems like Richard Earnshaw is
right that sched1 is generally bad when you are using -Os, because
it can increase register pressure and cause extra spill/fill code when
you move
On 03/19/2010 12:09 PM, Ian Bolton wrote:
Hi folks!
I've moved on from register allocation (see Understanding IRA thread)
and onto scheduling.
In particular, I am investigating the effectiveness of the sched1
pass on our architecture and the associated interblock-scheduling
optimisation.
Let's start with sched1 ...
For our architecture at least, it seems like Richard Earnshaw is
right that sched1 is generally bad when you are using -Os, because
it can increase register pressure and cause extra spill/fill code
when
you move independent instructions in between dependent
On Fri, Mar 19, 2010 at 5:09 PM, Ian Bolton bol...@icerasemi.com wrote:
Anyway, the reason I mention interblock-scheduling is that I see it
doing seemingly intelligent moves, but then the later BB-reorder pass
is juggling blocks around such that we end up with extra code inside
hot loops! I
I mention all this because I was wondering which other architectures
have turned off sched1 for -Os? More importantly, I was wondering
if anyone else had considered creating some kind of clever hybrid
that only uses sched1 when it will increase performance without
increasing register
On 03/19/2010 12:47 PM, Ian Bolton wrote:
I mention all this because I was wondering which other architectures
have turned off sched1 for -Os? More importantly, I was wondering
if anyone else had considered creating some kind of clever hybrid
that only uses sched1 when it will increase
On Mar 19, 2010, at 5:33 AM, b95705...@ntu.edu.tw wrote:
Hello Tristan,
I think the main issue is that EFI C dialect is not ANSI-C compliant: the
size of pointer is determined
at the run-time and therefore the layout of the structure is not static.
Gcc doesn't support this model.
As
Let me correct my mistake.
If I understood correctly, your point is that O(log N) is fast enough
because the size of switch is small in practice.
But I am still not convinced that using hash table would not increase the
speed.
As we know hash table requires O(N) only.
There must be some
On 03/18/2010 05:22 AM, Jae Hyuk Kwak wrote:
On Wed, Mar 17, 2010 at 1:04 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
Note, that many hash tables are computed by the modulus operation, which is
often fairly expensive (and on machines without a hardware divide unit,
requiring a
Dear all,
If anyone is interested, we pre-released new MILEPOST GCC supporting versions
4.4.0,4.4.1,4.4.2 and 4.4.3. You can download it here:
http://sourceforge.net/projects/gcc-ici/files/MILEPOST-GCC/V2.1-pre-release
The new documentation is available here:
On Mar 19, 2010, at 12:02 PM, Bruce Korb wrote:
Hi,
What does this message really mean?
i.e. What should I do about it?
ld.so should be loading shared objects in /usr/local/lib,
and that is where libmpc.so lives, so what gives?
Thanks - Bruce
$ cat /etc/SuSE-release
openSUSE 11.1 (x86_64)
On 03/19/10 10:47, Ian Bolton wrote:
I mention all this because I was wondering which other architectures
have turned off sched1 for -Os? More importantly, I was wondering
if anyone else had considered creating some kind of clever hybrid
that only uses sched1 when it will increase performance
Hi Michael,
Thank you for the detailed response.
On Fri, Mar 19, 2010 at 9:54 AM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
On Thu, Mar 18, 2010 at 05:10:18PM -0700, Jae Hyuk Kwak wrote:
Hi Michael,
Thank you for the details.
If I understood correctly, your point is that O(log N)
Jae Hyuk Kwak wrote:
For the issue of Modulus operation, it does not need to be divide or
hardware modulus operation.
Let me give you an example here:
13 % 2 = 1
13 (2-1) = 1
Yes, of course, we all know that, and of course the compiler does
these simple optimizations. However, for computing
Hi Robert,
On Fri, Mar 19, 2010 at 2:13 PM, Robert Dewar de...@adacore.com wrote:
Jae Hyuk Kwak wrote:
For the issue of Modulus operation, it does not need to be divide or
hardware modulus operation.
Let me give you an example here:
13 % 2 = 1
13 (2-1) = 1
Yes, of course, we all know
Hi,
I would like to get some advice on handling Android for x86 in
tool configurations. Android is based on Linux but it is exactly the
same, so some customizations are required. There was a discussion
among people working on Android and someone suggested using
i*86-unknown-android. My
Jae Hyuk Kwak wrote:
Hi Robert,
On Fri, Mar 19, 2010 at 2:13 PM, Robert Dewar de...@adacore.com wrote:
Jae Hyuk Kwak wrote:
For the issue of Modulus operation, it does not need to be divide or
hardware modulus operation.
Let me give you an example here:
13 % 2 = 1
13 (2-1) = 1
Yes, of
Hi Bruce,
* Bruce Korb wrote on Fri, Mar 19, 2010 at 05:22:15PM CET:
On Fri, Mar 19, 2010 at 9:12 AM, Richard Guenther wrote:
On Fri, Mar 19, 2010 at 5:02 PM, Bruce Korb wrote:
What does this message really mean?
i.e. What should I do about it?
run ldconfig or use binaries from
On 19/03/2010 21:13, Robert Dewar wrote:
Jae Hyuk Kwak wrote:
For the issue of Modulus operation, it does not need to be divide or
hardware modulus operation.
Yes, of course, we all know that, and of course the compiler does
these simple optimizations. However, for computing hashes you
On Fri, 2010-03-19 at 22:06 +0800, fanqifei wrote:
1. I add movsi expander in which function foor_expand_move is used to
force the operands[1] to reg and emit the move insn.
Another change is that in the define of insn “*mov_mode_insn in which
a condition is added to prevent a store const
On 19/03/2010 22:07, Robert Dewar wrote:
You miss my point, doing a mod with 256 is an AWFUL hash algorithm
since it only uses the low order 8 bits!
This statement is only true contingent on a number of significant
assumptions you haven't stated - assumptions which can easily be violated.
On Fri, 19 Mar 2010, Doug Kwan (Ãö®¶¼w) wrote:
Hi,
I would like to get some advice on handling Android for x86 in
tool configurations. Android is based on Linux but it is exactly the
same, so some customizations are required. There was a discussion
among people working on Android and
On Thu, Mar 18, 2010 at 10:29 AM, roy rosen roy.1ro...@gmail.com wrote:
Hi,
I am trying to implement a simple load 8 bytes instruction.
I tried to use movdi so that it would allocate two sequential
registers for the load.
It starts well but in pass subreg1 the insns are decomposed and all DI
Thanks for the fast reply,
On Fri, Mar 19, 2010 at 3:07 PM, Robert Dewar de...@adacore.com wrote:
In many situations, hash tables turn out to be more efficient than
search trees or any other table lookup structure.
The above quote from Wikipedia is indeed misleading because it does
not make
That's a very good suggestion. Thanks.
-Doug
2010/3/19 Joseph S. Myers jos...@codesourcery.com:
On Fri, 19 Mar 2010, Doug Kwan (Ãö®¶¼w) wrote:
Hi,
I would like to get some advice on handling Android for x86 in
tool configurations. Android is based on Linux but it is exactly the
Dave Korn wrote:
Please, nobody bring up the old saw that prime numbers are a good choice for
hashtable sizes. They aren't, they're a crude workaround for a poor hash
function.
Well on a machine with a fast modulus operation, the crude workaround
is often the most efficient algorithm in
By the way, in practice I have found that in many situations, the
input to hash functions is nowhere near pseudo-random, e.g. this
is very much true of identifiers in programs, so the best hash
algorithm is often one that is specialized for the particular
non-pseudo-random domain.
Of course in
Dave Korn wrote:
On 19/03/2010 22:07, Robert Dewar wrote:
You miss my point, doing a mod with 256 is an AWFUL hash algorithm
since it only uses the low order 8 bits!
This statement is only true contingent on a number of significant
assumptions you haven't stated - assumptions which can
Jae Hyuk Kwak wrote:
A quote from this article:
... the switch very efficiently, even constructing a hash table if this
method of switching is ...
Yes, it does. Such a old paper mentioned it and we are still not doing it.
So it makes me wonder why.
Why? Perhaps because it is not helpful
Jae Hyuk Kwak wrote:
Now we have a switch statement that has 400 cases or whatever.
switch ( valueFormUser )
{
case 0: do1(); break;
case 1: do2(); break;
case 2: do3(); break;
...
case 399: do399(); break;
default: break;
Well clearly if you have 400 cases like this,
We are glad to announce that GCC has been accepted Google's Summer of
Code 2010 program. Summer of Code is a program sponsored by Google in
which students are paid to contribute to open source projects. This
will be GCC's fifth year of participation. For more information, see
Hi Ralf,
I used: ../configure make make install and that installed it
to /usr/local/lib. However, /usr/local/lib, despite being in /etc/ld.so.conf,
it was not in ld.so.cache. re-running ldconfig did the trick. I've had
/usr/local/lib in the cache for years now, so I don't know how it went
--- Comment #3 from iwamatsu at nigauri dot org 2010-03-19 06:11 ---
(In reply to comment #2)
Looks the same issue in
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00747.html
though I can't reproduce the problem with my gcc-4.4.3 and
4.4 head compilers for the test case in #1.
The -O0 result looks right. This behavior observed on x86 using r157445 and
x64 using r157542.
reg...@john-home:~$ current-gcc -O0 small.c -o small -Wall
reg...@john-home:~$ ./small
1
reg...@john-home:~$ current-gcc -O1 small.c -o small -Wall
reg...@john-home:~$ ./small
0
reg...@john-home:~$
--- Comment #1 from sezeroz at gmail dot com 2010-03-19 06:51 ---
Happened on x86_64-pc-linux and my gcc-4.4 was affected too, gcc-3.4.6 seemed
fine.
--
sezeroz at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-19 07:19
---
Subject: Bug 43106
Author: ebotcazou
Date: Fri Mar 19 07:18:47 2010
New Revision: 157558
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157558
Log:
PR ada/43106
*
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-03-19 07:22
---
Presumably by the overhaul of the subtypes support.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from kurt at garloff dot de 2010-03-19 08:03 ---
Well for 4.5, make sure you configured with --enable-checking=release;
otherwise it is not a fair comparison.
Did not change anything unfortunately :-(
(I have enabled --enable-lto in case this matters, though I have
--- Comment #2 from mikpe at it dot uu dot se 2010-03-19 09:46 ---
4.2.4/4.3.4/4.4.3 are affected, 4.1.2 and older seem to be Ok.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
I think gcc produce wrong location information of function argument.
/* sample source sub.c **/
int test(int first, int second)
{
return second;
}
//
The sample source is compiled as follows.
==
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-03-19 09:56
---
(In reply to comment #13)
Hi!
I was wondering if this bug is likely to be fixed in the next GCC release; is
this likely to be the case?
Unlikely. Backporting the one-line change will cause massive
--- Comment #14 from rguenther at suse dot de 2010-03-19 10:09 ---
Subject: Re: [4.3 Regression] very long
compile-time in PRE building gimp-plugin-registry
On Fri, 19 Mar 2010, kurt at garloff dot de wrote:
--- Comment #11 from kurt at garloff dot de 2010-03-19 00:34 ---
--- Comment #18 from jamborm at gcc dot gnu dot org 2010-03-19 10:14
---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-03-19 10:15
---
(In reply to comment #14)
Subject: Re: [4.3 Regression] very long
compile-time in PRE building gimp-plugin-registry
On Fri, 19 Mar 2010, kurt at garloff dot de wrote:
--- Comment #11 from kurt at
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 10:18 ---
Subject: Bug 43415
Author: rguenth
Date: Fri Mar 19 10:18:25 2010
New Revision: 157562
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157562
Log:
2010-03-19 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-19 10:18 ---
Fixed for 4.5 sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #13 from mrs at gcc dot gnu dot org 2010-03-19 10:20 ---
Subject: Bug 42554
Author: mrs
Date: Fri Mar 19 10:19:52 2010
New Revision: 157563
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157563
Log:
PR ada/42554
* configure.ac: Only pass -c to ranlib
--- Comment #47 from rguenth at gcc dot gnu dot org 2010-03-19 10:26
---
(In reply to comment #46)
The answer to the question (b) in comment #35:
(b) why !optimize_size has been replaced with optimize_insn_for_speed_p ()?
seems to be
this patch replace some of optimize_size
--- Comment #48 from rguenth at gcc dot gnu dot org 2010-03-19 10:35
---
Untested patch doing 2):
Index: builtins.c
===
--- builtins.c (revision 157561)
+++ builtins.c (working copy)
@@ -2980,10 +2980,16 @@
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-19 11:02 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 11:29 ---
Combine breaks this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-19 11:35 ---
It combines
(insn 6 5 7 2 t.c:16 (parallel [
(set (reg:SI 59 [ D.2732 ])
(ior:SI (reg:SI 67 [ g_9 ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
--- Comment #4 from ramana at gcc dot gnu dot org 2010-03-19 12:04 ---
Yes - haven't thought about it much, maybe the backend could give an error if a
frame were allocated for a naked function rather than ICE'ing in an awkward
place.
--
ramana at gcc dot gnu dot org changed:
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-19 12:06 ---
Breakpoint 7, combine_simplify_rtx (x=0x75ae6e58, op0_mode=VOIDmode,
in_dest=0) at /space/rguenther/src/svn/trunk/gcc/combine.c:4861
4861 enum rtx_code code = GET_CODE (x);
(set (reg:SI 69)
(and:SI
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-19 12:37 ---
Subject: Bug 43305
Author: matz
Date: Fri Mar 19 12:37:28 2010
New Revision: 157567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157567
Log:
PR 43305
* builtins.c
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-19 12:38 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-19 12:40 ---
make_extraction (mode=SImode, inner=0x75b48ac8, pos=0, pos_rtx=0x0, len=8,
unsignedp=1, in_dest=0, in_compare=0)
at /space/rguenther/src/svn/trunk/gcc/combine.c:6648
6648 enum machine_mode is_mode
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 12:53 ---
(In reply to comment #2)
Oh it might also need the patch for PR 29751 which I hope to submit for 4.6.
Note the patch in there still works and has been tested as of earlier this
week.
New mem-ref will make that
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-19 13:07 ---
*** Bug 43429 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43426
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-19 13:07 ---
*** This bug has been marked as a duplicate of 43426 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Function:
float y;
float foo(float x)
{
y = x * x + x;
asm volatile (vmov.i8 q0, #0 ::: q0);
asm volatile (vmov.i8 q1, #0 ::: q1);
asm volatile (vmov.i8 q2, #0 ::: q2);
asm volatile (vmov.i8 q3, #0 ::: q3);
asm volatile (vmov.i8 q4, #0 ::: q4);
asm volatile (vmov.i8 q5,
--- Comment #8 from eli dot osherovich at gmail dot com 2010-03-19 13:27
---
(In reply to comment #6)
Also: 1e22 is not exactly representable as a floating point number. By
consequence, 1e22 is different numbers when stored as a double or a
long double, and we should expect
--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-03-19 13:27
---
I think the compiler should throw an error if there are any statements in the
naked function other than asm statements. All such asms should be treated as
volatile.
--
--- Comment #9 from eli dot osherovich at gmail dot com 2010-03-19 13:29
---
(In reply to comment #7)
Subject: Re: sinl is not computed correctly
On Thu, 18 Mar 2010, bangerth at gmail dot com wrote:
Also: 1e22 is not exactly representable as a floating point number. By
--- Comment #12 from danglin at gcc dot gnu dot org 2010-03-19 13:30
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2010-03-19 13:32 ---
Yes, there is no easy way of describing the container relationship of the Neon
registers to the compiler at the minute. Thus the only work around at the
moment is to indicate that all the registers contained as part
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-
O2 -fexceptions -fnon-call-exceptions -fpeel-loops -c -o pr42427.o
/test/gnu/gc
c/gcc/gcc/testsuite/gcc.dg/pr42427.c(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr42427.c:5:21: fatal error: complex.h:
N
--- Comment #1 from nightstrike at gmail dot com 2010-03-19 14:25 ---
This is probably due to the way you built GCC. To have a completely
relocatable toolchain, you need to use the --with-sysroot option to configure,
and you need to set it equal to prefix or below prefix in the
--- Comment #6 from marti at juffo dot org 2010-03-19 14:46 ---
(In reply to comment #5)
I think the compiler should throw an error if there are any statements in the
naked function other than asm statements.
This would break a lot of code; there are use cases where you want to
--- Comment #3 from ramana at gcc dot gnu dot org 2010-03-19 15:12 ---
Is this for Thumb1 or Thumb2 ? Can you check with trunk today ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2010-03-19 15:21 ---
Confirmed with trunk.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 15:33 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00893.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #49 from dominiq at lps dot ens dot fr 2010-03-19 15:40 ---
A few remarks about comments #47 and #48
Note that this PR isn't too serious as -fwhole-file isn't the default
for Fortran so we do not run into this unfortunate interaction of
profile estimation and inlining.
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-19 15:46 ---
Well, just fixed on the trunk. This fix looks simple enough that it should be
backportable.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from aldyh at gcc dot gnu dot org 2010-03-19 15:48 ---
Created an attachment (id=20141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20141action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
--- Comment #3 from aldyh at gcc dot gnu dot org 2010-03-19 15:58 ---
Reproduce with: ./cc1 -g -O a.i -mscore3
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ramana at gcc dot gnu dot org 2010-03-19 15:58 ---
Subject: Bug 43399
Author: ramana
Date: Fri Mar 19 15:58:37 2010
New Revision: 157574
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157574
Log:
Fix PR target/43399
2010-03-19 Ramana Radhakrishnan
While looking at PR43058, I've noticed that we generate tons of completely
useless location list elements. E.g. on the pr43058.c testcase with X2 instead
of X4 X4 and without the PR43058 patch applied, we generate extremely long
location list for the first a variable and then each loclist is 2
--- Comment #10 from zsojka at seznam dot cz 2010-03-19 16:08 ---
How does the test work, would it fail on non-patched trunk?
- extern int printf(const char *format, ...);
- printf(%d\n, foo(100));
+ if (foo(100) != 6)
+ __builtin_abort ();
I *think* this would do the job, but I
--- Comment #4 from nightstrike at gmail dot com 2010-03-19 16:16 ---
Can we fix this before 4.5 is released?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 16:18 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00899.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-19 16:23 ---
I'm not sure what you're asking. When the unpatched compiler the testcase
(with the printf or the x!=6-abort) will ICE with a checking compiler,
and produce wrong output (0 or an abort) with a nonchecking compiler.
1 - 100 of 165 matches
Mail list logo
