Hi,
I would like to banish bits and pieces of the compiler from ever
appearing again in places where they do not belong. That would be step
one towards modularization: impose boundaries of some kind. As it is,
we can't really make separate modules of parts of gcc yet, but at
least I would like to
On 05/25/2010 09:55 AM, Steven Bosscher wrote:
1) Group front end objects in Makefile.in under e.g. ALL_HOST_FRONTEND_OBJS
2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND
3) Conditionally poison symbols in system.h
For the last step, that would be e.g.:
#ifdef
Hi all,
I compared assembly files of a function compiled by GCC4.3.4 and GCC3.4.4.
The function focuses on array computation and has no branch, or any
loop structure,
The command line is like -march=mips32r2 -O3, and here is the
instruction statics:
total: 1879 : 1534
On Tue, May 25, 2010 at 9:56 AM, Paolo Bonzini bonz...@gnu.org wrote:
On 05/25/2010 09:55 AM, Steven Bosscher wrote:
1) Group front end objects in Makefile.in under e.g.
ALL_HOST_FRONTEND_OBJS
2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND
3) Conditionally poison symbols
On 25/05/2010 09:44, Steven Bosscher wrote:
+# This lists all host objects for the front ends. Extra defines are passed
+# to the compiler for these objects.
+ALL_HOST_FRONTEND_OBJS = $(C_OBJS)
+ $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
+
Missing line-continuation backslash there,
On Thu, 13 May 2010, Todd Rinaldo wrote:
Your FAQ at the below URLS conflicts as to which autoconf should be
used. one says 2.13 th other says 2.64. 2.65 is currently available.
http://gcc.gnu.org/faq.html#generated_files
http://gcc.gnu.org/install/prerequisites.html
Thanks for your
Steven Bosscher stevenb@gmail.com writes:
But for some reason I get -DIN_GCC_FRONTEND also on some of the gen*
files, libiberty, and gcov-io.o, like so:
Target-specific variable values are applied to all dependencies, see
(make) Target-specific:
There is one more special feature of
Hello,
I tried to compile the gcc-melt branch from svn, but i get the following error:
make warmelt1
make[4]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc'
date +/* empty-file-for-melt.c %c */ empty-file-for-melt.c-tmp
/bin/bash ../../melt-branch/gcc/../move-if-change
Hello,
I am using current mainline to compile a testcase which contains a loop.
The target I'm working on supports cmpsi pattern.
While expanding the loop condition I get that do_compare_rtx_and_jump ()
and
do_jump_by_parts_greater_rtx () call each other repeatedly.
The test I'm compiling
On Tue, 25 May 2010, Steven Bosscher wrote:
I am guessing this comes in from the $C_TARGET_OBJS and other language
target objects. In the Makefile in the build directory I have this
dependency:
Target specific, C specific object file
C_TARGET_OBJS=i386-c.o
But unfortunately I cannot
On Tue, May 25, 2010 at 2:25 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Tue, 25 May 2010, Steven Bosscher wrote:
I am guessing this comes in from the $C_TARGET_OBJS and other language
target objects. In the Makefile in the build directory I have this
dependency:
Target specific,
On Tue, 25 May 2010 16:28:37 +0800, Amker.Cheng wrote:
Hi all,
I compared assembly files of a function compiled by GCC4.3.4 and
GCC3.4.4.
The function focuses on array computation and has no branch, or any
loop structure,
The command line is like -march=mips32r2 -O3, and here is the
On 05/25/2010 12:13 PM, Revital1 Eres wrote:
Hello,
I am using current mainline to compile a testcase which contains a loop.
The target I'm working on supports cmpsi pattern.
While expanding the loop condition I get that do_compare_rtx_and_jump ()
and
do_jump_by_parts_greater_rtx () call
Hello,
Just did so... :-)
and it indeed solves this.
Thanks,
Revital
From: Paolo Bonzini bonz...@gnu.org
To: Revital1 Eres/Haifa/i...@ibmil
Cc: gcc@gcc.gnu.org
Date: 25/05/2010 03:57 PM
Subject:Re: Help with expanding compare
Sent by:Paolo Bonzini
On 05/25/2010 03:01 PM, Revital1 Eres wrote:
Hello,
Just did so... :-)
and it indeed solves this.
Remember to do the same for cstore.
Most of the time it will remove more code from your target than it adds.
I think that it did so for basically all targets in GCC 4.5, sometimes
cutting up
On Tue, 2010-05-25 at 12:03 +0200, Wolfgang wrote:
Hello,
I tried to compile the gcc-melt branch from svn,
A big thanks for testing GCC MELT! What svn revision of the MELT branch
are you testing? Did you configure gcc-melt with --enable-bootstrap?
Can you reproduce the bug inside a clean
On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab sch...@redhat.com wrote:
Steven Bosscher stevenb@gmail.com writes:
But for some reason I get -DIN_GCC_FRONTEND also on some of the gen*
files, libiberty, and gcov-io.o, like so:
Target-specific variable values are applied to all
Steven Bosscher wrote:
The first thing I'd like to do now, is banish RTL from the front end.
Certainly a desirable goal!
(I did a bit of this in the C++ front-end a while back, though nothing
as formal or complete as what you are suggesting. There used to be
various places where the front end
* Steven Bosscher wrote on Tue, May 25, 2010 at 04:23:35PM CEST:
On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote:
Target-specific variable values are applied to all dependencies, see
(make) Target-specific:
[...]
That is the problem here. TM_H depends on insn-constants.h, which
On Tue, May 25, 2010 at 4:28 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
* Steven Bosscher wrote on Tue, May 25, 2010 at 04:23:35PM CEST:
On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote:
Target-specific variable values are applied to all dependencies, see
(make) Target-specific:
On Tue, 2010-05-25 at 16:20 +0200, Basile Starynkevitch wrote:
A dirty workaround might be to replace every -gtoggle occurrence in the
build tree gcc/Makefile with -g.
Another slightly less dirty workaround, assuming that gcc-4.5 is
available on your machine, is to set the GCCMELT_CC
Steven Bosscher stevenb@gmail.com writes:
So I guess this plan of mine is not going to work...
Other ideas?
Add $(CFLAGS-$(@F)) to the .c.o rule and define CFLAGS-foo for each foo
in $(ALL_HOST_FRONTEND_OBJS). Though the latter is a bit tricky if you
want to do it automatically.
Andreas.
On Tue, May 25, 2010 at 16:59, Andreas Schwab sch...@redhat.com wrote:
Steven Bosscher stevenb@gmail.com writes:
So I guess this plan of mine is not going to work...
Other ideas?
Add $(CFLAGS-$(@F)) to the .c.o rule
Actually $@ is fine, since you want cp/tree.o to have different flags
Original-Nachricht
Datum: Tue, 25 May 2010 16:20:14 +0200
Von: Basile Starynkevitch bas...@starynkevitch.net
An: Wolfgang wolfgang8...@gmx.de
CC: gcc@gcc.gnu.org
Betreff: Re: Melt-building problem
On Tue, 2010-05-25 at 12:03 +0200, Wolfgang wrote:
Hello,
I tried to
On Tue, 2010-05-25 at 17:09 +0200, Wolfgang wrote:
Original-Nachricht
Datum: Tue, 25 May 2010 16:20:14 +0200
Von: Basile Starynkevitch bas...@starynkevitch.net
An: Wolfgang wolfgang8...@gmx.de
CC: gcc@gcc.gnu.org
Betreff: Re: Melt-building problem
On Tue,
On Tue, 2010-05-25 at 17:09 +0200, Wolfgang wrote:
Original-Nachricht
Datum: Tue, 25 May 2010 16:20:14 +0200
Von: Basile Starynkevitch bas...@starynkevitch.net
An: Wolfgang wolfgang8...@gmx.de
CC: gcc@gcc.gnu.org
Betreff: Re: Melt-building problem
On Tue,
Dear All,
I am porting GCC to a 16 bit micro (with 16 bit bytes, thus
BITS_PER_UNIT=16, 16 bit ints become QIs etc).
The port compiles is nearly done and simple C programs, but now chokes
on a trivial line such as:
yyy(array[4], e, p);
with this error:
xxx.c: In function ‘yyy’:
All,
the toplevel configury of gcc/gdb/binutils is very much out of sync.
If people agree, I would like to freeze commits to the toplevel
configury until they are not diverging anymore.
Also, I would like to make a new policy that from now on patches to the
toplevel cannot be committed by
* Paolo Bonzini wrote on Tue, May 25, 2010 at 06:06:16PM CEST:
the toplevel configury of gcc/gdb/binutils is very much out of sync.
Unfortunately I don't have much time to devote to bringing the trees
back in shape, and not even to chase down committers of patches
placed only on one side.
On 05/25/2010 07:09 PM, Ralf Wildenhues wrote:
* Paolo Bonzini wrote on Tue, May 25, 2010 at 06:06:16PM CEST:
the toplevel configury of gcc/gdb/binutils is very much out of sync.
Unfortunately I don't have much time to devote to bringing the trees
back in shape, and not even to chase down
* Paolo Bonzini wrote on Tue, May 25, 2010 at 07:10:33PM CEST:
On 05/25/2010 07:09 PM, Ralf Wildenhues wrote:
... the last date when the tree was synchronized ...
It looked fairly good 3 months ago[1].
Toplevel and config/ went out of sync with commit 6c8aa2aa884d of the
GCC infradead git
* Ralf Wildenhues wrote on Tue, May 25, 2010 at 07:33:53PM CEST:
* Paolo Bonzini wrote on Tue, May 25, 2010 at 07:10:33PM CEST:
As you prefer. I'd rather see a list of commits before giving you
green light though. :-)
commit id of infradead mirror, GCC SVN revision number:
One more
On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li davi...@google.com wrote:
On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, May 20, 2010 at 11:21 PM, Xinliang David Li davi...@google.com
wrote:
On Thu, May 20, 2010 at 2:18 PM, Steven Bosscher
Also, I would like to make a new policy that from now on patches to
the toplevel cannot be committed by anyone who doesn't have write
access to both gcc and src. Is there any agreement on this?
Our current policy certainly doesn't work, either we come up with
something that will, or abandon
There are no changes in intl, libiberty. The sourceware git mirror
doesn't seem to carry libdecnumber. Which files in include/ were
part of libiberty again?
Libiberty is kept in sync because gcc is the master and src is the
copy, so it can be mostly automated. The libiberty sync includes
On 25/05/10 06:06, Ian Lance Taylor wrote:
The official list of maintainers is stored in the gcc source code in
the file MAINTAINERS. Having said that, there is no maintainer listed
for lm32. I assume that it must be, as you suggest, Jon Beniston.
Yeah, I spotted that in SVN about five
Snapshot gcc-4.4-20100525 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100525/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Philip Pemberton phil...@gmail.com writes:
The address is unusual:
(subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ])
(const_int 64 [0x40])) [0 S8 A64]) 4)
Why isn't that simply
(mem/s:SI (plus:SI (reg/v/f:SI 39 [ ctx ])
(const_int 68 [0x40]))
In a biweekly call with the other GCC Release Managers, I was asked
today on the status of the SC/FSF discussions re. GFDL/GPL issues. In
particular, the question of whether or not we can use literate
programming techniques to extract documentation from code and take bits
of what is currently in
In:
http://gcc.gnu.org/ml/gcc/2010-05/msg00347.html
I indicated that I, and the other GCC RMs as available, would
participate in an interactive IRC discussion on May 27th at 9:00 AM Pacific.
As nobody has volunteered to moderate the IRC session, we'll use the
general-purpose GCC developer IRC
On Tue, May 25, 2010 at 4:38 PM, DJ Delorie d...@redhat.com wrote:
Also, I would like to make a new policy that from now on patches to
the toplevel cannot be committed by anyone who doesn't have write
access to both gcc and src. Is there any agreement on this?
Our current policy certainly
On 25/05/2010 17:06, Paolo Bonzini wrote:
Unfortunately I don't have much time to devote to bringing the trees
back in shape, and not even to chase down committers of patches placed
only on one side. Can anybody help with this?
Augh. I forgot to copy over this one:
PR lto/42776
On 25/05/2010 18:33, Ralf Wildenhues wrote:
bcd70fb06d56d9316d49019f5c0a3109def08d39 158763
a9ed67d000f285282e61aa9b87cc8d992a8731df 158762
I'm responsible for those two, and I'm copying them across right now; sorry
for forgetting.
cheers,
DaveK
On 26/05/2010 05:58, Dave Korn wrote:
On 25/05/2010 18:33, Ralf Wildenhues wrote:
bcd70fb06d56d9316d49019f5c0a3109def08d39 158763
a9ed67d000f285282e61aa9b87cc8d992a8731df 158762
I'm responsible for those two, and I'm copying them across right now; sorry
for forgetting.
And while
On 26/05/2010 06:09, Dave Korn wrote:
On 26/05/2010 05:58, Dave Korn wrote:
On 25/05/2010 18:33, Ralf Wildenhues wrote:
bcd70fb06d56d9316d49019f5c0a3109def08d39 158763
a9ed67d000f285282e61aa9b87cc8d992a8731df 158762
I'm responsible for those two, and I'm copying them across right now;
On Tue, 2010-05-25 at 17:44 -0700, Mark Mitchell wrote:
In a biweekly call with the other GCC Release Managers, I was asked
today on the status of the SC/FSF discussions re. GFDL/GPL issues. In
particular, the question of whether or not we can use literate
programming techniques to extract
--- Comment #1 from pzhao at gcc dot gnu dot org 2010-05-25 06:26 ---
Subject: Bug 18249
Author: pzhao
Date: Tue May 25 06:26:07 2010
New Revision: 159808
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159808
Log:
2010-05-25 Shujing Zhao pearly.z...@oracle.com
PR
--- Comment #5 from wilson at gcc dot gnu dot org 2010-05-25 06:30 ---
Richard Guenther suggested using DOT_PROD_EXPR. I ran into several problems
with that.
DOT_PROD_EXPR expands to the sdot_prodM pattern. The mips port is using
maddMN. We essentially have two named patterns that
--- Comment #6 from wilson at gcc dot gnu dot org 2010-05-25 06:35 ---
Created an attachment (id=20739)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20739action=view)
second patch attempt, modifying widen_mult tree pass
This removes about 100 lines from expr.c, and adds about 90
--- Comment #2 from pzhao at gcc dot gnu dot org 2010-05-25 06:57 ---
Fixed for 4.6.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18249
--- Comment #3 from pzhao at gcc dot gnu dot org 2010-05-25 06:57 ---
Fixed.
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-25 07:33 ---
powerpc64-apple-darwin9 does *not* exhibit this ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
--- Comment #7 from iains at gcc dot gnu dot org 2010-05-25 07:38 ---
(In reply to comment #4)
(In reply to comment #3)
most likely this is a duplicate of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
1. I see the failure on both BE (sparc64) and LE (armv5tel).
2. Both BE
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-25 07:57 ---
If cp-demangle.c fails to compile even with -fcompare-debug switch added,
please
attach preprocessed source for it from sparc64 and/or arm and mention the exact
command line switches used to compile it, so it can be
--- Comment #14 from rguenther at suse dot de 2010-05-25 08:11 ---
Subject: Re: Multiple comparisons are not simplified
On Mon, 24 May 2010, sandra at codesourcery dot com wrote:
--- Comment #13 from sandra at codesourcery dot com 2010-05-24 13:21
---
I'm working on a
--- Comment #16 from reichelt at gcc dot gnu dot org 2010-05-25 08:41
---
*** Bug 44264 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2010-05-25 08:41
---
This sounds like the same as PR 44256 which was just fixed today.
I guess, you're right. The bug disappeared.
*** This bug has been marked as a duplicate of 44256 ***
--
reichelt at gcc dot gnu dot org
--- Comment #6 from iains at gcc dot gnu dot org 2010-05-25 09:11 ---
Subject: Bug 44140
Author: iains
Date: Tue May 25 09:10:52 2010
New Revision: 159812
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159812
Log:
PR ObjC/44140
* objc.dg/torture/tls/thr-init-3.m:
--- Comment #12 from bonzini at gnu dot org 2010-05-25 09:19 ---
Subject: Bug 43610
Author: bonzini
Date: Tue May 25 09:19:37 2010
New Revision: 159813
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159813
Log:
2010-05-09 Paolo Bonzini bonz...@gnu.org
PR target/43610
--- Comment #7 from iains at gcc dot gnu dot org 2010-05-25 09:22 ---
This bug has nothing to do with the TLS check, so renaming
A non-tls testcase exhibiting the same fail is shown as comment #5
--
iains at gcc dot gnu dot org changed:
What|Removed
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18249
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-25 09:28
---
For the record, both Intel and Comeau accept this. Let's CC Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #25 from iains at gcc dot gnu dot org 2010-05-25 09:38 ---
#24 works for me also on powerpc-apple-darwin9 and powerpc64-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
--- Comment #1 from burnus at gcc dot gnu dot org 2010-05-25 09:50 ---
CONFIRM
(No regression: GCC 4.1/4.2/4.3 reject the code [names invalid in expression]
while 4.4/4.5/4.6 show either the link error or ICE. Other compilers simply
work.)
One has the local parameter:
CHARACTER(*),
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
says gcc-3.4.x, gcc-4.[0-5].x: on m68k-linux and hppa-linux this is either
libgcc_s.so.1 (when configuring --with-sjlj-exceptions) or libgcc_s.so.2. For
all others, this is libgcc_s.so.1.
But I see libgcc_s.so.4 on hppa not libgcc_s.so.2.
--- Comment #1 from caolanm at redhat dot com 2010-05-25 10:34 ---
Created an attachment (id=20740)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20740action=view)
update docs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44268
--- Comment #28 from jakub at gcc dot gnu dot org 2010-05-25 10:39 ---
Created an attachment (id=20741)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20741action=view)
gcc46-pr41371.patch
Another small optimization. At least on this testcase in 80% the s1node and
--- Comment #4 from krebbel at gcc dot gnu dot org 2010-05-25 11:18 ---
Subject: Bug 44203
Author: krebbel
Date: Tue May 25 11:18:07 2010
New Revision: 159816
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159816
Log:
2010-05-25 Christian Borntraeger borntrae...@de.ibm.com
/cp/ChangeLog
trunk/gcc/cp/parser.c
This broke bootstrap on i686-pc-linux-gnu:
/user/inria/fsf/bld-20100525/./prev-gcc/xgcc
-B/user/inria/fsf/bld-20100525/./prev-gcc/ -B/user/inria/i686-pc-linux-gnu/bin/
-B/user/inria/i686-pc-linux-gnu/bin/ -B/user/inria/i686-pc-linux-gnu/lib/
-isystem /user
--- Comment #13 from dbkr at mxtelecom dot com 2010-05-25 12:09 ---
I've just run into this problem too with MinGW's packaged GCC 4.4.0. It was
working fine for some time but recently started crashing when both libevent and
the C++ program that libevent was calling back into were both
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-25 12:22 ---
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01837.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18249
Searching for 18249 or PR18249 in the web archive of the gcc-patches mailing
list fails, even though there are postings with PR18249 in the subject.
--
Summary: Search for PR number in mailing lists fails
Product: gcc
Version: 4.6.0
Status:
--- Comment #31 from iains at gcc dot gnu dot org 2010-05-25 12:51 ---
please can we revert the changes of comment #11?
They did not solve the problem and AFAICT they are wrong and break bootstrap on
x86_64-apple-darwin10 if I correct an error in the t-makefile fragments.
after
When I attempt to compile the snapshot of 05/22/2010 I get the following
messages:
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
libiberty/cp-demangle.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-25 13:27 ---
*** This bug has been marked as a duplicate of 44255 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-25 13:27 ---
*** Bug 44270 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-25 13:40 ---
Re-confirmed. It's not some decl/type context that is missing, maybe some
C++ debug hook that needs to be emulated.
Not working on this at the moment.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #1 from amodra at gmail dot com 2010-05-25 13:42 ---
Created an attachment (id=20742)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20742action=view)
fairly obvious fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44266
--- Comment #2 from amodra at gmail dot com 2010-05-25 13:45 ---
Created an attachment (id=20743)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20743action=view)
alternate fix using emit_library_call machinery
this one hasn't finished bootstrapping yet
--
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-25 13:51 ---
Created an attachment (id=20744)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20744action=view)
gcc46-pr43260.patch
Untested patch that solves it similarly to how C++ FE does this.
--
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-05-25 13:56
---
-fsched2-use-superblocks also fixes it.
-fdbg-cnt=sched_region:65 is broken, -fdbg-cnt=sched_region:64 works for
a simplified testcase tail:
int bmi_get(const int* id)
{
if (*id != 42)
__builtin_abort();
Revision 159808:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00862.html
gave:
../../src-trunk/gcc/cp/parser.c: In function 'cp_parser_asm_definition':
../../src-trunk/gcc/cp/parser.c:13478:3: error: enum conversion in
initialization is invalid in C++ [-Werror=c++-compat]
cc1: all warnings being
gcc 4.5.0, built for arm-elf
Problems with compiling following code:
int ret_const(void)
{
return 0x12E+2;
}
GCC claims that:
test.c: In function 'ret_const':
test.c:3:12: error: invalid suffix +2 on integer constant
test.c:4:1: warning: control reaches end of non-void function
This is
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-05-25 14:57
---
We're exchanging
movq112(%rsp), %rdx
and
leaq96(%rsp), %rbx
movq%rbp, 16(%rbx)
which is broken.
(insn 565 18 20 3 /usr/include/boost/function/function_template.hpp:566 (set
When you compile anything using @file support, the driver assumes @file
(at_file_supplied is true) is allowed and may pass options to the linker via
@file using a *temporary* file.
When -save-temps is also used, the temporary @file passed to the linker should
also be saved.
Saving the temporary
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-05-25 15:28
---
I have some patches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-25 15:33 ---
It is not a bug.
See ISO C99, 6.4.8.
0x12E+2
as whole is a pp-number and thus one token (which is not a valid number though,
but that is determined in a later phase, not during lexing).
If you want 0x12E + 2, you
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-25 15:50 ---
Subject: Bug 44069
Author: rguenth
Date: Tue May 25 15:49:34 2010
New Revision: 159824
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159824
Log:
2010-05-25 Richard Guenther rguent...@suse.de
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-25 15:53 ---
Fixed for 4.6 sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c: In function 'uw_update_context_1':
/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c:1378:1: error: unrecognizable insn:
(insn 372 371 373 42 /src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c:241 (set (reg:DI
457)
(plus:SI (subreg/s:SI (reg:DI 183 [ ivtmp___789
--- Comment #5 from ro at gcc dot gnu dot org 2010-05-25 16:14 ---
Created an attachment (id=20745)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20745action=view)
proposed patch
This patch worked for me. It's a hack in that it does the save and restore
using lowlevel autoconf
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-25 16:16 ---
Subject: Bug 42801
Author: jakub
Date: Tue May 25 16:15:38 2010
New Revision: 159826
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159826
Log:
PR debug/42801
* tree-inline.c (remap_decls):
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-25 16:18 ---
Subject: Bug 18249
Author: jakub
Date: Tue May 25 16:17:32 2010
New Revision: 159827
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159827
Log:
PR c++/18249
* parser.c (non_integral_constant):
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-25 16:19 ---
Subject: Bug 43260
Author: jakub
Date: Tue May 25 16:19:11 2010
New Revision: 159828
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159828
Log:
PR debug/43260
* java-tree.h
--- Comment #6 from bonzini at gnu dot org 2010-05-25 16:21 ---
The patch needs a fat comment saying what's going on, then it should be okay.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44216
--- Comment #29 from jakub at gcc dot gnu dot org 2010-05-25 16:27 ---
Subject: Bug 41371
Author: jakub
Date: Tue May 25 16:27:03 2010
New Revision: 159829
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159829
Log:
PR debug/41371
* var-tracking.c
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-25 16:28 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from ubizjak at gmail dot com 2010-05-25 16:42 ---
*** Bug 44274 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43973
--- Comment #1 from ubizjak at gmail dot com 2010-05-25 16:42 ---
This is duplicate of 43973.
*** This bug has been marked as a duplicate of 43973 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2010-05-25 16:47 ---
Fixed by [1].
[1] http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00882.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
1 - 100 of 136 matches
Mail list logo
