On 01/08/2010 16:26, Gabor Kerenyi wrote:
I'm porting GCC 4.4.4 to a new arch and while cross-compiling libgcc I get
the
following error:
../../../libgcc/../gcc/libgcc2.c: In function ‘__clzsi2’:
../../../libgcc/../gcc/libgcc2.c:716: error: unrecognizable insn:
(insn 49 48 50 16
If I understand correctly it complains about a move instruction where src
memory location should be (reg22+reg23). My arch defines:
#define MAX_REGS_PER_ADDRESS 1
the first pseudo reg is 13
I think the wording of the second sentence in the M_R_P_A documentation
(beginning 'Note
Hi,
I ran a small test to see how the trunk/4.5 works
with the rewritten restrict qualified pointer code. But it doesn't
seem to work on both x86-64 and our port.
tst.c:
void foo (int * restrict a, int * restrict b,
int * restrict c, int * restrict d)
{
*c = *a + 1;
*d = *b + 1;
}
On Mon, 2 Aug 2010, Bingfeng Mei wrote:
Hi,
I ran a small test to see how the trunk/4.5 works
with the rewritten restrict qualified pointer code. But it doesn't
seem to work on both x86-64 and our port.
tst.c:
void foo (int * restrict a, int * restrict b,
int * restrict c,
On Mon 2 Aug 2010 10:44, Kilbane, Stephen pondered:
For #6101, the test's just started failing for 4.3 because 4.3 adds a
new xfail condition not applied to 4.1:
4.1: // { dg-do run { xfail sparc*-*-solaris2* } }
4.3: // { dg-do run { xfail { { sparc*-*-solaris2* } || lax_strtofp } } }
Hi, please have a look at the
Bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
And a patch(for gcc-4.4.4) posted therein. It seems to fix the issue.
Yet, I need to confirm whether DW_AT_external flag should be set for the public
functions of a C++ class or not?
I guess not, because
On Sat, Jul 31, 2010 at 00:16, Mark Mitchell m...@codesourcery.com wrote:
In any case, you're suggesting we go against the express wishes of the
FSF. Would you suggest that we do that in the context of FSF GCC?
Well, this issue is another one in a long series of roadblocks that
we've had to
We are already having trouble keeping our documentation up-to-date.
Some of it is in such a poor shape as to be laughable. Yes, it's
mostly our fault, but if we were able to generate documentation by
simply extracting it from the code. Tools exist for this, and
properly maintained, they are
On 10-08-02 19:17 , Richard Kenner wrote:
We are already having trouble keeping our documentation up-to-date.
Some of it is in such a poor shape as to be laughable. Yes, it's
mostly our fault, but if we were able to generate documentation by
simply extracting it from the code. Tools exist for
On Tue, Aug 3, 2010 at 1:17 AM, Richard Kenner
ken...@vlsi1.ultra.nyu.edu wrote:
We are already having trouble keeping our documentation up-to-date.
Some of it is in such a poor shape as to be laughable. Yes, it's
mostly our fault, but if we were able to generate documentation by
simply
That is true, but very often the documentation is needed in two
places: in the code and in the manual. Especially for things like
machine constraints, flags and options.
Yes, but the audiences are different between users who read the manual and
developers who read the code. For the best
Richard Kenner wrote:
That is true, but very often the documentation is needed in two
places: in the code and in the manual. Especially for things like
machine constraints, flags and options.
Yes, but the audiences are different between users who read the manual and
developers who read the
On Aug 2, 2010, at 7:17 PM, Richard Kenner wrote:
We are already having trouble keeping our documentation up-to-date.
Some of it is in such a poor shape as to be laughable. Yes, it's
mostly our fault, but if we were able to generate documentation by
simply extracting it from the code.
Richard, your argument is a distraction from the important issue at
hand. Unless you posit that there is no useful way in which to generate
documentation from code (and comments therein), which seems an extreme
statement, then it is desirable that we have the ability to do that.
Right now we
Richard Kenner wrote:
bad isn't very precise. The claim was made that a reason that it's bad
is that not being able to automatically generate documentation lowers
the quality of the documentation. That's what I disagree with.
OK, fine; that's a reasonably debatable point. But, we
I am work on a project related with GCC AST.
In my project, i write a plugin for GCC. This plugin read a AST from a
source code, a covert this source code to another language.
Currently i have a problem with GCC AST. In particular, i cannot
retrieve all information about CALL_EXPR.
I read GCC
--- Comment #35 from paolo dot carlini at oracle dot com 2010-08-02 06:53
---
Thanks a lot Armand (by the way, many thanks to Ralf too)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-02 06:56 ---
Probably related to PR 44584.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Attempting to bootstrap gcc-4.6-20100731 (r162788) on armv5tel-linux-gnueabi
fails due to bootstrap comparison failures after stage 3:
make[3]: Leaving directory `/home/mikpe/objdir46'
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning:
Assume there is a directory foo in the current directory and there is a foo.c
in ./foo , I saw this on 4.5.1
$ gcc-4.5 -fdump-tree-optimized -save-temps=obj foo/foo.c -S -o foo/foo.s
foo/foo.c: In function foo:
foo/foo.c:1:6: error: could not open dump file foo/foo/foo.140t.optimized: No
such
--- Comment #1 from jiez at gcc dot gnu dot org 2010-08-02 08:43 ---
Make the summary more specific.
--
jiez at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from bernds at gcc dot gnu dot org 2010-08-02 10:07 ---
Subject: Bug 40457
Author: bernds
Date: Mon Aug 2 10:06:47 2010
New Revision: 162815
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162815
Log:
PR target/40457
* config/arm/arm.h
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45162
--- Comment #5 from dominiq at lps dot ens dot fr 2010-08-02 11:41 ---
As pointed out by Dominique, one needs to be careful. I think one can
optimize:
c = matmul(b, transpose(c))
c = matmul(c,b)
where c is a rank-2 matrix. I think one cannot optimize it if c is just a
--- Comment #24 from ian dot bolton at arm dot com 2010-08-02 12:23 ---
(In reply to comment #23)
I can confirm this fails with GCC 4.4.4 and that GCC 4.3.2 works.
I get no warning and correct code in latest 4.4 branch (4.4.5 - 20100727), but
I do get the warning and incorrect code
--- Comment #6 from burnus at gcc dot gnu dot org 2010-08-02 12:41 ---
(In reply to comment #5)
As pointed out by Dominique, one needs to be careful. I think one can
optimize:
c = matmul(b, transpose(c))
c = matmul(c,b)
where c is a rank-2 matrix. I think one cannot
--- Comment #3 from t dot artem at mailcity dot com 2010-08-02 13:09
---
I've just tested GCC 4.5.1 and it also miscompiles the source code.
--
t dot artem at mailcity dot com changed:
What|Removed |Added
--- Comment #4 from t dot artem at mailcity dot com 2010-08-02 13:10
---
Created an attachment (id=21369)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21369action=view)
faad2 2.7.0 complete sources with -save-temps for GCC 4.5.1
--
--- Comment #5 from t dot artem at mailcity dot com 2010-08-02 13:15
---
I've found the culprit (or better say mplayer developer hinted), it is
-fstrict-aliasing optimization.
With -fno-strict-aliasing GCC 4.4.x and 4.5.x produce proper code.
Please, advise.
--
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2010-08-02 13:19
---
Closing as fixed. Regarding comment #7. I do not see the problem on 4.5. I
reran tests here on my machine that failed with 4.6 and there were no failures
on 4.5
--
jvdelisle at gcc dot gnu dot org
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-08-02 13:28 ---
(In reply to comment #6)
Is there a patch for 4.5.1 for this somewhere? I'm hitting this issue at gcc
4.5.1 java boostrap (#45154)
The patch is really the same. I did not commit it because the branch
was
--- Comment #25 from ian dot bolton at arm dot com 2010-08-02 13:33 ---
(In reply to comment #24)
(In reply to comment #23)
I can confirm this fails with GCC 4.4.4 and that GCC 4.3.2 works.
I get no warning and correct code in latest 4.4 branch (4.4.5 - 20100727), but
I do get
--- Comment #7 from dominiq at lps dot ens dot fr 2010-08-02 13:39 ---
I fail to see why a scalar temporary is not enough:
do j = 1, N
do i = 1, N
tmp = 0.0
do k = 1, N
tmp = a(i,k)*b(k,j)
end do
a(i,j) = tmp
end do
end do
Note: it won't work with
--- Comment #8 from burnus at gcc dot gnu dot org 2010-08-02 14:10 ---
(In reply to comment #7)
I fail to see why a scalar temporary is not enough:
Well, try:
I concede defeat.
If one want to enter this kind of reduced temporaries, another candidate is
a=transpose(a) which
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-02 14:12 ---
Why CC me? I have no clue about faad2, the strict-aliasing thing hints
at errors in faad2, not gcc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dominiq at lps dot ens dot fr 2010-08-02 14:36 ---
Well, with an array descriptor it one only changes the strides/bounds ...
From polyhedron test induct.f90
[macbook] lin/test% gfc -Warray-temporaries induct.f90
induct.f90:1629.20:
rotate_quad =
--- Comment #1 from ramana at gcc dot gnu dot org 2010-08-02 14:55 ---
Confirmed. My bootstrap with thumb2 and armv7-a failed as well. Here's the
configuration line . I only see a comparison failure with tree-vect-data-refs.o
in this configuration.
Configured with:
--- Comment #2 from ramana at gcc dot gnu dot org 2010-08-02 14:58 ---
Created an attachment (id=21370)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21370action=view)
Disassembly and object files that are different with the thumb2 bootstrap
Disassembly and object files in this
--- Comment #10 from mikael at gcc dot gnu dot org 2010-08-02 15:31 ---
Subject: Bug 44064
Author: mikael
Date: Mon Aug 2 15:30:47 2010
New Revision: 162821
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162821
Log:
2010-08-02 Mikael Morin mik...@gcc.gnu.org
Janus
--- Comment #11 from mikael at gcc dot gnu dot org 2010-08-02 15:31 ---
Subject: Bug 45151
Author: mikael
Date: Mon Aug 2 15:30:47 2010
New Revision: 162821
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162821
Log:
2010-08-02 Mikael Morin mik...@gcc.gnu.org
Janus
--- Comment #21 from mikael at gcc dot gnu dot org 2010-08-02 15:31 ---
Subject: Bug 42051
Author: mikael
Date: Mon Aug 2 15:30:47 2010
New Revision: 162821
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162821
Log:
2010-08-02 Mikael Morin mik...@gcc.gnu.org
Janus
--- Comment #7 from t dot artem at mailcity dot com 2010-08-02 15:49
---
(In reply to comment #6)
Why CC me? I have no clue about faad2, the strict-aliasing thing hints
at errors in faad2, not gcc.
Richard, I don't know who is who amongst GCC developers, but you are a
prominent
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-08-02 16:21 ---
Like I said GCC 4.2.x has no problems compiling this library, so I have no
idea
who to blame and who else I should get in touch with.
I would get into contact with the developers of the library first. Yes GCC
--- Comment #1 from rwild at gcc dot gnu dot org 2010-08-02 16:40 ---
Is this a transient failure with parallel make, i.e., are you using parallel
make, and does the failure go away with a serial make or another parallel make
invocation? Which -jN option do you pass? Have you seen
Here is a small test case, with output and version information in the comments.
There are enough ways of stating this problem that it was not evident to me
within the existing bug list. One skilled in the art would know if this is a
duplicate.
I'm not sure where to upload my .i file, so I will
--- Comment #1 from robots at marcabel dot com 2010-08-02 16:47 ---
Created an attachment (id=21371)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21371action=view)
Preprocessor output / compiler input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45164
--- Comment #2 from robots at marcabel dot com 2010-08-02 16:48 ---
Created an attachment (id=21372)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21372action=view)
Source code to produce
in case it doesn't paste well from my initial report.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-02 16:48 ---
Signed overflow is undefined; use either unsigned or -fwrapv to get the
behavior you want.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-08-02 16:54 ---
Subject: Bug 36854
Author: tkoenig
Date: Mon Aug 2 16:53:51 2010
New Revision: 162824
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162824
Log:
2010-08-02 Thomas Koenig tkoe...@gcc.gnu.org
PR
--- Comment #4 from robots at marcabel dot com 2010-08-02 16:54 ---
Confirmed resolved invalid. Thank you!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45164
fd's are opened but never closed.
--
Summary: unix.c:fallback_access() leaks file descriptors
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo:
--- Comment #48 from ubizjak at gmail dot com 2010-08-02 17:12 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00021.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
When multiple .c (.cpp?) files are mentioned on the command line, GCC places
only a single one in the MD output:
$ echo int main() { return 0; } a.c
$ echo int foo() { return 0; } b.c
$ gcc -MD a.c b.c
$ cat a.d
a.o: a.c
b.c was lost, but should be listed.
--
Summary: gcc -MD
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-02
17:18 ---
Subject: Re: No rule to make target
`.deps/affinity.Plo'
On Mon, 02 Aug 2010, rwild at gcc dot gnu dot org wrote:
Please also show how you configured your build, and please also post the exact
--- Comment #49 from ubizjak at gmail dot com 2010-08-02 17:33 ---
Author: uros
Date: Mon Aug 2 17:26:40 2010
New Revision: 162826
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162826
Log:
target/41089
* config/alpha/alpha.c (alpha_build_builtin_va_list): Mark
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-08-02 17:40 ---
(In reply to comment #7)
The patch is really the same. I did not commit it because the branch
was frozen for the release of 4.5.1. I'm re-testing it on the branch
now and hopefully will commit it today.
--- Comment #1 from pj dot pandit at yahoo dot co dot in 2010-08-02 18:38
---
The following patch to gcc-4.4.4 seems to fix the issue for DW_AT_subprogram
DIEs.
$ diff -Naurp gcc-4.4.4/gcc/dwarf2out.c gcc-4.4.4.1/gcc/dwarf2out.c
--- gcc-4.4.4/gcc/dwarf2out.c 2010-02-10
build environment: gcc 4.5.0 on MacBook Pro running OS X 10.6.4
execution environment: same as build environment
command: g++ --std=c++0x filename
auto at_or_above = [] ( int threshhold )
{
return [threshhold] (int x)
{ return x = threshhold; };
};
template class Pred
int zero( Pred )
--- Comment #10 from tkoenig at gcc dot gnu dot org 2010-08-02 19:00
---
This fixes the test case from comment #0, and looks much more sane.
Let's see if this survives regression-testing...
Index: dependency.c
===
---
--- Comment #18 from uweigand at gcc dot gnu dot org 2010-08-02 19:25
---
(In reply to comment #17)
Someone might want to try this again after the fix for PR 38582.
It's a lot better, but still not real good. I'm now seeing on a QS22 (ppu -
spu cross compiler):
-O0: 0m9.983s
-O1:
--- Comment #19 from pinskia at gcc dot gnu dot org 2010-08-02 20:16
---
reload CSE regs
Will most likely be helped by:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02397.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
--- Comment #18 from bernds at gcc dot gnu dot org 2010-08-02 20:18 ---
Subject: Bug 45063
Author: bernds
Date: Mon Aug 2 20:17:59 2010
New Revision: 162828
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162828
Log:
PR target/45063
* caller-save.c
--- Comment #9 from t dot artem at mailcity dot com 2010-08-02 20:27
---
The culprit is the ic_predict.c file. When I compile it with
-fno-strict-aliasing (while everything else is being compiled with
-fstrict-aliasing) libfaad works correctly.
These are the warnings which I get from
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
It's fairly common in C and C++ libraries to have an enum with each element
representing an aspect of a request. In these situations it would be nice to be
able to deprecate specific enum members. For example the user wants to retrieve
a Foo from a server, and Foo's have 3 parts, they might make a
--- Comment #11 from tkoenig at gcc dot gnu dot org 2010-08-02 22:04
---
Subject: Bug 45159
Author: tkoenig
Date: Mon Aug 2 22:04:36 2010
New Revision: 162829
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162829
Log:
2010-08-02 Thomas Koenig tkoe...@gcc.gnu.org
PR
--- Comment #12 from tkoenig at gcc dot gnu dot org 2010-08-02 22:16
---
(In reply to comment #5)
[macbook] lin/test% gfc -Warray-temporaries nf.f90
nf.f90:293.30:
if ( ii1 ) x(i:i+nxy-1) = x(i:i+nxy-1) - au3(i-nxy:i-1)*x(i-nxy:i-1)
1
Warning:
A trivial C++ 'hello world' produces mudflap violations w/ -O2, but not w/ -O0:
---
#include iostream
int main() {
std::cout hello std::endl;
}
---
/opt/gcc-4.5.1/bin/gcc -Wall -O2 -fmudflap -o test test.cc -lmudflap -lstdc++
./test
***
mudflap violation 1 (check/read):
gfortran tech support,
When I attempt to compile the program listed below, the following error
messages are printed:
n...@oxford:~/Elements/AllocChar$ more alloccharP.xyz
alloccharP.f90:6.12:
character(:), allocatable :: c_Char(:)
1
Error: Syntax error in CHARACTER declaration
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-03 02:31 ---
This statement:
character(:), allocatable :: io_message
uses a deferred type parameter (a F2003
feature), which is not supported by gfortran
at this time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-03 05:43 ---
By the way, gfortran's Fortran 2003 implementation status can be found at
http://gcc.gnu.org/wiki/Fortran2003Status
--
burnus at gcc dot gnu dot org changed:
What|Removed
73 matches
Mail list logo
