Joe Buck wrote:
On Wed, Jun 06, 2007 at 11:13:16AM -0700, Lothar Werzinger wrote:
when I build a coverage build of my software I get some undefined symbols
like global constructors keyed to src_utility_Tree.cpp_90B986A5_564B8955
I did some investigation and as you can see in the below test
Zdenek Dvorak wrote:
...
The number of parallel computations in loop.
The estimated latency of the critical path of loop.
The estimated cycle length of loop body.
The max. dependence height of computations.
The max. height of memory dependencies of computations.
The max. height of control
When I looked at what sparc-gcc was generating for the return
address column, I discovered that it didn't generate anything.
At least it generates the RA column:
.section.eh_frame,#alloc,#write
.LLframe1:
.uaword .LLECIE1-.LLSCIE1 ! Length of Common Information
On 6/9/07, Andrew Pinski [EMAIL PROTECTED] wrote:
On 6/7/07, Mark Mitchell [EMAIL PROTECTED] wrote:
* PTR_PLUS branch.
I believe that this branch should be included in GCC 4.3. Andrew,
would you please update me as to its status?
Yes, the summary is the branch has two autovector
Trying to get current (last build 3,3) , I
installed
texinfo 4.8 and make 2.81 first - I am using the
following setup and make lines:
SRC=/local/src/gnu/gcc-4.1.2; CONFIG_SHELL=/bin/ksh
$SRC/configure --without-fast-fixincludes
--enable-languages=c,c++,java
make CFLAGS='-O' LIBCFLAGS='-g
Eric Botcazou wrote:
When I looked at what sparc-gcc was generating for the return
address column, I discovered that it didn't generate anything.
At least it generates the RA column:
The CIE says what the RA column is, but there is no initial value
location expression generated for the
Eric Botcazou wrote:
The CIE says what the RA column is, but there is no initial value
location expression generated for the return address. That means
that on entry to a function, the CIE cannot be used to tell what
the return address is.
I'm not sure I understand. The RA column is the
Not by GDB.
Then an approach could be to patch the GDB unwinder to make it follow the GCC
conventions.
You seem to be under the misapprehension that I'm talking about exception
handling in gcc. I'm not.
Well, GCC doesn't generate 2 flavor of CIEs (on SPARC) so considerations that
apply to
Eric Botcazou wrote:
Not by GDB.
Then an approach could be to patch the GDB unwinder to make it follow the GCC
conventions.
The correct approach would be to have gcc generate correct DWARF data.
Indeed, I have patch gdb to work around the inaccurate CIE.
You seem to be under the
Hi all,
From gcc documents, I know that if the condition code or comparison
result can be placed in any general register, or if there are multiple
condition registers, use a pseudo register. I want to use general
register, but I don't know how to do it. Could someone know that? And
show
Brooks Moses wrote:
Several members of the GFortran team (primarily Chris Rickett and Steve
Kargl) have been working on a project to add the BIND(C) functionality
from the Fortran 2003 standard. This provides for a standard means of
linking Fortran code with code that uses standard C linkage
Eric Botcazou wrote:
Debugging does.
I fail to see why, at least on SPARC, %o7 should be good enough.
You set a breakpoint at the return address assuming that you
will reach it when you finish the function. On Sparc, if you
set it at the address in %o7, you will be setting the breakpoint
at
OK
I had make 2.81 installed from the get-go and it did
not conform to the smart make, but the first time I
tried to fix by installing texinfo just before make
install - NFG.
I installed texinfo and rebuilt the world - it worked.
Thanks - and yes I will do my bit to support GNU as
soon as it
Following testcase returns wrong result on x86_64-pc-linux-gnu due to the
mismatch of return type from soft-fp/getf2.c (and letf2.c). The return type
from soft-fp functions is int (SImode) but the test in prepare_float_lib_cmp()
/optabs.c/ that test the returned value expands to word_mode (DImode
--- Comment #11 from v dot haisman at sh dot cvut dot cz 2007-06-09 08:33
---
I guess this is now passé.
--
v dot haisman at sh dot cvut dot cz changed:
What|Removed |Added
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-06-09 08:40
---
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00304.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-06-09 09:10 ---
This is soft-fp problem. The libc patch is at
http://sourceware.org/ml/libc-alpha/2007-06/msg00057.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #173 from rguenth at gcc dot gnu dot org 2007-06-09 09:48
---
Full testing shows no (or at least 0.5%) performance regression on tramp3d
runtime. Compile time seems to go up by 0.5% (that looks consistent, about the
same with previous patches) for tramp3d. Testcases not
--- Comment #174 from pcarlini at suse dot de 2007-06-09 09:55 ---
Great!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
SPEC2006 403.gcc is miscompiled so we ICE building scilab.i:
scilab.i:12953: Internal compiler error in remove_useless_values, at
cselib.c:394
flags used for building 403.gcc are -O3 -funroll-loops -fpeel-loops
-ftree-vectorize. (base with -O2 still works ok)
The change happened between
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-09 10:27 ---
We need this reduced to a managable testcase that gcc miscompiles.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rask at sygehus dot dk 2007-06-09 11:02 ---
It is still broken as of revision 125570.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
--- Comment #175 from bkoz at gcc dot gnu dot org 2007-06-09 12:03 ---
Nice, thanks Ian.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #12 from bkoz at gcc dot gnu dot org 2007-06-09 12:05 ---
I'm going to close this.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #13 from bkoz at gcc dot gnu dot org 2007-06-09 12:12 ---
Should be fixed now on mainline and 4.2.1+, Paolo updated docs as well.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ian at gcc dot gnu dot org 2007-06-09 16:28 ---
Subject: Bug 32169
Author: ian
Date: Sat Jun 9 16:28:31 2007
New Revision: 125591
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125591
Log:
./:
PR tree-optimization/32169
* tree-vrp.c
--- Comment #6 from ian at gcc dot gnu dot org 2007-06-09 16:31 ---
Subject: Bug 32169
Author: ian
Date: Sat Jun 9 16:31:11 2007
New Revision: 125592
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125592
Log:
./:
PR tree-optimization/32169
* tree-vrp.c
--- Comment #7 from ian at airs dot com 2007-06-09 16:35 ---
Fixed. Thanks for reporting it.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from kargl at gcc dot gnu dot org 2007-06-09 17:06 ---
(In reply to comment #2)
From [EMAIL PROTECTED]
I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
the most recent patches. My version is 2.2.1-p5.
What does p4 do?
They only offer
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-09 18:55 ---
This is the same bug as PR 30572.
*** This bug has been marked as a duplicate of 30572 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-09 18:55 ---
*** Bug 32255 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-09 19:01
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-06-09 19:27
---
There are a couple of issues going on here. First, if the input file is a
regular file which is seekable, gfortran is indeed giving the wrong result.
This is because the endfile condition was not being set
--- Comment #176 from mark at codesourcery dot com 2007-06-09 19:29 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenth at gcc dot gnu dot org wrote:
So, from my point of view the patch is ready to be exposed to more
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-09 19:37
---
I have confirmed that this is a regression against g77, 4.2 and 4.1 in all
cases, so the hunt is on.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-06-09 20:52
---
The patch that broke this is r123403 which is my patch for 31052. Not
surprising. We need to be real careful here because this patch fixes a
regression we had on SPEC. I will need someone with SPEC access to
--- Comment #1 from patchapp at dberlin dot org 2007-06-09 21:25 ---
Subject: Bug number PR c++/32111
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00593.html
--
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-06-09 22:20
---
Even shorter testcase:
=
templatetypename T struct A
{
T foo();
A() { foo.~T(); }
};
Aint a;
=
With checking enabled I get the following
--- Comment #6 from chris at bubblescope dot net 2007-06-10 00:10 ---
While fixing this could stop that illegal code, wouldn't it also lead to
increased code size where you have multiple sets of (for example) ints
templated on different comparitors?
--
chris at bubblescope dot net
--- Comment #7 from pcarlini at suse dot de 2007-06-10 00:20 ---
That question occured to me too... Now I'm thinking that probably isn't a real
issue assuming good optimizers, as usual. Do you have a practical example?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31970
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 01:56 ---
The java source compiler has been removed from gcc 4.3 so closing as won't fix.
Also I don't think unused parameters are common in OOP but in java.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-10 02:10 ---
What target are you targetting?
Also I can't reproduce this on the trunk.
Can you provide the output of gcc -v ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32166
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-10 02:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-10 02:18 ---
*** Bug 32141 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 02:18 ---
*** This bug has been marked as a duplicate of 30111 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from patchapp at dberlin dot org 2007-06-10 02:20 ---
Subject: Bug number PR32235
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00596.html
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 02:21 ---
Confirmed, not a regression as far as the eyes can see.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-10 02:23 ---
I have noticed this more and more on the pointer plus branch, why it shows up
there more I don't know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-10 02:27 ---
The ones that had internal errors are now gone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-10 02:37 ---
/* Fail if there is not enough space. If there are this many operands
required, first make sure there isn't a different problem causing this
many operands. If the decision is that this is
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-10 02:57 ---
I think this is becuase we are looking into the static array variable's
initializers.
For an example:
static StgWord rY52_closure[] = { (W_)base_GHCziBase_ZC_static_info,
(W_)rY50_closure,
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-06-10 03:07
---
I think this is sufficiently fixed. We do not need to support bad coding
practices (meaning not standard compliant
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 03:14 ---
Point 2): (Retorical Questions) Why do we use gcc ? - The OS's gcc. Which
version are we using, do we care? Can it actually compile the tests?
Because this has to be the build compiler, otherwise it is hard to
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-06-10 03:18
---
It should never result in more warnings.
More inlining :)
Anyways the use is still uninitialized if you look at the IR, GCC itself cannot
tell if r is initialized by looking at the IR.
--
pinskia at gcc dot
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 03:20 ---
Can you attach
/space/projects/reference/tools/arm-elf-gnu/4.2.0/gcc-build-926ej-s/./gcc/as ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-10 03:23 ---
This is an extension that GCC allows some constant folding with some functions.
So this is just a missed optimization of not constant folding sin.
And yes this is fixed in 4.3.0 by the use of MPFR.
--
pinskia
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-10 03:24 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 03:26 ---
Note you most likely don't have a x86_64-elf compiler installed anyways but we
should not be crashing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-06-10 03:31 ---
It won't be fixed by sccvn, at least not initially.
SCCVN has very strict rules about what expressions it decides are worth trying
to keep around to simplify other expressions.
Right now, we only keep those for
60 matches
Mail list logo