You are right about C, but i believe templates in C++ make parsing harder.
DOxygen also parses C/C++.
On 7/29/07, Rafael Espindola [EMAIL PROTECTED] wrote:
Having spent some time looking at the code for gcc it seems reasonably
easy(with some suggestions) to traverse the tree generated and
Hi,
Or perhaps this could be another manifestation of the cse gets confused by
reg_equal notes on subparts of dimode pseudos if no movdi pattern is defined
in the backend bug[*]? Pranav, is there a movdi pattern in your backend?
There needs to be one, gcc does get it wrong if you rely on
Hello,
bootstrapping with GCC 4.3. from today is not successfull on my computer
i686-pc-linux-gnu.
configure flags:
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++,treelang
--with-mpfr=/usr/local
Here is the error message:
make[5]: Leaving directory
On 7/27/07 9:58 AM, Zdenek Dvorak wrote:
Hello,
I liked the idea of 'Reviewers' more than any of the other options.
I would like to go with this patch, unless we find a much better
option?
to cancel this category of maintainers completely?
An interesting idea, but let's discuss that
I noticed while building test gcc43 fink packaging
that the gcj-4.3.0 subdirectory in the gcc installation
directory has been suddenly changed to gcj-4.3.0-9. Is
this intentional or a typo in one of the patches?
Jack
Andreas Meier [EMAIL PROTECTED] writes:
bootstrapping with GCC 4.3. from today is not successfull on my computer
i686-pc-linux-gnu.
Does it help to revert this patch?
2007-07-26 Zdenek Dvorak [EMAIL PROTECTED]
* dominance.c (dom_computed, n_bbs_in_dom_tree): Removed.
*
On 7/28/07 5:38 PM, Gerald Pfeifer wrote:
Currently I only see the 2003 and 2004 proceedings at
ftp://gcc.gnu.org/pub/gcc/summit/
Huh. I didn't know those existed. I've always used the links from the
wiki.
How about moving everything to one consistent place? Any preferences
on what
Dave Korn escreveu:
Thanks, and do drop a note back with a summary of what you find out over
there when you're done; if there's definitely a bug in gcc's understanding of
the resolution rules, obviously we'd like to open a PR and get it fixed.
I think we have finally a consensus at
Hi,
I'm working on GCC 4.1.1 on spu target and get following problem:
After splitting an insn with a note REG_LIBCALL, the insn is replaced by
some other insns, which don't attach REG_LIBCALL note any more, and the
original one is then deleted. While the insn REG_RETVAL still points to
the
Hi all,
I try to develop a tool that get the final CFG of gcc by passing the
-fdump-tree-final_cleanup-lineno option and parsing the file dumped by gcc.
I noticed that this flag does create an output only if at least the
'-O1' (or more) is in the command line.
I just would like to know if it
On 7/30/07 11:15 AM, Emmanuel Fleury wrote:
I just would like to know if it would be possible to get the
final_cleanup target even though no optimization flag has been given in
the command line (for now, I'm just forcing '-O1' to be present if no
other optimization flag has been detected in
Wow, that was quick. :)
Diego Novillo wrote:
On 7/30/07 11:15 AM, Emmanuel Fleury wrote:
I just would like to know if it would be possible to get the
final_cleanup target even though no optimization flag has been given in
the command line (for now, I'm just forcing '-O1' to be present if no
On 7/30/07, Diego Novillo [EMAIL PROTECTED] wrote:
On 7/27/07 9:58 AM, Zdenek Dvorak wrote:
Hello,
I liked the idea of 'Reviewers' more than any of the other options.
I would like to go with this patch, unless we find a much better
option?
to cancel this category of maintainers
On 7/30/07 11:34 AM, Emmanuel Fleury wrote:
Actually, I know that these dumps are here, as you said, just for
debugging purpose but why not making them 'permanent' and kind-of
'standardized' (I mean, not changing it too frequently), so that code
analysis tools could plug on GCC ? (I know I'm
On 7/30/07 12:08 PM, Seongbae Park (¹Ú¼º¹è, ÚÓà÷ÛÆ) wrote:
While reviewers can approve the changes in the parts of the compiler
they maintain,
they still need approval of their own patches from other maintainers
or reviewers.
Sounds good to me. Thanks.
Sa Liu [EMAIL PROTECTED] writes:
I'm working on GCC 4.1.1 on spu target and get following problem:
After splitting an insn with a note REG_LIBCALL, the insn is replaced by
some other insns, which don't attach REG_LIBCALL note any more, and the
original one is then deleted. While the insn
Hello,
this doesn't help.
Andreas
Andreas Schwab schrieb:
Andreas Meier [EMAIL PROTECTED] writes:
bootstrapping with GCC 4.3. from today is not successfull on my computer
i686-pc-linux-gnu.
Does it help to revert this patch?
2007-07-26 Zdenek Dvorak [EMAIL PROTECTED]
*
H.J. Lu wrote:
According to gcc/ChangeLog, gcc 4.2.1 was released on 2007-07-19.
Shouldn't gcc/DEV-PHASE in gcc 4.2 branch be marked as prerelease?
I've now updated BASE-VER and DEV-PHASE.
Good catch, thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Hi Kai,
so, could you resolve the remaining issues? Or have you kind of
paused the project?
Cheers,
Nicolas
On Jul 12, 2007, at 2:14 , Kai Tietz wrote:
Hi,
I am nearly through :) The remaining macros left to be ported are
REGPARM_MAX and SSE_REGPARM_MAX. The sysv_abi uses 6 regs and 8
Snapshot gcc-4.1-20070730 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070730/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi,
I just stumbled over the patch
2007-03-26 Dirk Mueller [EMAIL PROTECTED]
* parser.c (cp_parser_member_declaration): Pedwarn
about stray semicolons after member declarations.
which was approved by Gaby here:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01456.html
and made it
test message. delete before reading.
Ben White
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-07-30 06:11
---
Fixed on trunk. Closing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
--- Comment #4 from corsepiu at gcc dot gnu dot org 2007-07-30 08:11
---
Having investigated this breakdown further, I can reproduce it for many
coldfire variants.
Also: FWIW: Adding -fomit-frame-pointer lets the ICE disappear.
--
corsepiu at gcc dot gnu dot org changed:
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-30 09:28 ---
Subject: Bug 32527
Author: pinskia
Date: Mon Jul 30 09:28:14 2007
New Revision: 127058
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127058
Log:
2007-07-30 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-07-30 09:30
---
Fixed as mentioned so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-07-30 09:30 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from paolo at gcc dot gnu dot org 2007-07-30 09:37 ---
Subject: Bug 32108
Author: paolo
Date: Mon Jul 30 09:37:20 2007
New Revision: 127059
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127059
Log:
cp/
2007-07-30 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #19 from victork at il dot ibm dot com 2007-07-30 11:08 ---
I've tried to bootstrap with -mabi=altivec, but it failed with the same
error:
/home/victork/mainline-20-06/build.124727mabi/./prev-gcc/xgcc
-B/home/victork/mainline-20-06/build.124727mabi/./prev-gcc/
Using r127057 I get an internal compiler error with the following testcase:
-
program test_gfortran2
implicit none
Integer, Parameter ::
Double = Selected_Real_Kind(15,200)
Integer :: j
Complex(Double) :: g(5)
--- Comment #1 from dominiq at lps dot ens dot fr 2007-07-30 11:52 ---
Confirmed on PPC Darwin8, ICE on 4.3, pass on 4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32935
--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-07-30
11:56 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
I've tried to bootstrap with -mabi=altivec, but it failed with the same
error:
yes, the problem on ppc64 must be something
--- Comment #2 from CyrusOmega at gmail dot com 2007-07-30 12:04 ---
(In reply to comment #1)
Well it is valid as B::print hides A::print.
Try doing:
#include iostream
class A {
public:
virtual char * print() const { return A\n;}
virtual ~A(){};
};
class B : public A {
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-30 12:41 ---
Works with 2007-02-02-r121508 (on x86-64-linux)
Fails with 2007-02-02-r121519 (on x86-64-linux)
Ignoring Java and testsuite changes one finds the following changelog:
gcc/ChangeLog:
+2007-02-02 Ian Lance Taylor
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-30 13:36 ---
Reduced testcase:
program test_gfortran2
Complex(8) :: g, zh
Real(8):: g_q
g = zh/cmplx(0.0_8, -g_q, 8) - zh/cmplx(0.0_8,-g_q)
end
This is, again, all about kinds. If all involved variables are of
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-30 13:53 ---
With stage1 based f95, I get a different ICE which shows the issue:
t.f90:2: error: type mismatch in complex expression
complex8
real8
real4
D.1336 = COMPLEX_EXPR -0.0, D.1335
t.f90:5: confused by earlier errors,
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-30 13:57 ---
Here is an even shorter testcase:
program test_gfortran2
Complex(8) :: g, zh
Real(8):: g_q
g = zh - zh/cmplx(0.0_8,-g_q)
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32935
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-30 14:05 ---
And here is a patch which fixes the ICE:
Index: fold-const.c
===
--- fold-const.c(revision 127042)
+++ fold-const.c(working copy)
@@
The following testcase produces an error:
function all_res()
implicit none
real, pointer :: gain
integer :: all_res
allocate (gain,STAT=all_res)
end
--- Comment #12 from sje at gcc dot gnu dot org 2007-07-30 15:16 ---
Subject: Bug 32218
Author: sje
Date: Mon Jul 30 15:15:54 2007
New Revision: 127062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127062
Log:
PR target/32218
* tree-vect-patterns.c
--- Comment #4 from paolo at gcc dot gnu dot org 2007-07-30 15:38 ---
Subject: Bug 32108
Author: paolo
Date: Mon Jul 30 15:38:39 2007
New Revision: 127064
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127064
Log:
cp/
2007-07-30 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #5 from pcarlini at suse dot de 2007-07-30 15:39 ---
Fixed for 4.2.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-30 15:45 ---
The problem is that all_res is not only the name of a (result) variable but
also of the function itself.
The following - not regtested - should work (also if one uses ENTRY rather than
FUNCTION).
Index:
--- Comment #14 from pault at gcc dot gnu dot org 2007-07-30 16:22 ---
To my amazement, the patch below fixes the problem and, I am pretty sure, will
complete its regtest OK.
Before posting it, I want to thoroughly check that I have understood the
problem and that the fix is valid.
--- Comment #2 from patchapp at dberlin dot org 2007-07-30 18:30 ---
Subject: Bug number PR32936
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-07/msg02125.html
--
The failure in actual_array_constructor_2.f90
can be reduced to
$ cat actual_array_constructor_2.f90
character(4), dimension(4) :: c1, c2
integer m
m = 4
call foo ((/(c1(i), i = m,1,-1)/), c2)
if (any(c2(4:1:-1) .ne. c1)) call abort ()
contains
subroutine foo (chr1, chr2)
--- Comment #5 from hjl at lucon dot org 2007-07-30 20:22 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from hjl at lucon dot org 2007-07-30 20:22 ---
*** This bug has been marked as a duplicate of 32105 ***
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #3 from hjl at lucon dot org 2007-07-30 20:22 ---
*** Bug 32932 has been marked as a duplicate of this bug. ***
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #3 from hjl at lucon dot org 2007-07-30 20:23 ---
Wrong one.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #1 from hjl at lucon dot org 2007-07-30 20:23 ---
*** Bug 32932 has been marked as a duplicate of this bug. ***
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #4 from hjl at lucon dot org 2007-07-30 20:23 ---
*** This bug has been marked as a duplicate of 32064 ***
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2007-07-30 20:24 ---
The problem appears to be that the first argument to gfortani_compare_string
is pushed as an 8-byte integer, which messes things up.
The test passes for me with -m64, without it the backtrace is (on Darwin8):
--- Comment #19 from danglin at gcc dot gnu dot org 2007-07-30 20:31
---
Introduced in revision 126326.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from hjl at lucon dot org 2007-07-30 20:41 ---
Is this related to PR32921? Can you try the patch in comment 6:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921#c6
--
hjl at lucon dot org changed:
What|Removed |Added
Reducing the altreturn_5.f90 failure on i686-pc-linux-gnu, we get
$ cat alt.f90
SUBROUTINE R (i, *, *)
INTEGER i
RETURN i
END
$ gdb ~/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software,
--- Comment #22 from tkoenig at gcc dot gnu dot org 2007-07-30 21:06
---
Subject: Bug 32770
Author: tkoenig
Date: Mon Jul 30 21:06:41 2007
New Revision: 127071
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127071
Log:
2007-07-30 Thomas Koenig [EMAIL PROTECTED]
PR
The ivopts pass fails to set the REG_POINTER attribute on a pseudo that is
equal to two pseudos, one of which has teh REG_POINTER attribute and the other
is just a n offset from it. This leads us to not sort the operands on an
indexed load/store instruction causing performance problems on POWER6.
--- Comment #2 from hjl at lucon dot org 2007-07-30 23:04 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02151.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32064
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-30 23:12 ---
I think this was fixed for the trunk by removing the source code compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32939
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-30 23:54 ---
;; quadrant.0 = quadrant
(insn 16 15 17 t.c:8 (set (reg:SI 127)
(high:SI (symbol_ref:SI (quadrant) [flags 0x84] var_decl 0xf7d9f070
quadrant))) -1 (nil))
(insn 17 16 18 t.c:8 (set (reg/f:SI 126)
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-07-31 01:39
---
Regression tests fine on X86-64-Gnu/Linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31609
62 matches
Mail list logo